{"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-03-20\n📝 Original message:Very, very limited. The more data you stuff in them, the less reliable and\nslower scanning becomes. A URL is about the limit of what's practically\nachievable. Even with that, BitPay have been complaining about the\nincreased character length from adding the https url to download the\npayment request (though not escaping reduces character count by a lot and\nis valid).\n\nX.509 is extremely bloated, partly due to the number of features it\nsupports, partly due to its history but mostly due to the widespread use of\nRSA which generates giant keys and signatures. Of course you can get ECC\ncerts as well, but in practice most merchants don't seem to use them yet.\nThere's no way you can fit a cert chain into a QR code.\n\nHowever, this is no big deal, because for the serverless PoS device case\nAlex cares about you need a backchannel to submit the transaction and\nrefund address anyway, so Bluetooth is already useful/required. Downloading\nthe payment request via it as well as uploading the response is not a big\nchange and - as mentioned - already implemented by Andreas and myself some\ntime ago.\n\n\n\nOn Thu, Mar 20, 2014 at 1:12 PM, Adam Back \u003cadam at cypherspace.org\u003e wrote:\n\n\u003e Whats a sensible limit on practical/convenient QR code size?\n\u003e\n\u003e How much of the payment protocol message size comes from use of x509?\n\u003e\n\u003e (Just exploring what the options are).\n\u003e\n\u003e Adam\n\u003e\n\u003e\n\u003e On Thu, Mar 20, 2014 at 11:36:09AM +0100, Mike Hearn wrote:\n\u003e\n\u003e\u003e   Encoding entire payment requests into qrcodes is definitely not the way\n\u003e\u003e   to go. They can already be large when signed and we're just at the\n\u003e\u003e   start of adding features.\n\u003e\u003e   Finishing off and standardising the bluetooth support is the way to go\n\u003e\u003e   (r=bt:mac). Andreas' app already has some support for this I believe,\n\u003e\u003e   so Alex you could prototype with that, but we need to:\n\u003e\u003e   1) Add an encryption/auth layer on top, because it runs over RFCOMM\n\u003e\u003e   sockets. The authentication would require proof of owning the Bitcoin\n\u003e\u003e   key that's in the address part of the URI (which is needed for\n\u003e\u003e   backwards compat anyway).\n\u003e\u003e   2) Write a BIP for it and make sure it's interoperable\n\u003e\u003e   For the auth layer we could either use SSL and then just ignore the\n\u003e\u003e   server certificate and require signing of the session public key with\n\u003e\u003e   the Bitcoin key, which should be easy to code up but is rather heavy on\n\u003e\u003e   the air, or roll a custom lightweight thing where we just do a basic\n\u003e\u003e   ECDH, with the servers key being the same as the address key. But\n\u003e\u003e   rolling such protocols is subtle and I guess it'd need to be reviewed\n\u003e\u003e   by people familiar with such things.\n\u003e\u003e   This feels like a good opportunity to grow the community - perhaps we\n\u003e\u003e   can find a volunteer in the forums who enjoys crypto.\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140320/d9962f3d/attachment.html\u003e"}