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. ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
