{"type":"rich","version":"1.0","author_name":"npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7","author_url":"https://nostr.ae/npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-02-05\n📝 Original message:Thanks Paul, for writing up your protocol!\n\nFirst thoughts:\n\nFor a BIP standard, I think we should skip \"bitcoin:\" URIs entirely and\npublish BIP70 payment requests instead. URIs mainly stick around because\nof QR codes limited capacity. BIP70 would partly address the \"copycat\"\nproblem by signing payment requests.\n\nIn your Motivation section, I miss some words about NFC. NFC already\naddresses all of the usability issues mentioned and is supported by\nmobile wallets since 2011. That doesn't mean your method doesn't make\nsense in some situations, but I think it should be explained why to\nprefer broadcasting payment requests over picking them up via near field\nradio.\n\n\nOn 02/05/2015 09:01 AM, Paul Puey wrote:\n\u003e Airbitz has developed and implemented a method for communicating a\n\u003e bitcoin URI across Bluetooth (BLE) or any other P2P, mid range,\n\u003e wireless, broadcast medium. The currently documented implementation is\n\u003e available in our iOS and Android mobile wallet (updated Android version\n\u003e with BLE coming in about 1 week). We would like to have the BIP pulled\n\u003e into Github for review and discussion. Here is the current BIP:\n\u003e \n\u003e \n\u003e BIP: TBD\n\u003e \n\u003e Title: P2P Wireless URI transfer\n\u003e \n\u003e Authors: Thomas Baker \u003ctom’at’airbitz.co \u003chttp://airbitz.co\u003e\u003e, Paul Puey\n\u003e \u003cpaul’at’airbitz.co \u003chttp://airbitz.co\u003e\u003e\n\u003e \n\u003e Contributors: Joey Krug \u003cjoeykrug’at’gmail.com \u003chttp://gmail.com\u003e\u003e\n\u003e \n\u003e Status: proposal\n\u003e \n\u003e Type: Standards Track\n\u003e \n\u003e Created: 2015-01-12\n\u003e \n\u003e \n\u003e     Table of Contents\n\u003e \n\u003e   *\n\u003e \n\u003e     Abstract\n\u003e \n\u003e   *\n\u003e \n\u003e     Motivation\n\u003e \n\u003e   *\n\u003e \n\u003e     Specification\n\u003e \n\u003e   *\n\u003e \n\u003e     Compatibility\n\u003e \n\u003e   *\n\u003e \n\u003e     Examples\n\u003e \n\u003e   *\n\u003e \n\u003e     References\n\u003e \n\u003e \n\u003e     Abstract\n\u003e \n\u003e This is a protocol for peer-to-peer wireless transfer of a URI request\n\u003e using an open broadcast or advertisement channel such as Bluetooth,\n\u003e Bluetooth Low Energy, or WiFi Direct.\n\u003e \n\u003e \n\u003e     Motivation\n\u003e \n\u003e There are disadvantages for a merchant (requester) and customer (sender)\n\u003e to exchange a URI request using QR codes that can be eliminated by using\n\u003e wireless broadcast or advertisements.\n\u003e \n\u003e Current QR code scan method to transfer a request URI from merchant\n\u003e (Requester) to customer (Sender) is cumbersome. A usual scenario is a\n\u003e merchant with a POS terminal for order entry and a separate tablet for\n\u003e transacting payments with bitcoin, and a customer with a smartphone.\n\u003e After the order is entered, the merchant enters payment request\n\u003e information into the tablet, generates the QR code representing the URI,\n\u003e and presents this to the customer. The customer prepares to scan the QR\n\u003e code with their smartphone by maneuvering the camera to the tablet. The\n\u003e tablet screen must be relatively clean, point at the customer, and held\n\u003e steady. The smartphone camera lens must be clean, point at the tablet\n\u003e screen, come into range, and held steady to focus and wait for a QR\n\u003e scan. Environmental conditions such as bright outdoor sunlight, indoor\n\u003e spot lights, or significant distance between QR code and camera can\n\u003e create difficult and cumbersome experiences for users.\n\u003e \n\u003e Using a wireless local broadcast allows the merchant to just enter the\n\u003e payment and wait. The tablet and smartphone are not maneuvered to align\n\u003e in any way. The customer observes broadcast listings, selects the\n\u003e appropriate one from possible simultaneous broadcasts from other POS\n\u003e stations nearby, examines the URI request details such as amount, and\n\u003e decides whether to send funds, initiating a bitcoin network transfer.\n\u003e The merchant and customer then receive the transaction confirmations and\n\u003e are done with the sale. Merchant and customer devices are kept private\n\u003e and secured in their own possession.\n\u003e \n\u003e The URI and other broadcast identification (Joe’s Grill #1) only contain\n\u003e public information. However, a copycat broadcaster acting as MITM might\n\u003e duplicate the broadcast simultaneously as the merchant, attempting to\n\u003e lure the customer to send funds to the copycat. That attack is mitigated\n\u003e with this broadcast method because of the partial address in the broadcast.\n\u003e \n\u003e \n\u003e     Specification\n\u003e \n\u003e Requester generates a bitcoin URI request of variable length, and a\n\u003e limited descriptive identifier string. Requester then broadcasts the\n\u003e URI’s partial public address (\u003cpaddress\u003e) plus identifier (\u003cid\u003e) over a\n\u003e publicly visible wireless channel.\n\u003e \n\u003e Sender scans for broadcasts on their device, examines and selects the\n\u003e desired request by the identifier and partial address. This connects a\n\u003e data channel to Requester.\n\u003e \n\u003e Requester sends full URI back over the data channel.\n\u003e \n\u003e Sender device ensures \u003cpaddress\u003e is part of the full URI public address\n\u003e and checks the full address integrity. Checking the broadcast and full\n\u003e URI integrity prevents a copycat device within range from copying the\n\u003e partial address and fooling the customer into sending funds to the\n\u003e copycat instead.\n\u003e \n\u003e Below is a description of the protocol through Bluetooth Smart (Low Energy).\n\u003e \n\u003e Requestor      Sender     - Bitcoin transaction roles\n\u003e \n\u003e Peripheral     Central    - Bluetooth GAP definitions\n\u003e \n\u003e   Mode           Mode\n\u003e \n\u003e 1   |-------------\u003e|       - Requestor Advertises partial bitcoin: URI +\n\u003e Name\n\u003e \n\u003e    |     ...      |       \n\u003e \n\u003e 2   |\u003c-------------|       - Subscribe then send sender's Name,\n\u003e requesting a response\n\u003e \n\u003e 3   |-------------\u003e|       - ACK\n\u003e \n\u003e 4   |\u003c-------------|       - request Read Characteristic from peripheral\n\u003e \n\u003e 5   |-------------\u003e|       - Sender receives full bitcoin: URI\n\u003e \n\u003e \n\u003e  1.\n\u003e \n\u003e     Peripheral advertises over a service UUID a BLE extended\n\u003e     advertisement with a Scan Response containing the partial address of\n\u003e     a bitcoin URI and a Name, any plain text. The entire response is\n\u003e     limited to 26 characters. The first 10 make up the first 10\n\u003e     characters of the bitcoin URI public address where to send bitcoin,\n\u003e     and must be present. The remaining characters are any plain text\n\u003e     such as “The Habit 1” or “Starbucks-Reg 1”, more human readable\n\u003e     information. The partial address serves as a check against a nearby\n\u003e     attacker who may try to lure a Sender into sending payment to a\n\u003e     separate wallet by advertising a similar Scan Response but cannot\n\u003e     replicate a public address with the same leading 10 characters and\n\u003e     different trailing characters.\n\u003e \n\u003e  2.\n\u003e \n\u003e     When the Central scans the advertisement, it may display the Scan\n\u003e     Response in a human readable listing using the two pieces of\n\u003e     information. If Central chooses this advertisement to receive the\n\u003e     full request, it then subscribes to the service and writes the\n\u003e     characteristic (a second UUID) with it’s own name, or a blank if not\n\u003e     sending a name, to the Peripheral.\n\u003e \n\u003e  3.\n\u003e \n\u003e     Peripheral gets a characteristic write request of the Central’s\n\u003e     name, and acknowledges the receipt by sending a server response.\n\u003e \n\u003e  4.\n\u003e \n\u003e     Central receives a characteristic write (from the response) and\n\u003e     immediately requests the entire bitcoin URI by issuing a read\n\u003e     request on that characteristic.\n\u003e \n\u003e  5.\n\u003e \n\u003e     Peripheral receives the read request and sends the entire bitcoin\n\u003e     URI over that characteristic up to 512 bytes.\n\u003e \n\u003e This ends the proposed specification as the bitcoin URI transfer is\n\u003e complete. The Sender would then normally confirm the request and decide\n\u003e whether to initiate the fund transfer.\n\u003e \n\u003e \n\u003e     Compatibility\n\u003e \n\u003e There are no prior BIPs covering this.\n\u003e \n\u003e \n\u003e     Examples\n\u003e \n\u003e Airbitz iOS Bluetooth Low Energy to Bluetooth Low Energy request transfer.\n\u003e \n\u003e \n\u003e     References\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e \n\u003e logo   \n\u003e \t*Paul Puey* CEO / Co-Founder, Airbitz Inc\n\u003e +1-619-850-8624 | http://airbitz.co \u003chttp://airbitz.co/\u003e | San Diego\n\u003e \u003chttp://facebook.com/airbitz\u003e \u003chttp://twitter.com/airbitz\u003e \u003chttps://plus.google.com/118173667510609425617\u003e \u003chttps://go.airbitz.co/comments/feed/\u003e \u003chttp://linkedin.com/in/paulpuey\u003e \u003chttps://angel.co/paul-puey\u003e\n\u003e \n\u003e *DOWNLOAD THE AIRBITZ WALLET:*\n\u003e  \n\u003e \u003chttps://play.google.com/store/apps/details?id=com.airbitz\u003e\u003chttps://itunes.apple.com/us/app/airbitz/id843536046\u003e\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Dive into the World of Parallel Programming. The Go Parallel Website,\n\u003e sponsored by Intel and developed in partnership with Slashdot Media, is your\n\u003e hub for all things parallel software development, from weekly thought\n\u003e leadership blogs to news, videos, case studies, tutorials and more. Take a\n\u003e look and join the conversation now. http://goparallel.sourceforge.net/\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e"}