Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 74.125.82.174 as permitted sender)
	client-ip=74.125.82.174; envelope-from=jgarzik@bitpay.com;
	helo=mail-we0-f174.google.com; 
MIME-Version: 1.0
In-Reply-To: <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>
	<l1uj7g$vds$1@ger.gmane.org>
Date: Wed, 25 Sep 2013 10:31:19 -0400
Message-ID: <CAJHLa0NbEjnQ2V8HPjVfC_mZ33ojMBMQP2i90KvmEsZik7h3kA@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
Precedence: list

BitPay experimented with QR codes in low light, restaurant and other
conditions.  QR codes become difficult to use even at 100 chars.

On the merchant side, we prefer a short URL that speaks payment
protocol if visited via bitcoin client, but will gracefully work if
scanned by a phone with zero bitcoin support -- you will simply be
redirected to a BitPay invoice page for a normal browser.



On Wed, Sep 25, 2013 at 7:59 AM, Andreas Schildbach
<andreas@schildbach.de> wrote:
> 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



-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/