📅 Original date posted:2014-03-20
📝 Original message:Encoding entire payment requests into qrcodes is definitely not the way to
go. They can already be large when signed and we're just at the start of
adding features.
Finishing off and standardising the bluetooth support is the way to go
(r=bt:mac). Andreas' app already has some support for this I believe, so
Alex you could prototype with that, but we need to:
1) Add an encryption/auth layer on top, because it runs over RFCOMM
sockets. The authentication would require proof of owning the Bitcoin key
that's in the address part of the URI (which is needed for backwards compat
anyway).
2) Write a BIP for it and make sure it's interoperable
For the auth layer we could either use SSL and then just ignore the server
certificate and require signing of the session public key with the Bitcoin
key, which should be easy to code up but is rather heavy on the air, or
roll a custom lightweight thing where we just do a basic ECDH, with the
servers key being the same as the address key. But rolling such protocols
is subtle and I guess it'd need to be reviewed by people familiar with such
things.
This feels like a good opportunity to grow the community - perhaps we can
find a volunteer in the forums who enjoys crypto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140320/ad3cb0fd/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:14:18
in reply to nevent1q…vxvh
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:14:18Event JSON
{
"id": "49957abdd4d14b33440df47423d4f769679f5e28f9409bd61161526ff845a99d",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686150858,
"kind": 1,
"tags": [
[
"e",
"d70d8d12a406cb1c9a067111bb9c717b35fd85b951e12f89e562fccc2fad4277",
"",
"root"
],
[
"e",
"96131fe532e428ae940c2758b1c64c4e4e1b7f125570321d8bc5649c02f8241e",
"",
"reply"
],
[
"p",
"3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc"
]
],
"content": "📅 Original date posted:2014-03-20\n📝 Original message:Encoding entire payment requests into qrcodes is definitely not the way to\ngo. They can already be large when signed and we're just at the start of\nadding features.\n\nFinishing off and standardising the bluetooth support is the way to go\n(r=bt:mac). Andreas' app already has some support for this I believe, so\nAlex you could prototype with that, but we need to:\n\n1) Add an encryption/auth layer on top, because it runs over RFCOMM\nsockets. The authentication would require proof of owning the Bitcoin key\nthat's in the address part of the URI (which is needed for backwards compat\nanyway).\n\n2) Write a BIP for it and make sure it's interoperable\n\nFor the auth layer we could either use SSL and then just ignore the server\ncertificate and require signing of the session public key with the Bitcoin\nkey, which should be easy to code up but is rather heavy on the air, or\nroll a custom lightweight thing where we just do a basic ECDH, with the\nservers key being the same as the address key. But rolling such protocols\nis subtle and I guess it'd need to be reviewed by people familiar with such\nthings.\n\nThis feels like a good opportunity to grow the community - perhaps we can\nfind a volunteer in the forums who enjoys crypto.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140320/ad3cb0fd/attachment.html\u003e",
"sig": "2c26e0c9334feacd87bca408394dc7e12ff01f3864f5b1c43f964fb4cdd912498acf541c0722f810f1bc6d9a5f784ffc990029fc5e3fbd6d0aeb09d4c2351d49"
}