From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: From: Mike Hearn To: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Just a heads up,

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.

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.

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.

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.
--001a113351949c986404e6463ea1--