From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJHrb-00075H-2u for bitcoin-development@lists.sourceforge.net; Thu, 05 Feb 2015 08:32:39 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of airbitz.co designates 74.125.82.171 as permitted sender) client-ip=74.125.82.171; envelope-from=paul@airbitz.co; helo=mail-we0-f171.google.com; Received: from mail-we0-f171.google.com ([74.125.82.171]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJHrY-00031i-CR for bitcoin-development@lists.sourceforge.net; Thu, 05 Feb 2015 08:32:39 +0000 Received: by mail-we0-f171.google.com with SMTP id k11so6289272wes.2 for ; Thu, 05 Feb 2015 00:32:30 -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=cXQuqE9A5ihhdTh67a84P23mJY8j7FhXF+8UAmlnYLo=; b=Su6WmjiI806C/s8/QJRgDMehYthuD8RG6qzgd8+ezz3DbU3K6Gz21et74bbgS6xW8S Sc43zFYAUPy7H3h4iUyEd/K/SBQtqPVmcV/CwHgYYgIMQ2dLJ0i6b/hiLBMqTm3H/QUd x8SIvOuq6hWno7nMkaWrQ5G8slB5mTwnP1XjwfOOWNl/zfmAShM2yFtcRs7dhWFc1pxI cXjN+oWZWGSNBn3EraTUyLDdTB4p2Djeoe1YCOQDZAoqqyq1BHHbrE4hiJrjxsbFU0zo YB1C9gcPWW8Eh0kfUFhInWsqd3Rwh5IpYp8JQ0/bU01DEq0ueLeKmknQF24g1lkmbgNg XafQ== X-Gm-Message-State: ALoCoQm10W8cxes8r471apgX+Y9B3cEhpc2v6U2AqMqoWiAhVpA8JmQ/A0Jozo5sl3oGuCt+UB/J X-Received: by 10.180.74.52 with SMTP id q20mr1312688wiv.0.1423123312165; Thu, 05 Feb 2015 00:01:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.37.137 with HTTP; Thu, 5 Feb 2015 00:01:31 -0800 (PST) X-Originating-IP: [98.210.17.60] From: Paul Puey Date: Thu, 5 Feb 2015 00:01:31 -0800 Message-ID: To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=f46d043890797e5d8f050e52b7aa X-Spam-Score: 0.3 (/) 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.9 THIS_AD "This ad" and variants X-Headers-End: 1YJHrY-00031i-CR Subject: [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 08:32:39 -0000 --f46d043890797e5d8f050e52b7aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Airbitz has developed and implemented a method for communicating a bitcoin URI across Bluetooth (BLE) or any other P2P, mid range, wireless, broadcast medium. The currently documented implementation is available in our iOS and Android mobile wallet (updated Android version with BLE coming in about 1 week). We would like to have the BIP pulled into Github for review and discussion. Here is the current BIP: BIP: TBD Title: P2P Wireless URI transfer Authors: Thomas Baker , Paul Puey Contributors: Joey Krug Status: proposal Type: Standards Track Created: 2015-01-12 Table of Contents - Abstract - Motivation - Specification - Compatibility - Examples - References Abstract This is a protocol for peer-to-peer wireless transfer of a URI request using an open broadcast or advertisement channel such as Bluetooth, Bluetooth Low Energy, or WiFi Direct. Motivation There are disadvantages for a merchant (requester) and customer (sender) to exchange a URI request using QR codes that can be eliminated by using wireless broadcast or advertisements. Current QR code scan method to transfer a request URI from merchant (Requester) to customer (Sender) is cumbersome. A usual scenario is a merchant with a POS terminal for order entry and a separate tablet for transacting payments with bitcoin, and a customer with a smartphone. After the order is entered, the merchant enters payment request information into the tablet, generates the QR code representing the URI, and presents this to the customer. The customer prepares to scan the QR code with their smartphone by maneuvering the camera to the tablet. The tablet screen must be relatively clean, point at the customer, and held steady. The smartphone camera lens must be clean, point at the tablet screen, come into range, and held steady to focus and wait for a QR scan. Environmental conditions such as bright outdoor sunlight, indoor spot lights, or significant distance between QR code and camera can create difficult and cumbersome experiences for users. Using a wireless local broadcast allows the merchant to just enter the payment and wait. The tablet and smartphone are not maneuvered to align in any way. The customer observes broadcast listings, selects the appropriate one from possible simultaneous broadcasts from other POS stations nearby, examines the URI request details such as amount, and decides whether to send funds, initiating a bitcoin network transfer. The merchant and customer then receive the transaction confirmations and are done with the sale. Merchant and customer devices are kept private and secured in their own possession. The URI and other broadcast identification (Joe=E2=80=99s Grill #1) only co= ntain public information. However, a copycat broadcaster acting as MITM might duplicate the broadcast simultaneously as the merchant, attempting to lure the customer to send funds to the copycat. That attack is mitigated with this broadcast method because of the partial address in the broadcast. Specification Requester generates a bitcoin URI request of variable length, and a limited descriptive identifier string. Requester then broadcasts the URI=E2=80=99s = partial public address () plus identifier () over a publicly visible wireless channel. Sender scans for broadcasts on their device, examines and selects the desired request by the identifier and partial address. This connects a data channel to Requester. Requester sends full URI back over the data channel. Sender device ensures is part of the full URI public address and checks the full address integrity. Checking the broadcast and full URI integrity prevents a copycat device within range from copying the partial address and fooling the customer into sending funds to the copycat instead. Below is a description of the protocol through Bluetooth Smart (Low Energy)= . Requestor Sender - Bitcoin transaction roles Peripheral Central - Bluetooth GAP definitions Mode Mode 1 |------------->| - Requestor Advertises partial bitcoin: URI + Name | ... | 2 |<-------------| - Subscribe then send sender's Name, requesting a response 3 |------------->| - ACK 4 |<-------------| - request Read Characteristic from peripheral 5 |------------->| - Sender receives full bitcoin: URI 1. Peripheral advertises over a service UUID a BLE extended advertisement with a Scan Response containing the partial address of a bitcoin URI and= a Name, any plain text. The entire response is limited to 26 characters. T= he first 10 make up the first 10 characters of the bitcoin URI public addre= ss where to send bitcoin, and must be present. The remaining characters are any plain text such as =E2=80=9CThe Habit 1=E2=80=9D or =E2=80=9CStarbuc= ks-Reg 1=E2=80=9D, more human readable information. The partial address serves as a check against a nearby attacker who may try to lure a Sender into sending payment to a separate wallet by advertising a similar Scan Response but cannot replic= ate a public address with the same leading 10 characters and different trail= ing characters. 2. When the Central scans the advertisement, it may display the Scan Response in a human readable listing using the two pieces of information= . If Central chooses this advertisement to receive the full request, it th= en subscribes to the service and writes the characteristic (a second UUID) with it=E2=80=99s own name, or a blank if not sending a name, to the Per= ipheral. 3. Peripheral gets a characteristic write request of the Central=E2=80=99s = name, and acknowledges the receipt by sending a server response. 4. Central receives a characteristic write (from the response) and immediately requests the entire bitcoin URI by issuing a read request on that characteristic. 5. Peripheral receives the read request and sends the entire bitcoin URI over that characteristic up to 512 bytes. This ends the proposed specification as the bitcoin URI transfer is complete. The Sender would then normally confirm the request and decide whether to initiate the fund transfer. Compatibility There are no prior BIPs covering this. Examples Airbitz iOS Bluetooth Low Energy to Bluetooth Low Energy request transfer. References [image: logo] *Paul Puey* CEO / Co-Founder, Airbitz Inc +1-619-850-8624 | http://airbitz.co | San Diego *DOWNLOAD THE AIRBITZ WALLET:* --f46d043890797e5d8f050e52b7aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Airbitz has developed and implemented a method for communi= cating a bitcoin URI across Bluetooth (BLE) or any other P2P, mid range, wi= reless, broadcast medium. The currently documented implementation is availa= ble in our iOS and Android mobile wallet (updated Android version with BLE = coming in about 1 week). We would like to have the BIP pulled into Github f= or review and discussion. Here is the current BIP:


<= div>BIP: TBD<= /span>

Title: P2P Wireless URI transfer

Authors: Thomas Baker <tom=E2=80= =99at=E2=80=99airbitz.co>, Paul Puey &= lt;paul=E2=80=99at=E2=80=99airbitz.co>=

Contributors: Joey Krug <joeykrug=E2=80=99at=E2=80=99gmail.com>

Status: proposal

Type: Standards Trac= k

Created: 2015-01-12


Table of Contents

<= ul style=3D"margin-top:0pt;margin-bottom:0pt">

  • Abstract<= /span>

  • Motivation

  • Specification

  • Compatibility=

  • Examples

  • = References

    • Abstract=

    This is a protocol for peer-to-peer wireless transfer of a URI r= equest using an open broadcast or advertisement channel such as Bluetooth, = Bluetooth Low Energy, or WiFi Direct.

    Motivation

    = There are disadvantages for a merchant (requester) and customer (sender) to= exchange a URI request using QR codes that can be eliminated by using wire= less broadcast or advertisements.

    Current QR code scan meth= od to transfer a request URI from merchant (Requester) to customer (Sender)= is cumbersome. A usual scenario is a merchant with a POS terminal for orde= r entry and a separate tablet for transacting payments with bitcoin, and a = customer with a smartphone. After the order is entered, the merchant enters= payment request information into the tablet, generates the QR code represe= nting the URI, and presents this to the customer. The customer prepares to = scan the QR code with their smartphone by maneuvering the camera to the tab= let. The tablet screen must be relatively clean, point at the customer, and= held steady. The smartphone camera lens must be clean, point at the tablet= screen, come into range, and held steady to focus and wait for a QR scan. = Environmental conditions such as bright outdoor sunlight, indoor spot light= s, or significant distance between QR code and camera can create difficult = and cumbersome experiences for users.

    Using a wireless loca= l broadcast allows the merchant to just enter the payment and wait. The tab= let and smartphone are not maneuvered to align in any way. The customer obs= erves broadcast listings, selects the appropriate one from possible simulta= neous broadcasts from other POS stations nearby, examines the URI request d= etails such as amount, and decides whether to send funds, initiating a bitc= oin network transfer. The merchant and customer then receive the transactio= n confirmations and are done with the sale. Merchant and customer devices a= re kept private and secured in their own possession.

    The UR= I and other broadcast identification (Joe=E2=80=99s Grill #1) only contain = public information. However, a copycat broadcaster acting as MITM might dup= licate the broadcast simultaneously as the merchant, attempting to lure the= customer to send funds to the copycat. That attack is mitigated with this = broadcast method because of the partial address in the broadcast.

    Sp= ecification

    Requester generates a bitcoin URI request of v= ariable length, and a limited descriptive identifier string. Requester then= broadcasts the URI=E2=80=99s partial public address (<paddress>) plu= s identifier (<id>) over a publicly visible wireless channel.<= /p>

    Sender scans for broadcasts on their device, examines and selects = the desired request by the identifier and partial address. This connects a = data channel to Requester.

    Requester sends full URI back ov= er the data channel.

    Sender device ensures <paddress>= is part of the full URI public address and checks the full address integri= ty. Checking the broadcast and full URI integrity prevents a copycat device= within range from copying the partial address and fooling the customer int= o sending funds to the copycat instead.

    Below is a descrip= tion of the protocol through Bluetooth Smart (Low Energy).

    = Requestor =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Sender =C2=A0=C2=A0=C2=A0=C2=A0- B= itcoin transaction roles

    Peripheral =C2=A0=C2=A0=C2=A0=C2= =A0Central =C2=A0=C2=A0=C2=A0- Bluetooth GAP definitions

    = =C2=A0=C2=A0Mode =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Mode

    1 =C2=A0=C2=A0|------------->| =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0- Requestor Advertises partial bitcoin: URI + Name

    =C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0... =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    = 2 =C2=A0=C2=A0|<-------------| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- Sub= scribe then send sender's Name, requesting a response

    = 3 =C2=A0=C2=A0|------------->| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- ACK=

    4 =C2=A0=C2=A0|<-------------| =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0- request Read Characteristic from peripheral

    = 5 =C2=A0=C2=A0|------------->| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- Sen= der receives full bitcoin: URI


    1. Peripheral advertises ove= r a service UUID a BLE extended advertisement with a Scan Response containi= ng the partial address of a bitcoin URI and a Name, any plain text. The ent= ire response is limited to 26 characters. The first 10 make up the first 10= characters of the bitcoin URI public address where to send bitcoin, and mu= st be present. The remaining characters are any plain text such as =E2=80= =9CThe Habit 1=E2=80=9D or =E2=80=9CStarbucks-Reg 1=E2=80=9D, more human re= adable information. The partial address serves as a check against a nearby = attacker who may try to lure a Sender into sending payment to a separate wa= llet by advertising a similar Scan Response but cannot replicate a public a= ddress with the same leading 10 characters and different trailing character= s.

    2. When the Central scans t= he advertisement, it may display the Scan Response in a human readable list= ing using the two pieces of information. If Central chooses this advertisem= ent to receive the full request, it then subscribes to the service and writ= es the characteristic (a second UUID) with it=E2=80=99s own name, or a blan= k if not sending a name, to the Peripheral.

    3. Peripheral gets a characteristic write request of the Cent= ral=E2=80=99s name, and acknowledges the receipt by sending a server respon= se.

    4. Central receives a char= acteristic write (from the response) and immediately requests the entire bi= tcoin URI by issuing a read request on that characteristic.

      5. =

    5. Peripheral receives the read request and = sends the entire bitcoin URI over that characteristic up to 512 bytes.

    This ends the proposed specification as the bitcoin U= RI transfer is complete. The Sender would then normally confirm the request= and decide whether to initiate the fund transfer.

    Compatibility

    There are no prior BIPs covering this.

    Examples

    Airb= itz iOS Bluetooth Low Energy to Bluetooth Low Energy request transfer.

    References




    <= div class=3D"gmail_signature">
    <= div dir=3D"ltr">

    3D"logo"=C2=A0=C2=A0=C2=A0
    		Paul Puey= =C2=A0CEO / Co-Founder,= Airbitz Inc
    <= a style=3D"color:rgb(128,128,128);outline:none;text-decoration:none">+1-619-850-8624=C2=A0|=C2=A0http://airbit= z.co=C2= =A0|=C2=A0San Diego
    =C2=A03D""=C2=A0=C2=A0=C2=A0=C2=A0
    = DOWNLOAD THE AI= RBITZ WALLET:
    =C2=A0<= /span>=



    --f46d043890797e5d8f050e52b7aa--