1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YJjN3-0003l0-AB
for bitcoin-development@lists.sourceforge.net;
Fri, 06 Feb 2015 13:54:57 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.42 as permitted sender)
client-ip=74.125.82.42; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f42.google.com;
Received: from mail-wg0-f42.google.com ([74.125.82.42])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YJjN2-0000dR-26
for bitcoin-development@lists.sourceforge.net;
Fri, 06 Feb 2015 13:54:57 +0000
Received: by mail-wg0-f42.google.com with SMTP id x13so13735641wgg.1
for <bitcoin-development@lists.sourceforge.net>;
Fri, 06 Feb 2015 05:54:50 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.93.134 with SMTP id cu6mr7984583wjb.79.1423230890038;
Fri, 06 Feb 2015 05:54:50 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.11 with HTTP; Fri, 6 Feb 2015 05:54:49 -0800 (PST)
In-Reply-To: <54D482B8.9070108@voskuil.org>
References: <544174F8.1050208@AndySchroder.com>
<54D3FEE9.70502@AndySchroder.com> <54D40C7D.8090804@voskuil.org>
<mb1um3$ee3$1@ger.gmane.org> <54D482B8.9070108@voskuil.org>
Date: Fri, 6 Feb 2015 14:54:49 +0100
X-Google-Sender-Auth: Naz19Oi0tjAgxi6VmlrLnvtAJfs
Message-ID: <CANEZrP23tfTzCfk2eXUOPX=CFCg6GKn4HO5Rb3ZxeOJQtEQCHw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary=047d7bb7092ca25c5e050e6bc354
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YJjN2-0000dR-26
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth
Communication and bitcoin: URI Scheme Improvements
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2015 13:54:57 -0000
--047d7bb7092ca25c5e050e6bc354
Content-Type: text/plain; charset=UTF-8
BLE meets a different use case than regular Bluetooth. BLE is designed to
allow always-on broadcast "beacons" which are conceptually similar to NFC
tags, with very low power requirements. The tradeoff for this ultra-low
power consumption and always on nature is the same as with NFC tags: you
get very little space for data, and they are essentially one way. That's
why a common use case for it is to trigger some other mechanism like a
classical Bluetooth socket or HTTPS connection.
I think BLE has a role to play in Bitcoin payments, but probably not for
actually transferring payment data. Rather, a merchant should be able to
drop a BLE beacon in their shop, and then wallet apps can use that to learn
where to download a payment request/upload a payment message. But the
actual data transfer would still take place over Bluetooth, Wifi or the
internet.
That leads to the question of what the beacon broadcasts. A bitcoin URI is
the obvious answer: the problem is a URI contains an address. No problem
for the "throw money at a live performer" use case but a problem for the
cafe use case. If we are willing to mandate BIP70 and remove the static
address part from the URI the we get a "uri that points to a url" which is
a bit inefficient but at least lets us distinguish bitcoin beacons from
other kinds. That still leaves the fundamental question raised by the
Airbitz spec - how does your wallet download the right payment request?
Unfortunately that's a tough UI problem. I don't think comparing long hex
strings manually is a good way to go. This seems less user friendly than a
QR code.
Once we solve that problem, how BLE beacons can trigger payments will all
fall into place. The tech part isn't the hard part.
--047d7bb7092ca25c5e050e6bc354
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">BLE meets a different use case =
than regular Bluetooth. BLE is designed to allow always-on broadcast "=
beacons" which are conceptually similar to NFC tags, with very low pow=
er requirements. The tradeoff for this ultra-low power consumption and alwa=
ys on nature is the same as with NFC tags: you get very little space for da=
ta, and they are essentially one way. That's why a common use case for =
it is to trigger some other mechanism like a classical Bluetooth socket or =
HTTPS connection.</div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">I think BLE has a role to play in Bitcoin payments, but probabl=
y not for actually transferring payment data. Rather, a merchant should be =
able to drop a BLE beacon in their shop, and then wallet apps can use that =
to learn where to download a payment request/upload a payment message. But =
the actual data transfer would still take place over Bluetooth, Wifi or the=
internet.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra">That leads to the question of what the beacon broadcasts. A bitcoin UR=
I is the obvious answer: the problem is a URI contains an address. No probl=
em for the "throw money at a live performer" use case but a probl=
em for the cafe use case. If we are willing to mandate BIP70 and remove the=
static address part from the URI the we get a "uri that points to a u=
rl" which is a bit inefficient but at least lets us distinguish bitcoi=
n beacons from other kinds. That still leaves the fundamental question rais=
ed by the Airbitz spec - how does your wallet download the right payment re=
quest?</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"=
>Unfortunately that's a tough UI problem. I don't think comparing l=
ong hex strings manually is a good way to go. This seems less user friendly=
than a QR code.</div><div class=3D"gmail_extra"><br></div><div class=3D"gm=
ail_extra">Once we solve that problem, how BLE beacons can trigger payments=
will all fall into place. The tech part isn't the hard part.</div></di=
v>
--047d7bb7092ca25c5e050e6bc354--
|
