Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.213.169 as permitted sender)
	client-ip=209.85.213.169; envelope-from=jgarzik@bitpay.com;
	helo=mail-ig0-f169.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP1iTfZxY915hzoAEApz1+wd_S9j5RCwVJCNFqQ_+DNTSQ@mail.gmail.com>
References: <mailman.341412.1410515709.2178.bitcoin-development@lists.sourceforge.net>
	<A4CC413B-D5A5-423C-9D56-463FCDBDDE08@coinqy.com>
	<luuk5f$i8o$1@ger.gmane.org>
	<CANEZrP1iTfZxY915hzoAEApz1+wd_S9j5RCwVJCNFqQ_+DNTSQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Fri, 12 Sep 2014 10:15:21 -0400
Message-ID: <CAJHLa0Px985E7NyhHVPRpLxXD6XDGhd_WwsbHNBaQZVMQwxTwA@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] BIP72 amendment proposal
Precedence: list

Indeed -- Every byte added to the QR code makes it more difficult to
be used in restaurants, pubs and other low-light conditions.  BitPay
tested some of these scenarios.

Scannability is absolutely impacted.

On Fri, Sep 12, 2014 at 9:49 AM, Mike Hearn <mike@plan99.net> wrote:
> A few thoughts on this:
>
> (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk
> here is that a MITM intercepts the payment request, which will be typically
> requested just seconds after the QR code is vended. 80 bits of entropy would
> still be a lot and take a long time to brute force, whilst keeping QR codes
> more compact, which impacts scannability.
>
> (2) This should not be necessary in the common HTTPS context. The QR code
> itself is going to be fetched from some service, over HTTPS. I see no
> reasonable attacker that can MITM the request for the BIP70 message but not
> the request to get the QR code. Adding a hash makes QR codes more bloated
> and harder to scan, all on the assumption that HTTPS is broken in some odd
> way that we haven't actually ever seen in practice.
>
> (3) This can be useful in the Bluetooth context, but then again, we could
> also do things a different way by signing with the key in the first part of
> the URI, thus avoiding the need for a hash.
>
> I know I've been around the loop on this one with Andreas many times. But
> this BIP doesn't fix any actually existing problem in the previous spec. It
> exists because Andreas thinks SSL is useless. If SSL is useless we all have
> much bigger problems.
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/