{"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:2014-01-27\n📝 Original message:As promised I'd like to present my work done on leveraging the payment\nprotocol for face-to-face payments. The general assumption is that\nindividuals don't own X.509 certificates. Their devices may be only\nbadly connected to the internet or in some cases not at all. I've\nimplemented a prototype on a branch of Bitcoin Wallet. It is using\nbitcoinj 0.11 (not released).\n\nhttps://github.com/schildbach/bitcoin-wallet/commits/payment-protocol\n\n\nTAP TO PAY\n\nFirst I looked at the NFC tap-to-pay usecase. The way it works as\ncurrently rolled out: A BIP21 URL is published using an NDEF URI\nmessage. The URL is supplemented by a Bluetooth MAC address that can be\nconnected in order to finish the payment. Once connected, a very simple\ncustom protocol transmits the signed transaction(s) in\nbitcoin-serialized form to the payee, who replies with an ack or nack.\n\nThe way I prototyped it to work in future: Instead of the BIP21 URL a\nBIP70 payment request is published using an NDEF MIME message (mime-type\nas per BIP71). The paymentUrl field can (and in the face-to-face case\nshould) contain a Bluetooth URL which contains the MAC address of the\npayee. Because I could not find any standard for Bluetooth URLs, I made\nup my own: \"bt:112233445566\" means MAC address 11:22:33:44:55:66. Once\nconnected, Payment message and PaymentACK reply are used to finish the\npayment. Since Bluetooth sockets are streams, I had to use the delimited\nvariant of the protobufs for Payment and PaymentACK messages. This\nprepends them with a VARINT containing the message length.\n\nAll of the above should be easy to migrate. NFC implementations are\nrare, and the current Bluetooth protocol is implemented only by Bitcoin\nWallet afaik. Fallbacks are provided where necessary.\n\nIn future, I'd like to add encryption to the Bluetooth connection, maybe\nusing SSL and some DH key exchange.\n\n\nSCAN TO PAY\n\nFor scan-to-pay, the current landscape looks different. I assume at\nleast 50% of Bitcoin transactions are initiated by a BIP21 URL encoded\ninto a QR-code. Nevertheless, I tried to encode a payment request into\nthe bitcoin URL. I used my existing work on encoding transactions into\nQR-codes. Steps to encode:\n\n1. The payment request is protobuf-serialized. For a simple payment\nrequest, this results in only ~50 bytes thanks to the efficiency of\nprotobuf.\n2. The bytes are encoded using \"Base43\", which is the same as\nBase64/Base58, but its alphabet consists of the characters allowed in\nso-called \"alphanumeric\" QR-codes, minus the characters not allowed in URLs.\n3. The resulting string is prefixed by \"BITCOIN:\"\n4. All of that goes into a QR-code, and because it only contains\n\"alphanumeric\" characters, it will produce a very efficient code. For\nsimple payment requests, I could not notice any difference in scanning\ndifficulty.\n\nThere are some limitations however:\n\n- Obviously such QR-encoded payment requests cannot grow in size as much\nas using other media. In particular, I expect PKI signed requests are\nout of question. However, in face to face payments the value of a sig\nbased on PKI is highly questionable, and the fact the sig cannot be\nverified without TCP connectivity doesn't help. There should be some\nheadroom for multiple-output requests and moderately more complex\nscripts though.\n\n- I chose to re-use the \"bitcoin:\" URL scheme, because it's already\nwhitelisted in web browsers, QR-code scanners and so on. In order to\ndifferentiate \"payment requests URLs\" from BIP21 URLs, I test for\nuri.startsWith(\"BITCOIN:\") because you'll get letters in all-caps from\nalphanumeric QR-codes. I will investigate into a better solution.\n\n- Due to wide deployment of BIP21 QR-codes, migration needs to happen in\ndistinct phases. Ability to parse \"payment protocol URLs\" comes first,\ndefault to presenting them to users has to come (much) later.\n\n\nCLICK TO PAY\n\nFinally this is the usecase the payment protocol was invented for and\nit's not face-to-face. I don't have much to add, just one thing. As a\nbyproduct of the above, \"payment protocol URLs\" can be used for links\npublished on web pages as well. This might provide a nice replacement\nfor the imho rather ugly BIP72 specification once the payment protocol\nis widely deployed.\n\n\nOpen for discussion."}