* [Bitcoin-development] BIP16/17 replacement
@ 2012-01-31 16:50 Andy Parkins
2012-01-31 16:58 ` Luke-Jr
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Andy Parkins @ 2012-01-31 16:50 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: Text/Plain, Size: 2476 bytes --]
Hello,
Gulp. Am a little nervous about wading into this swamp. However, it seems
to me that the debate has veered into the personal and away from the
technical. Surely if there are objections to both suggestions, that another
solution might be better? The answer doesn't have to be A or B, if the
answer C turns out to be acceptable.
That being said; I am not confident enough to start making BIPs so I offer
this idea up for my traditional mailing-list roasting but with the hope that
I blindly stumble toward something more acceptable to everyone.
----
If the change is going to be a big one anyway and will require a client
upgrade why not...
- Increase the version number in transactions to make a new transaction
structure
- Dump the "scriptPubKey" field completely. Everything will be pay-to-
script-hash in version2 transactions
- Replace it with "hashOfClaimingScript"
- Add an "unsignedParameters" array.
hashOfClaimingScript is _not_ script. It's just the hash of the script that
is allowed to claim the output. Then before scriptSig is allowed to run, it
is hashed and compared against the hashOfClaimingScript.
unsignedParameters replaces the need for all the crazy messing around that
OP_CHECKSIG currently does because it is specifically a block of the
transaction that it not signed (although I would include the array size bytes
in the signature calculation), therefore no script filtering is necessary.
The claiming script, scriptSig, can then be checked against whatever list of
templates you like. For pay-to-address it will probably look like:
OP_PUSHPARAMETER {0}
OP_PUSH { <claimant public key> }
OP_CHECKSIGVERIFY
Handling the more complicated transactions (they're the point of all this
after all) is pretty obvious; the unsignedParameters block can hold as many
signatures as you like. It also removes the need for OP_CHECKMULTISIG, since
the script can specify the signature conditions. e.g. a 2-of-3 script:
OP_PUSHPARMETER {0}
OP_PUSH { <claimant public key0> }
OP_CHECKSIG
OP_PUSHPARMETER {1}
OP_PUSH { <claimant public key1> }
OP_CHECKSIG
OP_PUSHPARMETER {1}
OP_PUSH { <claimant public key1> }
OP_CHECKSIG
OP_ADD
OP_ADD
OP_PUSH {1}
OP_GREATERTHAN
(I'm sure someone cleverer than I can improve on the above)
-----
Let the flaming commence...
Andy
--
Dr Andy Parkins
andyparkins@gmail•com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [Bitcoin-development] BIP16/17 replacement 2012-01-31 16:50 [Bitcoin-development] BIP16/17 replacement Andy Parkins @ 2012-01-31 16:58 ` Luke-Jr 2012-01-31 17:11 ` Andy Parkins 2012-02-01 9:48 ` Andy Parkins 2012-01-31 17:45 ` Gregory Maxwell 2012-02-01 14:14 ` Andy Parkins 2 siblings, 2 replies; 9+ messages in thread From: Luke-Jr @ 2012-01-31 16:58 UTC (permalink / raw) To: bitcoin-development On Tuesday, January 31, 2012 11:50:58 AM Andy Parkins wrote: > Gulp. Am a little nervous about wading into this swamp. However, it seems > to me that the debate has veered into the personal and away from the > technical. Surely if there are objections to both suggestions, that > another solution might be better? The answer doesn't have to be A or B, > if the answer C turns out to be acceptable. I'm not aware of any remaining *tangible* objections to BIP 17 at this point (Gavin seems concerned over a theoretical risk-that-nobody-has-thought-of), but if there's a better solution, I'm perfectly fine Withdrawing BIP 17 to support it. > If the change is going to be a big one anyway and will require a client > upgrade why not... Both BIP 16 and 17 are backward compatible enough that people can continue to use the old clients with each other. An upgrade is only required to send to (or create/receive on) the new 3...-form addresses. That being said, it's quite possible to rewrite the practical implications of both BIP 16 and 17 in the format you seem to be suggesting. Doing so would even get rid of one of the major objections to BIP 16 (its inconsistency). ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] BIP16/17 replacement 2012-01-31 16:58 ` Luke-Jr @ 2012-01-31 17:11 ` Andy Parkins 2012-02-01 9:48 ` Andy Parkins 1 sibling, 0 replies; 9+ messages in thread From: Andy Parkins @ 2012-01-31 17:11 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: Text/Plain, Size: 1298 bytes --] On 2012 January 31 Tuesday, Luke-Jr wrote: > I'm not aware of any remaining *tangible* objections to BIP 17 at this > point (Gavin seems concerned over a theoretical > risk-that-nobody-has-thought-of), but if there's a better solution, I'm > perfectly fine Withdrawing BIP 17 to support it. I imagine the BIP16 supporters would say the same? Isn't that the essence of the current impasse? > Both BIP 16 and 17 are backward compatible enough that people can continue > to use the old clients with each other. An upgrade is only required to > send to (or create/receive on) the new 3...-form addresses. That being > said, it's quite possible to rewrite the practical implications of both > BIP 16 and 17 in the format you seem to be suggesting. Doing so would even > get rid of one of the major objections to BIP 16 (its inconsistency). My suggestion is backward compatible. You'd only have to make version2 transactions for version2 addresses; and the join between version1 and version2 is not a problem since the version1 source can be detected, and the handling of the version2 transaction altered as appropriate (it's only a matter of switching from the hash check to running the two scripts as normal). Andy -- Dr Andy Parkins andyparkins@gmail•com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] BIP16/17 replacement 2012-01-31 16:58 ` Luke-Jr 2012-01-31 17:11 ` Andy Parkins @ 2012-02-01 9:48 ` Andy Parkins 2012-02-01 10:02 ` Pieter Wuille 1 sibling, 1 reply; 9+ messages in thread From: Andy Parkins @ 2012-02-01 9:48 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: Text/Plain, Size: 516 bytes --] On 2012 January 31 Tuesday, Luke-Jr wrote: > Both BIP 16 and 17 are backward compatible enough that people can continue > to use the old clients with each other. An upgrade is only required to > send to (or create/receive on) the new 3...-form addresses. That being Is that true? (I'm happy to be called wrong) It doesn't seem like it to me. The new transaction types will be rejected by old clients won't they? They don't pass IsStandard(). Andy -- Dr Andy Parkins andyparkins@gmail•com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] BIP16/17 replacement 2012-02-01 9:48 ` Andy Parkins @ 2012-02-01 10:02 ` Pieter Wuille 2012-02-01 10:25 ` Andy Parkins 0 siblings, 1 reply; 9+ messages in thread From: Pieter Wuille @ 2012-02-01 10:02 UTC (permalink / raw) To: Andy Parkins; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1345 bytes --] Op 1 feb. 2012 10:48 schreef "Andy Parkins" <andyparkins@gmail•com> het volgende: > > On 2012 January 31 Tuesday, Luke-Jr wrote: > > > Both BIP 16 and 17 are backward compatible enough that people can continue > > to use the old clients with each other. An upgrade is only required to > > send to (or create/receive on) the new 3...-form addresses. That being > > Is that true? (I'm happy to be called wrong) > > It doesn't seem like it to me. The new transaction types will be rejected by > old clients won't they? They don't pass IsStandard(). IsStandard() is for accepting transactions into the memory pool. Non-standard transactions are verified just fine when they are in the block chain. BIP16/17 both create transactions that, when interpreted as old scripts, are valid. The only change to the protocol is that previously-valid transactions become invalid. As long as a supermajority of miners enforce the new rules, everyone can happily keep using their old bitcoin client. They won't create the new transaction type, and don't accept them as payment, but they will accept the new block chain. If we do a breaking change to the protocol - such as adding a new transaction type - ALL users must upgrade. Those who don't will see a fork of the chain from before the first new-style transaction. That is not the case now. -- Pieter [-- Attachment #2: Type: text/html, Size: 1586 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] BIP16/17 replacement 2012-02-01 10:02 ` Pieter Wuille @ 2012-02-01 10:25 ` Andy Parkins 0 siblings, 0 replies; 9+ messages in thread From: Andy Parkins @ 2012-02-01 10:25 UTC (permalink / raw) To: Pieter Wuille; +Cc: bitcoin-development [-- Attachment #1: Type: Text/Plain, Size: 669 bytes --] On 2012 February 01 Wednesday, Pieter Wuille wrote: > > old clients won't they? They don't pass IsStandard(). > > IsStandard() is for accepting transactions into the memory pool. > Non-standard transactions are verified just fine when they are in the block > chain. Ah. My misunderstanding then. > If we do a breaking change to the protocol - such as adding a new > transaction type - ALL users must upgrade. Those who don't will see a fork > of the chain from before the first new-style transaction. That is not the > case now. That makes a big difference. Thanks for the correction. Andy -- Dr Andy Parkins andyparkins@gmail•com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] BIP16/17 replacement 2012-01-31 16:50 [Bitcoin-development] BIP16/17 replacement Andy Parkins 2012-01-31 16:58 ` Luke-Jr @ 2012-01-31 17:45 ` Gregory Maxwell 2012-02-01 9:46 ` Andy Parkins 2012-02-01 14:14 ` Andy Parkins 2 siblings, 1 reply; 9+ messages in thread From: Gregory Maxwell @ 2012-01-31 17:45 UTC (permalink / raw) To: Andy Parkins; +Cc: bitcoin-development On Tue, Jan 31, 2012 at 11:50 AM, Andy Parkins <andyparkins@gmail•com> wrote: > Hello, > > Gulp. Am a little nervous about wading into this swamp. However, it seems > to me that the debate has veered into the personal and away from the I think you've been deceived by people who have some interest in promoting this as some sort of big controversy, or perhaps just confused by the general level of noise. The differences between BIP16/BIP17 are technically obscure, everyone who is well versed in the issue (with the potential exception of Luke). There is broad consensus among the involved technically minded parties over just about all of it. Luke has been maintaining an opinion tracker page: https://en.bitcoin.it/wiki/P2SH_Votes reflecting the views of core developers and people who've been technically involved enough to have an informed opinion. > Surely if there are objections to both suggestions, that another > solution might be better? There is always a different color that the shed could be painted. Expecting absolute consensus on the _best_ way forward is an unreasonable standard, especially if you're going to invite the opinions of many people. Depending on how you count we have considered a good two dozen options in this space— Starting with the OP_CAT key combinations many months back, and including many variants of the current ideas. The BIPs only represent the "final" surviving ideas. In particular, BIP16 was the isolated consensus path forward that came out of the discussions about the concerns that BIP12 was too computationally powerful— I don't think I can identify any particular person as the author of the BIP16 idea. At the the time BIP16 became a BIP only Luke was actively objecting to it. Though his hard work and tireless (...unstoppable dogmatic) promotion he's managed to build a workable alternative, and it now has some support other than himself. This, however, doesn't constitute a material schism. > this idea up for my traditional mailing-list roasting but with the hope that As always, asbestos underwear is required. > If the change is going to be a big one anyway and will require a client > upgrade why not... It does not, in fact— Yes, it requires a client update to make use of the new functionality, but old nodes will happily continue to validate things. It's hard to express how critical this is distinctly. Bitcoin is, predominantly, a zero-trust system. Nodes don't trust that things were done right, the validate them for themselves. A breaking change of the kind you suggest is not something that would be considered lightly, and this is certainly not justified for this. > - Increase the version number in transactions to make a new transaction > structure > - Dump the "scriptPubKey" field completely. Everything will be pay-to- > script-hash in version2 transactions > - Replace it with "hashOfClaimingScript" > - Add an "unsignedParameters" array. If we ever were to scrap the system, I think we very much would do something like what you describe here... and as much has been documented: https://en.bitcoin.it/wiki/Hardfork_Wishlist (see "Elimination of output scripts") But, to be clear, this stuff is pretty much fantasy. I'm doubtful that it will ever happen, doubtful that we can get the kind of development resources required to pull off a true breaking change in a way that people would actually trust upgrading to— at least not before a time that the system is simply too big to make that kind of change. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] BIP16/17 replacement 2012-01-31 17:45 ` Gregory Maxwell @ 2012-02-01 9:46 ` Andy Parkins 0 siblings, 0 replies; 9+ messages in thread From: Andy Parkins @ 2012-02-01 9:46 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-development [-- Attachment #1: Type: Text/Plain, Size: 2743 bytes --] On 2012 January 31 Tuesday, Gregory Maxwell wrote: > I think you've been deceived by people who have some interest in > promoting this as some sort of big controversy, or perhaps just > confused by the general level of noise. Well that's good that there is no real problem. > It does not, in fact— Yes, it requires a client update to make use of > the new functionality, but old nodes will happily continue to validate > things. It's hard to express how critical this is distinctly. > Bitcoin is, predominantly, a zero-trust system. Nodes don't trust that > things were done right, the validate them for themselves. > > A breaking change of the kind you suggest is not something that would > be considered lightly, and this is certainly not justified for this. To be brutally honest; I don't see how the BIP16/17 changes are any less "breaking" than what I proposed (I'm not trying to push mine; forget it, the last thing bitcoin needs is another proposal if there is no real argument). I will agree the changes are smaller for BIP16, since the transactions are left as they are. If BIP16/BIP17 were being honest they would too increase the version number of the transaction structure. The new transaction type is not supported by the old client... that's a break. My argument would be that once you're going to break the old clients anyway, go the whole hog and fix some other stuff as well. > If we ever were to scrap the system, I think we very much would do > something like what you describe here... and as much has been > documented: > > https://en.bitcoin.it/wiki/Hardfork_Wishlist > (see "Elimination of output scripts") I'm glad I wasn't talking rubbish then. > But, to be clear, this stuff is pretty much fantasy. I'm doubtful that > it will ever happen, doubtful that we can get the kind of development Me too. Which is a shame; as it means we're locked into quite a fair number of earlier decisions that will now never be changed. > resources required to pull off a true breaking change in a way that > people would actually trust upgrading to— at least not before a time > that the system is simply too big to make that kind of change. Again: I don't see how BIP16/17 aren't "breaking" as well; but perhaps I'm just not familiar enough with the conventions. As far as I understand; no pre-BIP16 miner is going to allow BIP16 into the blockchain because it's not going to pass the IsStandard() test. I'd repeat: the reasonable thing to do is to increase the version number of the transaction structure to indicate that they are being processed differently from old transactions. Andy -- Dr Andy Parkins andyparkins@gmail•com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] BIP16/17 replacement 2012-01-31 16:50 [Bitcoin-development] BIP16/17 replacement Andy Parkins 2012-01-31 16:58 ` Luke-Jr 2012-01-31 17:45 ` Gregory Maxwell @ 2012-02-01 14:14 ` Andy Parkins 2 siblings, 0 replies; 9+ messages in thread From: Andy Parkins @ 2012-02-01 14:14 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: Text/Plain, Size: 1611 bytes --] On 2012 January 31 Tuesday, Andy Parkins wrote: > - Increase the version number in transactions to make a new transaction > structure > - Dump the "scriptPubKey" field completely. Everything will be pay-to- > script-hash in version2 transactions > - Replace it with "hashOfClaimingScript" > - Add an "unsignedParameters" array. Having thought about it; I've realised that the above is simply BIP16 without the backward compatibility work in it. If BIP16 renamed the scriptPubKey field to "hashOfClaimingScript" and no longer ran it as a script, it woudl be close to identical. We'd simply define the field as 0xa9 0x14 <hashOfClaimingScript> 0x87 Detection of this format of scriptPubKey activates "version2" processing of the transaction. And similarly, a new definition of scriptSig to be two fields: unsignedInitialStackBlock scriptClaim I'm sure nobody cares about my opinion; but that's actually been the moment of epiphany for me (and I raise it here, in case it is for someone else). Having previously been against BIP16, I'm now happy with BIP16 -- it's a progression towards the ideal... having a literal claimScriptHash field instead of scriptPubKey; and never running scriptPubKey. Potentially OP_CHECKSIG could be simplified as well because the rules could be "anything that's not the serialized script" in scriptSig is not signed. I can imagine one day, when the network is all BIP16 compliant, that scriptPubKey will no longer be allowed to run as script at all. Andy -- Dr Andy Parkins andyparkins@gmail•com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-02-01 14:14 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-01-31 16:50 [Bitcoin-development] BIP16/17 replacement Andy Parkins 2012-01-31 16:58 ` Luke-Jr 2012-01-31 17:11 ` Andy Parkins 2012-02-01 9:48 ` Andy Parkins 2012-02-01 10:02 ` Pieter Wuille 2012-02-01 10:25 ` Andy Parkins 2012-01-31 17:45 ` Gregory Maxwell 2012-02-01 9:46 ` Andy Parkins 2012-02-01 14:14 ` Andy Parkins
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox