<oembed><type>rich</type><version>1.0</version><author_name>npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_name><author_url>https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2014-03-20&#xA;📝 Original message:Encoding entire payment requests into qrcodes is definitely not the way to&#xA;go. They can already be large when signed and we&#39;re just at the start of&#xA;adding features.&#xA;&#xA;Finishing off and standardising the bluetooth support is the way to go&#xA;(r=bt:mac). Andreas&#39; app already has some support for this I believe, so&#xA;Alex you could prototype with that, but we need to:&#xA;&#xA;1) Add an encryption/auth layer on top, because it runs over RFCOMM&#xA;sockets. The authentication would require proof of owning the Bitcoin key&#xA;that&#39;s in the address part of the URI (which is needed for backwards compat&#xA;anyway).&#xA;&#xA;2) Write a BIP for it and make sure it&#39;s interoperable&#xA;&#xA;For the auth layer we could either use SSL and then just ignore the server&#xA;certificate and require signing of the session public key with the Bitcoin&#xA;key, which should be easy to code up but is rather heavy on the air, or&#xA;roll a custom lightweight thing where we just do a basic ECDH, with the&#xA;servers key being the same as the address key. But rolling such protocols&#xA;is subtle and I guess it&#39;d need to be reviewed by people familiar with such&#xA;things.&#xA;&#xA;This feels like a good opportunity to grow the community - perhaps we can&#xA;find a volunteer in the forums who enjoys crypto.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140320/ad3cb0fd/attachment.html&gt;</html></oembed>