Wladimir [ARCHIVE] on Nostr: 📅 Original date posted:2014-09-12 📝 Original message:On Fri, Sep 12, 2014 at ...
📅 Original date posted:2014-09-12
📝 Original message:On Fri, Sep 12, 2014 at 11:29 AM, Andreas Schildbach
<andreas at 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
📝 Original message:On Fri, Sep 12, 2014 at 11:29 AM, Andreas Schildbach
<andreas at 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