Andreas Schildbach [ARCHIVE] on Nostr: 📅 Original date posted:2013-09-25 📝 Original message:On 09/25/2013 01:45 PM, ...
📅 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.
📝 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.