📅 Original date posted:2013-09-25
📝 Original message:On 09/25/2013 01:45 PM, Mike Hearn wrote:
> OK, it might fit if you don't use any of the features the protocol
> provides :)
Now you're dver-dramaticing (-:
I'm just skipping one feature which I think is useless for QR codes
scanned in person.
> You can try it here:
Thanks. A typical request would be around 60 bytes, which should produce
an URL with around 100 chars. That should be fine for scanning, but I
will experiment.
> If you're thinking about governments and so on subverting CA's, then
> there is a plan for handling that (outside the Bitcoin world) called
> certificate transparency which is being implemented now.
Good to hear. Let's see if it gets momentum.
> Now when you are getting a QR code from the web, it's already being
> served over HTTPS. So if you're up against an attacker who can break a
> CA in order to steal your money, then you already lose, the QRcode
> itself as MITMd.
Sure. I was talking about QR codes scanned in person.
> In the Bluetooth case we might have to keep the address around and use
> it to do ECDHE or something like that.
Yeah, will look at that as soon as we're implementing the payment
protocol fully.
Andreas Schildbach [ARCHIVE] /
npub1xg…adsv7
2023-06-07 15:06:58
in reply to nevent1q…utrl
Author Public Key
npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7Published at
2023-06-07 15:06:58Event JSON
{
"id": "5d56b8c3503bde4769dc770f52883e1075af2afe2c82ae1ae7c4cfae57b2ce4c",
"pubkey": "3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc",
"created_at": 1686150418,
"kind": 1,
"tags": [
[
"e",
"a751be3c813f9be7c191d199bd218d957841ef330cc8bf258e75cbaf91bae46f",
"",
"root"
],
[
"e",
"576f8d5aea638d30ec4b1994e0397f92f5279b25a561e688c904ee8b689685d1",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2013-09-25\n📝 Original message:On 09/25/2013 01:45 PM, Mike Hearn wrote:\n\n\u003e OK, it might fit if you don't use any of the features the protocol\n\u003e provides :)\n\nNow you're dver-dramaticing (-:\n\nI'm just skipping one feature which I think is useless for QR codes\nscanned in person.\n\n\u003e You can try it here:\n\nThanks. A typical request would be around 60 bytes, which should produce\nan URL with around 100 chars. That should be fine for scanning, but I\nwill experiment.\n\n\u003e If you're thinking about governments and so on subverting CA's, then\n\u003e there is a plan for handling that (outside the Bitcoin world) called\n\u003e certificate transparency which is being implemented now.\n\nGood to hear. Let's see if it gets momentum.\n\n\u003e Now when you are getting a QR code from the web, it's already being\n\u003e served over HTTPS. So if you're up against an attacker who can break a\n\u003e CA in order to steal your money, then you already lose, the QRcode\n\u003e itself as MITMd.\n\nSure. I was talking about QR codes scanned in person.\n\n\u003e In the Bluetooth case we might have to keep the address around and use\n\u003e it to do ECDHE or something like that.\n\nYeah, will look at that as soon as we're implementing the payment\nprotocol fully.",
"sig": "5509c5bd3338ce918f933301940abfd75e9111d123a718ed90e49660404e881264157da898fcfe4b5169f5aa63b9006a195dfb6e4333670af8819fca00b208d8"
}