Amend BIP72 by an "h" parameter, which contains a hash of the…

[schildbach]

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

Thanks to Julian Haight for helping with the standard.

[laanwj]

Sounds like a good idea to me.

However various people have protested against non-trivial changes to current BIPs in the past, especially those in common use. Instead of 'amend' BIP72 it may be better to add a new BIP that describes this.

Also this needs a discussion post on the mailing list.

[schildbach]

Thanks for reminding me on the discussion post. I have posted now.

[jgarzik]

Procedural: We don't patch deployed BIPs.

A new BIP is needed.

[laanwj]

@jgarzik I had already said that.

[schildbach]

@jgarzik It was never finished, so I thought its a better idea to "patch" it. But I'm ok with moving to a new BIP number as well if that makes the majority happy.

[gavinandresen]

New BIP number.

[laanwj]

How can we move this forward?

@schildbach Have you proposed this as a new BIP yet?

[AndySchroder]

A new BIP has been drafted up that includes this improvement as well as several others. As soon as @schildbach and I finish fine tuning a few sentances, it will be announced for feedback/review.

[laanwj]

Thanks for letting me know @AndySchroder I'll close this issue then.