{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-01-27\n📝 Original message:Thanks Andreas, that's really interesting work. Comments below.\n\nOn Mon, Jan 27, 2014 at 12:59 PM, Andreas Schildbach\n\u003candreas at schildbach.de\u003ewrote:\n\n\u003e Because I could not find any standard for Bluetooth URLs, I made\n\u003e up my own: \"bt:112233445566\" means MAC address 11:22:33:44:55:66.\n\n\nI would like to see Bluetooth continue to work for scan-to-pay even in the\nsigned case. So for this reason the current approach with a BTMAC parameter\nin the Bitcoin URI seems to work universally across NFC tags and QR codes,\nand would allow download of a signed PaymentRequest even in the case where\na QR code is used.\n\nBecause a Bitcoin URI already contains a public key (hash), re-using that\nto establish an encrypted/authd connection on top of an insecure RFCOMM\nsocket would seem to be relatively straightforward.\n\n\n\u003e Obviously such QR-encoded payment requests cannot grow in size as much\n\u003e as using other media. In particular, I expect PKI signed requests are\n\u003e out of question. However, in face to face payments the value of a sig\n\u003e based on PKI is highly questionable, and the fact the sig cannot be\n\u003e verified without TCP connectivity doesn't help.\n\u003e\n\nJust a correction here - the reason signed payment requests are \"large\"\n(about 4000 bytes) is exactly because they *can* be verified offline, i.e.\nby a Trezor. The signed payment request contains all the data needed to\nestablish its authenticity, including certificates and the signature\nitself. No TCP connection is needed.\n\nFor face to face payments, I think signing is still useful. For one, we\nwant to keep the distinction between \"merchant\" and \"user\" as blurry and\nindistinct as possible. A strong separation between merchants and consumers\nis one of the many bad things about the credit card system. Whilst\ninitially we'd expect the payment protocol to be used by online webshops,\nin future it could be used by little corner shops, children's lemonade\nstands and so on. You don't want to exclude entire classes of transactions\nfrom being secure with Trezor type devices, and besides, even without a\nTrezor you probably still would like a receipt if you buy something from a\nlocal market trader.\n\nAnother use case - we heard a story about a restaurant owner who accepted\nBitcoin. He printed a static bitcoin URI onto a QR code on the menu. A\nmonth or two later he discovered one of his waiters had re-printed the\nmenus with his own QR code! The people thought they had been paying for the\nmeal, and in fact it went right into the pocket of the waiter.\n\nAs to how it works, well, that's not hard. Comodo give away free email\naddress certs with a few mouse clicks, it's no harder than signing up for a\nwebsite. Then you can just open that cert file on your phone to install it\nand it should become usable automatically with a future version of\nbitcoinj. Email address doesn't prove a whole lot, of course, but it's\nbetter than nothing. If the restaurant owner had even just a hotmail\naddress, he could have stuck it up behind the bar or painted it on the\noutside of his shop and some customer would have got suspicious when he\ndidn't see the address (assuming we're successful at deploying it of\ncourse).\n\n\n\u003e - I chose to re-use the \"bitcoin:\" URL scheme\n\u003e\n\nOther wallets won't know what to do with it and would yield a strange error\nmessage.\n\n\n\u003e Finally this is the usecase the payment protocol was invented for and\n\u003e it's not face-to-face. I don't have much to add, just one thing. As a\n\u003e byproduct of the above, \"payment protocol URLs\" can be used for links\n\u003e published on web pages as well. This might provide a nice replacement\n\u003e for the imho rather ugly BIP72 specification once the payment protocol\n\u003e is widely deployed.\n\n\nURL length is limited on some versions of internet explorer (probably on\nall browsers). Rather than pack a file into a URL, if you don't want to use\nthe current r= extension it's better for apps to just register to handle\n.bitcoinpaymentrequest files / the right MIME type. Downloading it and\nopening it would do the right thing automatically.\n\nRemember BIP 73 also! It says that with the apps built-in QR scanner, if\nyou scan an HTTP[S] URI, you should try downloading it with a magic header.\nThat way you can get a payment request file out of the server. Without the\nmagic header (i.e.  a normal generic barcode scanner app) it would open a\nweb page containing a bitcoin URI clickable link.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140127/55485834/attachment.html\u003e"}