Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of m.gmane.org
	designates 80.91.229.3 as permitted sender)
	client-ip=80.91.229.3;
	envelope-from=gcbd-bitcoin-development@m.gmane.org;
	helo=plane.gmane.org; 
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Wed, 25 Sep 2013 13:59:52 +0200
Message-ID: <l1uj7g$vds$1@ger.gmane.org>
References: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>	<521298F0.20108@petersson.at>	<CABsx9T3b--tfUmaxJxsXyM2f3Cw4M1oX1nX8o9WkW_haBmLctA@mail.gmail.com>	<CANEZrP2BOWk4FOUx4eVHvXmdSgx3zo_o18J8YBi2Uc_WkBAXKA@mail.gmail.com>	<CANEZrP0H9TVfQ3AGv6aBmS1DUa6MTWhSFAN1Jo4eimBEBQhPZw@mail.gmail.com>	<CABsx9T0TQ6Gg=muNP-rCZxan8_nAqeJt6ErYVOfnLJKrsLs81w@mail.gmail.com>	<CANEZrP2V72+-m-FOCsW3C2GBO7+=-0casKadeHncmNTYjyqJRA@mail.gmail.com>	<l1udst$uos$1@ger.gmane.org>	<CANEZrP03KsGHvGqcNT1Qs6qkJ4i050CPjwvGqTRRhbdkgMf_dA@mail.gmail.com>	<l1uhld$d68$1@ger.gmane.org>
	<CANEZrP2ZbSUvNk+0bHCWw40r00D8ja-crrZPjvN0mgG+NaD52w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.0
In-Reply-To: <CANEZrP2ZbSUvNk+0bHCWw40r00D8ja-crrZPjvN0mgG+NaD52w@mail.gmail.com>
Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
Precedence: list

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.