Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJTBH-0003pK-4e for bitcoin-development@lists.sourceforge.net; Thu, 05 Feb 2015 20:37:47 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of airbitz.co designates 209.85.212.179 as permitted sender) client-ip=209.85.212.179; envelope-from=paul@airbitz.co; helo=mail-wi0-f179.google.com; Received: from mail-wi0-f179.google.com ([209.85.212.179]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJTBE-0003oI-IK for bitcoin-development@lists.sourceforge.net; Thu, 05 Feb 2015 20:37:43 +0000 Received: by mail-wi0-f179.google.com with SMTP id l15so385192wiw.0 for ; Thu, 05 Feb 2015 12:37:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DONLSinYyx8MoiYTFM2lejlOchOwVBKmRAjlQPM8peA=; b=NgUxMJfTO1zS7UKFq2caXTnWcMzWMhz2iuMe08iwWgYvNao08BjhsQGAEobmYxFonZ yFvWM5/8EyBL6xnVNu9GmA58OqBO8Jbezs++fNDgdKFQw8QnXrrvZbpFN2cQl7mJ1CYn 1xZyFngx8S/Do7x6GJ0rR2MHCAQlnjnn4Nw6FBURCmbQUtNkOtShrAGGhM/cVAyKwofU lvooiKDxQL9KbUakGlQH60SnhUdb4DKwUBzAEuLSU1TY5awCZ0Ei2ehTTlSECcAg5KFN 6JFFF3ssXwlWKu3UuS7rquEAd9J3kZ3Oqx8iKpiE6ri3UegM3ojq9/tqrI6QnNXOHMPr 4eUg== X-Gm-Message-State: ALoCoQl8+OiP45oOKyQ/U516B5/F1iGE/LT4hBS8eAQFXAe5DUUvp7NI1wc0vPzroOBMX/kdxVwA X-Received: by 10.180.20.226 with SMTP id q2mr48834wie.28.1423168654423; Thu, 05 Feb 2015 12:37:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.37.137 with HTTP; Thu, 5 Feb 2015 12:37:14 -0800 (PST) X-Originating-IP: [64.245.0.218] In-Reply-To: References: From: Paul Puey Date: Thu, 5 Feb 2015 12:37:14 -0800 Message-ID: To: Mike Hearn Content-Type: multipart/alternative; boundary=bcaec53d55ed1a506a050e5d46a7 X-Spam-Score: -0.4 (/) 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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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.2 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YJTBE-0003oI-IK Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI 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: Thu, 05 Feb 2015 20:37:47 -0000 --bcaec53d55ed1a506a050e5d46a7 Content-Type: text/plain; charset=UTF-8 Thanks for CC'ing me Mike. Having trouble receiving maillist list posts. Even if a user could get the BIP70 URL in the URI, they would still need internet to access the URL. This BLE spec doesn't preclude BIP70, but can work with it while still allowing individuals without a certificate to broadcast a request. The issue of confused payments becomes less so if the Recipient broadcasts a name along with the 10 digit public addr prefix. Only if there is a name conflict will the user have to be concerned with the prefix. The name can be something like Mikes Coffee #1 and it can have a "Register #1" at the counter. A customer facing screen can also show the 10 digit prefix. [image: logo] *Paul Puey* CEO / Co-Founder, Airbitz Inc +1-619-850-8624 | http://airbitz.co | San Diego *DOWNLOAD THE AIRBITZ WALLET:* On Thu, Feb 5, 2015 at 12:28 PM, Mike Hearn wrote: > BIP70 requests can be sent over bluetooth as well, as can transactions. > Bitcoin Wallet can already send money even when offline by doing this. It's > transparent to the user. I mean original Bluetooth in this context - BLE > has incredibly tight data constraints and isn't really meant for data > transfer. > > Yes Android Beam has a pretty stupid UI. You can actually tap the devices, > take them away and then press, but that's not obvious at all. There have > been new APIs added in recent releases that give more control over this, so > it's possible we can revisit things and make the UI better these days. > > The donation to live performer example is good - there's no issue of > accidentally paying for someone else in this context as there's only one > recipient, but many senders. > > The issue of confused payments remains in other situations though. > > For the coffee shop use case, it'd be nicer (I think) if we aim for a > Square-style UI where the device broadcasts a (link to) a photo of the user > combined with a bluetooth MAC. Then the merchant tablet can show faces of > people in the shop, and can push a payment request to the users device. > That device can then buzz the user, show a confirmation screen, put > something on their smart watch etc or just auto-authorise the payment > because the BIP70 signature is from a trusted merchant. User never even > needs to touch their phone at all. > > On Thu, Feb 5, 2015 at 9:06 PM, Paul Puey wrote: > >> The BIP70 protocol would preclude individuals from utilizing the P2P >> transfer spec. It would also require that a Sender have internet >> connectivity to get the payment protocol info. BLE could enable payment w/o >> internet by first transferring the URI to from Recipient to Sender. Then in >> the future, we could sign a Tx and send it over BLE back to the recipient >> (who would still need internet to verify the Tx). This is an important use >> case for areas with poor 3G/4G connectivity as I've experience myself. >> >> Also, due to Android issues, NFC is incredibly clunky. The URI Sender is >> required to tap the screen *while* the two phones are in contact. We >> support NFC the same way Bitcoin Wallet does, but unless the payment >> recipient has a custom Android device (which a merchant might) then the >> usage model is worse than scanning a QR code. BLE also allows people to pay >> at a distance such as for a donation to a live performer. We'll look at >> adding this to the Motivation section. >> >> [image: logo] >> *Paul Puey* CEO / Co-Founder, Airbitz Inc >> +1-619-850-8624 | http://airbitz.co | San Diego >> >> >> >> >> *DOWNLOAD THE AIRBITZ WALLET:* >> >> >> >> >> From: Andreas Schildbach - 2015-02-05 13:47:04 >> >> Thanks Paul, for writing up your protocol! >> >> First thoughts: >> >> For a BIP standard, I think we should skip "bitcoin:" URIs entirely and >> publish BIP70 payment requests instead. URIs mainly stick around because >> of QR codes limited capacity. BIP70 would partly address the "copycat" >> problem by signing payment requests. >> >> In your Motivation section, I miss some words about NFC. NFC already >> addresses all of the usability issues mentioned and is supported by >> mobile wallets since 2011. That doesn't mean your method doesn't make >> sense in some situations, but I think it should be explained why to >> prefer broadcasting payment requests over picking them up via near field >> radio. >> >> >> >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming. The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is >> your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net/ >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > --bcaec53d55ed1a506a050e5d46a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for CC'ing me Mike. Having trouble receiving ma= illist list posts.

Even if a user could get the BIP70 URL in the URI, they would still= need internet to access the URL. This BLE spec doesn't preclude BIP70,= but can work with it while still allowing individuals without a certificat= e to broadcast a request.

The issue of confused payments becomes less so if the Recipient broadc= asts a name along with the 10 digit public addr prefix. Only if there is a = name conflict will the user have to be concerned with the prefix. The name = can be something like=C2=A0

Mikes Coffee #1 and it can have a "Register #1" at the cou= nter. A customer facing screen can also show the 10 digit prefix.

=

=
3D"logo"=C2=A0=C2=A0=C2=A0
Paul Puey=C2=A0CEO / Co-Founder, A= irbitz Inc
+1-6= 19-850-8624=C2=A0|=C2=A0http://airbitz= .co=C2=A0= |=C2=A0San Diego
=C2=A03D""=C2=A0=C2=A0=C2=A03D""=C2=A03D""=
DOWNLOAD THE AIRBITZ WA= LLET:
=C2=A0




On Thu, Feb 5, 2015 at 12:28 PM, Mike Hearn = <= mike@plan99.net> wrote:
BIP70 requests can be sent over bl= uetooth as well, as can transactions. Bitcoin Wallet can already send money= even when offline by doing this. It's transparent to the user. I mean = original Bluetooth in this context - BLE has incredibly tight data constrai= nts and isn't really meant for data transfer.

Yes Android Beam has a pretty s= tupid UI. You can actually tap the devices, take them away and then press, = but that's not obvious at all. There have been new APIs added in recent= releases that give more control over this, so it's possible we can rev= isit things and make the UI better these days.

The donation to live performer exa= mple is good - there's no issue of accidentally paying for someone else= in this context as there's only one recipient, but many senders.
=

The issue o= f confused payments remains in other situations though.

For the coffee shop use c= ase, it'd be nicer (I think) if we aim for a Square-style UI where the = device broadcasts a (link to) a photo of the user combined with a bluetooth= MAC. Then the merchant tablet can show faces of people in the shop, and ca= n push a payment request to the users device. That device can then buzz the= user, show a confirmation screen, put something on their smart watch etc o= r just auto-authorise the payment because the BIP70 signature is from a tru= sted merchant. User never even needs to touch their phone at all.

On Thu, Feb 5, 2015 at 9:06 PM, Paul Puey <= ;paul@airbitz.co&g= t; wrote:
The BIP= 70 protocol would preclude individuals from utilizing the P2P transfer spec= . It would also require that a Sender have internet connectivity to get the= payment protocol info. BLE could enable payment w/o internet by first tran= sferring the URI to from Recipient to Sender. Then in the future, we could = sign a Tx and send it over BLE back to the recipient (who would still need = internet to verify the Tx). This is an important use case for areas with po= or 3G/4G connectivity as I've experience myself.

Als= o, due to Android issues, NFC is incredibly clunky. The URI Sender is requi= red to tap the screen *while* the two phones are in contact. We support NFC= the same way Bitcoin Wallet does, but unless the payment recipient has a c= ustom Android device (which a merchant might) then the usage model is worse= than scanning a QR code. BLE also allows people to pay at a distance such = as for a donation to a live performer. We'll look at adding this to the= Motivation section.

3D"logo"=C2=A0=C2=A0=C2=A0
= 		Paul Pu= ey=C2=A0CEO / Co-Founder, Airbitz Inc
+1-6= 19-850-8624=C2=A0|=C2=A0http://airb= itz.co=C2= =A0|=C2=A0San Diego
=C2=A03D""=C2=A0=C2=A0=C2=A03D""=C2= =A03D=
DOWNLOAD THE AIRBITZ W= ALLET:
=C2=A0


From: Andreas Schil= dbach <andreas@sc...> - 2015-02-05 13:47:04
Thanks Paul, for writing up your protocol!

First thoughts:

For a BIP standard, I think we should skip "bitcoin:" URIs entire=
ly and
publish BIP70 payment requests instead. URIs mainly stick around because
of QR codes limited capacity. BIP70 would partly address the "copycat&=
quot;
problem by signing payment requests.

In your Motivation section, I miss some words about NFC. NFC already
addresses all of the usability issues mentioned and is supported by
mobile wallets since 2011. That doesn't mean your method doesn't ma=
ke
sense in some situations, but I think it should be explained why to
prefer broadcasting payment requests over picking them up via near field
radio.


-----------------------------------------------------------------------= -------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is you= r
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a<= br> look and join the conversation now. http://goparallel.sourceforge.net/
_______= ________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



--bcaec53d55ed1a506a050e5d46a7--