Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Mark van Cuijk <mark@coinqy.com>
In-Reply-To: <mailman.341412.1410515709.2178.bitcoin-development@lists.sourceforge.net>
Date: Fri, 12 Sep 2014 12:11:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4CC413B-D5A5-423C-9D56-463FCDBDDE08@coinqy.com>
References: <mailman.341412.1410515709.2178.bitcoin-development@lists.sourceforge.net>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP72 amendment proposal
Precedence: list

On 12 Sep 2014, at 11:55 , =
bitcoin-development-request@lists.sourceforge.net wrote:

> 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 plan.

Do you have a list (possibly incomplete) of apps that perform this kind =
of checking? We=92re currently working with some parties in a supply =
chain to allow a consumer payment on a retail website to automatically =
pay supply chain parties, the way BIP70 allows with multiple outputs on =
a transaction. This behaviour would prohibit this use case.

/Mark=