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