Proposal to change payment protocol signing
5 messages, 28 to 29 Apr 2014. Started by Gavin Andresen.
Gavin Andresen (2), Mike Hearn, Ryan X. Charles, Jouke Hofman
There is a discussion about clarifying how BIP70 signs payment requests here: https://github.com/bitcoin/bips/pull/41
The issue is what to do with the signature field before signing. The code Mike and I initially wrote does this:
request.set_signature(string(""));
(sets signature to the empty string)
I think that is a mistake; it should be:
request.clear_signature();
(clears signature field, so it is not serialized at all).
So: if you are implementing, or have implemented, the payment protocol, please chime in. I'd like to change the spec and the reference implementation NOW, while BIP70 is still a 'Draft'.
Because this type of "hey, I'm implementing your standard and it doesn't work the way I think it should" mistake is exactly why BIPs take a while before being declared 'Final.'
Who cares what it is? Setting to an empty byte array is fine, IMO. The payment protocol is already rolling out. It's implemented in several wallets, BitPay implements it, Coinbase is implementing it, etc.
-100000 for changing such a basic thing at this point. It'd cause chaos for the early adopters, punishing them instead of rewarding them. It'd seriously hurt adoption of the payment protocol when it's at its most vulnerable. We should mark BIP 70 as accepted and be done with it.
Agreed with Mike. It doesn't really matter what the signature field is set to. Changing the standard now is too hard with too little benefit.
On 4/28/14, 12:14 PM, Mike Hearn wrote:
Quoted text (25 lines)
> Who cares what it is? Setting to an empty byte array is fine, IMO. The > payment protocol is already rolling out. It's implemented in several > wallets, BitPay implements it, Coinbase is implementing it, etc. > > -100000 for changing such a basic thing at this point. It'd cause chaos > for the early adopters, punishing them instead of rewarding them. It'd > seriously hurt adoption of the payment protocol when it's at its most > vulnerable. We should mark BIP 70 as accepted and be done with it. > > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
We have BIP70 already in use (over a hundred paid requests).
Could you elaborate on why this needs changing?
On 28-04-14 14:39, Gavin Andresen wrote:
Quoted text (30 lines)
> There is a discussion about clarifying how BIP70 signs payment > requests here: https://github.com/bitcoin/bips/pull/41 > > The issue is what to do with the signature field before signing. > The code Mike and I initially wrote does this: > > request.set_signature(string("")); > > (sets signature to the empty string) > > I think that is a mistake; it should be: > > request.clear_signature(); > > (clears signature field, so it is not serialized at all). > > So: if you are implementing, or have implemented, the payment > protocol, please chime in. I'd like to change the spec and the > reference implementation NOW, while BIP70 is still a 'Draft'. > > Because this type of "hey, I'm implementing your standard and it > doesn't work the way I think it should" mistake is exactly why BIPs > take a while before being declared 'Final.' > > > > > ------------------------------------------------------------------------------ > >
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Quoted text (11 lines)
> Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing > platform available. Simple to use. Nothing to install. Get started > now for free." http://p.sf.net/sfu/SauceLabs > > > > _______________________________________________ Bitcoin-development > mailing list Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
Consensus is the spec should be clarified to match current behavior, so it won't change.