{"type":"rich","version":"1.0","author_name":"npub1rjuxg0r8xsxh36myahl6qvzrz2l8ku88cf2ghxej3a2g5wsdlmjq880ac2","author_url":"https://nostr.ae/npub1rjuxg0r8xsxh36myahl6qvzrz2l8ku88cf2ghxej3a2g5wsdlmjq880ac2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-02-05\n📝 Original message:Airbitz has developed and implemented a method for communicating a bitcoin\nURI across Bluetooth (BLE) or any other P2P, mid range, wireless, broadcast\nmedium. The currently documented implementation is available in our iOS and\nAndroid mobile wallet (updated Android version with BLE coming in about 1\nweek). We would like to have the BIP pulled into Github for review and\ndiscussion. Here is the current BIP:\n\n\nBIP: TBD\n\nTitle: P2P Wireless URI transfer\n\nAuthors: Thomas Baker \u003ctom’at’airbitz.co\u003e, Paul Puey \u003cpaul’at’airbitz.co\u003e\n\nContributors: Joey Krug \u003cjoeykrug’at’gmail.com\u003e\n\nStatus: proposal\n\nType: Standards Track\n\nCreated: 2015-01-12\n\nTable of Contents\n\n   -\n\n   Abstract\n   -\n\n   Motivation\n   -\n\n   Specification\n   -\n\n   Compatibility\n   -\n\n   Examples\n   -\n\n   References\n\nAbstract\n\nThis is a protocol for peer-to-peer wireless transfer of a URI request\nusing an open broadcast or advertisement channel such as Bluetooth,\nBluetooth Low Energy, or WiFi Direct.\nMotivation\n\nThere are disadvantages for a merchant (requester) and customer (sender) to\nexchange a URI request using QR codes that can be eliminated by using\nwireless broadcast or advertisements.\n\nCurrent QR code scan method to transfer a request URI from merchant\n(Requester) to customer (Sender) is cumbersome. A usual scenario is a\nmerchant with a POS terminal for order entry and a separate tablet for\ntransacting payments with bitcoin, and a customer with a smartphone. After\nthe order is entered, the merchant enters payment request information into\nthe tablet, generates the QR code representing the URI, and presents this\nto the customer. The customer prepares to scan the QR code with their\nsmartphone by maneuvering the camera to the tablet. The tablet screen must\nbe relatively clean, point at the customer, and held steady. The smartphone\ncamera lens must be clean, point at the tablet screen, come into range, and\nheld steady to focus and wait for a QR scan. Environmental conditions such\nas bright outdoor sunlight, indoor spot lights, or significant distance\nbetween QR code and camera can create difficult and cumbersome experiences\nfor users.\n\nUsing a wireless local broadcast allows the merchant to just enter the\npayment and wait. The tablet and smartphone are not maneuvered to align in\nany way. The customer observes broadcast listings, selects the appropriate\none from possible simultaneous broadcasts from other POS stations nearby,\nexamines the URI request details such as amount, and decides whether to\nsend funds, initiating a bitcoin network transfer. The merchant and\ncustomer then receive the transaction confirmations and are done with the\nsale. Merchant and customer devices are kept private and secured in their\nown possession.\n\nThe URI and other broadcast identification (Joe’s Grill #1) only contain\npublic information. However, a copycat broadcaster acting as MITM might\nduplicate the broadcast simultaneously as the merchant, attempting to lure\nthe customer to send funds to the copycat. That attack is mitigated with\nthis broadcast method because of the partial address in the broadcast.\nSpecification\n\nRequester generates a bitcoin URI request of variable length, and a limited\ndescriptive identifier string. Requester then broadcasts the URI’s partial\npublic address (\u003cpaddress\u003e) plus identifier (\u003cid\u003e) over a publicly visible\nwireless channel.\n\nSender scans for broadcasts on their device, examines and selects the\ndesired request by the identifier and partial address. This connects a data\nchannel to Requester.\n\nRequester sends full URI back over the data channel.\n\nSender device ensures \u003cpaddress\u003e is part of the full URI public address and\nchecks the full address integrity. Checking the broadcast and full URI\nintegrity prevents a copycat device within range from copying the partial\naddress and fooling the customer into sending funds to the copycat instead.\n\nBelow is a description of the protocol through Bluetooth Smart (Low Energy).\n\nRequestor      Sender     - Bitcoin transaction roles\n\nPeripheral     Central    - Bluetooth GAP definitions\n\n  Mode           Mode\n\n1   |-------------\u003e|       - Requestor Advertises partial bitcoin: URI +\nName\n\n   |     ...      |\n\n2   |\u003c-------------|       - Subscribe then send sender's Name, requesting\na response\n\n3   |-------------\u003e|       - ACK\n\n4   |\u003c-------------|       - request Read Characteristic from peripheral\n\n5   |-------------\u003e|       - Sender receives full bitcoin: URI\n\n\n   1.\n\n   Peripheral advertises over a service UUID a BLE extended advertisement\n   with a Scan Response containing the partial address of a bitcoin URI and a\n   Name, any plain text. The entire response is limited to 26 characters. The\n   first 10 make up the first 10 characters of the bitcoin URI public address\n   where to send bitcoin, and must be present. The remaining characters are\n   any plain text such as “The Habit 1” or “Starbucks-Reg 1”, more human\n   readable information. The partial address serves as a check against a\n   nearby attacker who may try to lure a Sender into sending payment to a\n   separate wallet by advertising a similar Scan Response but cannot replicate\n   a public address with the same leading 10 characters and different trailing\n   characters.\n   2.\n\n   When the Central scans the advertisement, it may display the Scan\n   Response in a human readable listing using the two pieces of information.\n   If Central chooses this advertisement to receive the full request, it then\n   subscribes to the service and writes the characteristic (a second UUID)\n   with it’s own name, or a blank if not sending a name, to the Peripheral.\n   3.\n\n   Peripheral gets a characteristic write request of the Central’s name,\n   and acknowledges the receipt by sending a server response.\n   4.\n\n   Central receives a characteristic write (from the response) and\n   immediately requests the entire bitcoin URI by issuing a read request on\n   that characteristic.\n   5.\n\n   Peripheral receives the read request and sends the entire bitcoin URI\n   over that characteristic up to 512 bytes.\n\nThis ends the proposed specification as the bitcoin URI transfer is\ncomplete. The Sender would then normally confirm the request and decide\nwhether to initiate the fund transfer.\nCompatibility\n\nThere are no prior BIPs covering this.\nExamples\n\nAirbitz iOS Bluetooth Low Energy to Bluetooth Low Energy request transfer.\nReferences\n\n\n\n[image: logo]\n*Paul Puey* CEO / Co-Founder, Airbitz Inc\n+1-619-850-8624 | http://airbitz.co | San Diego\n\u003chttp://facebook.com/airbitz\u003e  \u003chttp://twitter.com/airbitz\u003e\n\u003chttps://plus.google.com/118173667510609425617\u003e\n\u003chttps://go.airbitz.co/comments/feed/\u003e  \u003chttp://linkedin.com/in/paulpuey\u003e\n\u003chttps://angel.co/paul-puey\u003e\n*DOWNLOAD THE AIRBITZ WALLET:*\n  \u003chttps://play.google.com/store/apps/details?id=com.airbitz\u003e\n\u003chttps://itunes.apple.com/us/app/airbitz/id843536046\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/a00a4c8a/attachment.html\u003e"}