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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1VKW7b-0008Rn-Nd
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Sep 2013 16:21:27 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.47 as permitted sender)
client-ip=209.85.214.47; envelope-from=mh.in.england@gmail.com;
helo=mail-bk0-f47.google.com;
Received: from mail-bk0-f47.google.com ([209.85.214.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VKW7a-0006le-CX
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Sep 2013 16:21:27 +0000
Received: by mail-bk0-f47.google.com with SMTP id mx12so556707bkb.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 13 Sep 2013 09:21:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.204.103.199 with SMTP id l7mr12441233bko.11.1379089279378;
Fri, 13 Sep 2013 09:21:19 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.204.72.69 with HTTP; Fri, 13 Sep 2013 09:21:19 -0700 (PDT)
Date: Fri, 13 Sep 2013 18:21:19 +0200
X-Google-Sender-Auth: q9fGH-brA8RB6kLDCSj9NQOrPTw
Message-ID: <CANEZrP1xWjxcjNYAXKUvsCLgZ8z5CiLkox=aRPDHCJ+Bvn+mHA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a113351949c986404e6463ea1
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
X-Headers-End: 1VKW7a-0006le-CX
Subject: [Bitcoin-development] Bluetooth on Android
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, 13 Sep 2013 16:21:27 -0000
--001a113351949c986404e6463ea1
Content-Type: text/plain; charset=UTF-8
Just a heads up,
Over a year ago Andreas and I prototyped bluetooth tx submission on Android
at a hackfest in Berlin, and it will be with support on-by-default for the
sending side soon. That means, anyone can enable the feature in the
settings page and start receiving payments via Bluetooth as long as both
sides use the Bitcoin Wallet app.
The protocol used is a set of proprietary things. Once the payment protocol
is implemented in bitcoinj, I guess we will recast the bluetooth support to
use that and then submit a BIP for it, but right now it wouldn't make sense
to do so as we know the current protocol has a limited lifespan.
Send via bluetooth resolves one of the most common UX fails we see here in
Europe: people travel to conferences or events and then want to spend their
Bitcoins whilst they're abroad, but they can't reasonably do so because
data roaming is so expensive. By allowing the receiver i.e. merchant to
receive the tx via Bluetooth, this problem is avoided - often the receiver
is local and will be able to broadcast the transaction on your behalf.
Briefly, we use an unauthenticated RFCOMM socket with the adapter MAC
address in a new btcmac parameter in the bitcoin: URI qrcode. No pairing is
required. MITM attacks on the connection are possible, but all that's done
with it is writing raw tx bytes out over the connection so MITM is limited
to DoS.
--001a113351949c986404e6463ea1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Just a heads up,<div><br></div><div>Over a year ago Andrea=
s and I prototyped bluetooth tx submission on Android at a hackfest in Berl=
in, and it will be with support on-by-default for the sending side soon. Th=
at means, anyone can enable the feature in the settings page and start rece=
iving payments via Bluetooth as long as both sides use the Bitcoin Wallet a=
pp.</div>
<div><br></div><div>The protocol used is a set of proprietary things. Once =
the payment protocol is implemented in bitcoinj, I guess we will recast the=
bluetooth support to use that and then submit a BIP for it, but right now =
it wouldn't make sense to do so as we know the current protocol has a l=
imited lifespan.</div>
<div><br></div><div>Send via bluetooth resolves one of the most common UX f=
ails we see here in Europe: people travel to conferences or events and then=
want to spend their Bitcoins whilst they're abroad, but they can't=
reasonably do so because data roaming is so expensive. =C2=A0By allowing t=
he receiver i.e. merchant to receive the tx via Bluetooth, this problem is =
avoided - often the receiver is local and will be able to broadcast the tra=
nsaction on your behalf.<br>
</div><div><br></div><div>Briefly, we use an unauthenticated RFCOMM socket =
with the adapter MAC address in a new btcmac parameter in the bitcoin: URI =
qrcode. No pairing is required. MITM attacks on the connection are possible=
, but all that's done with it is writing raw tx bytes out over the conn=
ection so MITM is limited to DoS.</div>
</div>
--001a113351949c986404e6463ea1--
|
