Adam Back [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-20 📝 Original message:Whats a sensible limit on ...
📅 Original date posted:2014-03-20
📝 Original message:Whats a sensible limit on practical/convenient QR code size?
How much of the payment protocol message size comes from use of x509?
(Just exploring what the options are).
Adam
On Thu, Mar 20, 2014 at 11:36:09AM +0100, Mike Hearn wrote:
> 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.
Published at
2023-06-07 15:14:18Event JSON
{
"id": "5f2a37aae78dd782c794a526d91d67e294e1434c4e635b6839c3277f8ddbfad4",
"pubkey": "ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a",
"created_at": 1686150858,
"kind": 1,
"tags": [
[
"e",
"d70d8d12a406cb1c9a067111bb9c717b35fd85b951e12f89e562fccc2fad4277",
"",
"root"
],
[
"e",
"49957abdd4d14b33440df47423d4f769679f5e28f9409bd61161526ff845a99d",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-03-20\n📝 Original message:Whats a sensible limit on practical/convenient QR code size?\n\nHow much of the payment protocol message size comes from use of x509?\n\n(Just exploring what the options are).\n\nAdam\n\nOn Thu, Mar 20, 2014 at 11:36:09AM +0100, Mike Hearn wrote:\n\u003e Encoding entire payment requests into qrcodes is definitely not the way\n\u003e to go. They can already be large when signed and we're just at the\n\u003e start of adding features.\n\u003e Finishing off and standardising the bluetooth support is the way to go\n\u003e (r=bt:mac). Andreas' app already has some support for this I believe,\n\u003e so Alex you could prototype with that, but we need to:\n\u003e 1) Add an encryption/auth layer on top, because it runs over RFCOMM\n\u003e sockets. The authentication would require proof of owning the Bitcoin\n\u003e key that's in the address part of the URI (which is needed for\n\u003e backwards compat anyway).\n\u003e 2) Write a BIP for it and make sure it's interoperable\n\u003e For the auth layer we could either use SSL and then just ignore the\n\u003e server certificate and require signing of the session public key with\n\u003e the Bitcoin key, which should be easy to code up but is rather heavy on\n\u003e the air, or roll a custom lightweight thing where we just do a basic\n\u003e ECDH, with the servers key being the same as the address key. But\n\u003e rolling such protocols is subtle and I guess it'd need to be reviewed\n\u003e by people familiar with such things.\n\u003e This feels like a good opportunity to grow the community - perhaps we\n\u003e can find a volunteer in the forums who enjoys crypto.",
"sig": "863e88becc8347c604d23f41962b2c55e94ce22f8fdd2418ec76aca539d32c7521cf8cfbf20faccc4e96d4c73370a3f5ea19df444a3f53b4932d1ac462012881"
}