Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.171 as permitted sender)
	client-ip=209.85.213.171; envelope-from=laanwj@gmail.com;
	helo=mail-ig0-f171.google.com; 
MIME-Version: 1.0
In-Reply-To: <luuee6$as3$1@ger.gmane.org>
References: <luuee6$as3$1@ger.gmane.org>
Date: Fri, 12 Sep 2014 11:55:01 +0200
Message-ID: <CA+s+GJAjPdLB3jn-U6NbN0LvBKz+C5fDdbdEhFPKXUiTjyZDEA@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP72 amendment proposal
Precedence: list

On Fri, Sep 12, 2014 at 11:29 AM, Andreas Schildbach
<andreas@schildbach.de> wrote:
> This is the discussion post corresponding to this PR:
> https://github.com/bitcoin/bips/pull/106
>
> "Amend BIP72 by an "h" parameter, which contains a hash of the
> PaymentRequest message that is fetched via the "r" parameter.
>
> The hash is meant to link the trust anchor (e.g. the QR code) to the
> payment request message in a secure way. This will solve the problem
> several apps are comparing address+amount fields as a workaround
> instead, preventing some advanced BIP70 usecases. When these apps read a
> matching hash, they need not compare any of the other fields.

Sounds like a good idea to me.

I had no idea that some clients were comparing addresses and amounts
in the URI with the payment request for security, that seems like a
hacky and inflexible way. This is much better.

Wladimir