Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJSht-0001l8-AA for bitcoin-development@lists.sourceforge.net; Thu, 05 Feb 2015 20:07:21 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of airbitz.co designates 209.85.212.177 as permitted sender) client-ip=209.85.212.177; envelope-from=paul@airbitz.co; helo=mail-wi0-f177.google.com; Received: from mail-wi0-f177.google.com ([209.85.212.177]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJShm-0002t8-4o for bitcoin-development@lists.sourceforge.net; Thu, 05 Feb 2015 20:07:21 +0000 Received: by mail-wi0-f177.google.com with SMTP id r20so207444wiv.4 for ; Thu, 05 Feb 2015 12:07:08 -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:from:date:message-id:subject:to :content-type; bh=kUPGHNzPrQTGUCYb8Aj5SeBENTOwQIZCfPdHL/F+PbY=; b=a+VsLcoC2j5bWiNg033Gm6Vn0sHiF8Zufi3pQg+y0vKVvU+MJLIWcQ7upusDqYXWO2 Jgt5YQutiPI0NgG0qr3gqoCpVMTAoWN0JOBIMRE1Q3AeJkmhunFi5A2AElQuZDdtDOmJ BFYUxgczeDFxJ8dwKXGvB9npL2VEBbV3icMY0qbZgdowD1XJqN6U2qAfu5//JNSXF7ap yL5jiu/q21ONhbuFh4lqNHSeiOhCwZXGKIZRS83B8ZObrOdS/paiDOvDP1dAasyG5vgu ssybGP24/l1JMSPncaBGecRLGxr3zcSM/PIbM2VUqNlG+qmFRzUZ5MJvorEb8s3uA1tg h9Eg== X-Gm-Message-State: ALoCoQlRCn44YPvX5+3QBPCvcsk3/ToPMCi0paaS0bhakU45O4QuJh7uSB0idlChABERHpPKwmfB X-Received: by 10.180.228.72 with SMTP id sg8mr376137wic.48.1423166827905; Thu, 05 Feb 2015 12:07:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.37.137 with HTTP; Thu, 5 Feb 2015 12:06:47 -0800 (PST) X-Originating-IP: [64.245.0.218] From: Paul Puey Date: Thu, 5 Feb 2015 12:06:47 -0800 Message-ID: To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=001a1134cc4e3bf87b050e5cd90c X-Spam-Score: -0.6 (/) 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.0 T_REMOTE_IMAGE Message contains an external image X-Headers-End: 1YJShm-0002t8-4o 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:07:21 -0000 --001a1134cc4e3bf87b050e5cd90c Content-Type: text/plain; charset=UTF-8 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. --001a1134cc4e3bf87b050e5cd90c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The BIP70 protocol would preclude individuals from utilizi= ng 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 recipien= t (who would still need internet to verify the Tx). This is an important us= e 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 p= ayment 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 lo= ok at adding this to the Motivation section.

3D"logo"=C2=A0=C2=A0=C2=A0
= Paul Puey=C2=A0CEO / Co-Founder, Airbit= z Inc
=C2=A03D""=C2=A0=C2=A0=C2=A03D""=C2=A03D""=
DOWNLOAD THE AIRBITZ WA= LLET:
=C2=A0


From: Andreas Schildbach <andreas@sc...> - 2015-02-05 13:47:04<= /small>
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.

--001a1134cc4e3bf87b050e5cd90c--