Gavin Andresen (OP)
Legendary
Offline
Activity: 1652
Merit: 2300
Chief Scientist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 26, 2012, 05:21:41 PM |
|
I just had a great discussion with a developer who urged me to write a "big picture" technical post about BIP 16. So:
First, I think a good design approach is to be clear about what you are trying to accomplish and think about what the ideal solution, if there were no constraints like backwards compatibility, would look like.
The big picture goal has always been: short, multisignature bitcoin addresses (BIP 13).
The ideal solution would be to split scriptSig/scriptPubKey into three parts:
signatures, redemption script, and redemption script hash.
The sender would just provide the script hash, the receiver would provide the script and signatures to sign them over to somebody else.
Ideally, the redemption script hash would be include a version or 'hash type' byte, so in the future if RIPEMD160(SHA256()) was ever considered insecure a smooth upgrade could happen.
That's the ideal solution. I think all bitcoin transactions should have been done that way from the start, but it is what it is. Now we have to compromise, because one of the design constraints is backwards compatibility-- we are not going to replace scriptSig/scriptPubKey with something else and require everybody to upgrade all at once.
OP_EVAL tried to do too much, in my opinion. It enabled all sorts of nifty things, but we made the mistake of losing sight of what we were trying to accomplish.
BIP 16, in my view, meets the goal and (importantly!) does nothing more. I think of it as implementing the ideal three-way split in as simple and safe way as possible:
signatures: all the items except the last pushed onto the stack by the scriptSig redemption script: the last item pushed onto the stack by the scriptSig redemption script hash: the scriptPubKey
It is pretty darn close to what I think would be the ideal solution. It even has a byte at the beginning of the redemption script hash that specifies what hash type to use (OP_HASH160) !
That's all why I like BIP16 better than OP_EVAL. I've written quite a lot here on the details of why I prefer BIP 16 to BIP 17, but, fundamentally, I believe that BIP 16 is a more conservative solution that is less likely to have an "darn, I didn't see that coming" bug.
|
How often do you get the chance to work on a potentially world-changing project?
|
|
|
interlagos
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 26, 2012, 11:09:13 PM |
|
Hi Gavin,
Is it possible to also somehow close the hole about adding stuff into transaction before scriptSig by malicious nodes thus changing txID if modified transaction gets mined into block first?
Is it possible to address this in the future if not within BIP16?
Thanks
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 26, 2012, 11:17:33 PM |
|
Is it possible to also somehow close the hole about adding stuff into transaction before scriptSig by malicious nodes thus changing txID if modified transaction gets mined into block first?
Is it possible to address this in the future if not within BIP16? This can be fixed with or without P2SH of any kind.
|
|
|
|
interlagos
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 27, 2012, 12:00:49 AM |
|
Is it possible to also somehow close the hole about adding stuff into transaction before scriptSig by malicious nodes thus changing txID if modified transaction gets mined into block first?
Is it possible to address this in the future if not within BIP16? This can be fixed with or without P2SH of any kind. Yes that's what I thought as well, but since we are doing a major upgrade to the protocol it might be a good chance to take that into account as well. Or are you saying that the fix is very simple and won't require another heated debate and a fear of a chain fork? EDIT: if my question seemed like off-topic, I would rephrase it like this: How is this problem supposed to be fixed in the big picture (ideal situation in Gavin's OP)?
|
|
|
|
Costia
Newbie
Offline
Activity: 28
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 27, 2012, 06:49:56 PM |
|
If i do: scriptSig: [signature] {[pubkey] OP_CHECKSIG} OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL It going to execute the check(multi)sig 8 times?
|
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5306
Merit: 13296
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 27, 2012, 06:56:00 PM |
|
If i do: scriptSig: [signature] {[pubkey] OP_CHECKSIG} OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL It going to execute the check(multi)sig 8 times?
No. P2SH transactions can only have data in the scriptSig -- the OP_DUPs wouldn't be allowed.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
Costia
Newbie
Offline
Activity: 28
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 27, 2012, 07:00:16 PM |
|
i thought there was an OP_PUSHDATA there..
scriptSig: [signature] {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL
will execute multiple times? i think there was a ddos attack based on executing too many check sigs (wasting CPU time on all clients) what did the patch do to prevent this?
edit: i think there was some talk here about a multi sig counting to some 200 instructions limit, and that bip16's checksig didnt count for that limit
|
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5306
Merit: 13296
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 27, 2012, 07:03:38 PM |
|
i thought there was an OP_PUSHDATA there..
scriptSig: [signature] {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} {[pubkey] OP_CHECKSIG} scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL
will execute multiple times? i think there was a ddos attack based on executing too many check sigs (wasting CPU time on all clients) what did the patch do to prevent this?
Only the top item in the scriptSig is taken to be a serialized script. The others there would not be executed. That DoS attack is still prevented because serialized scripts still have their sigops counted and limited.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
Steve
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 27, 2012, 09:16:54 PM |
|
Sooo…it seems like the consensus is BIP-16. What are the next steps? Getting miners to officially register their intent to support it?
P.S. This weekend if I can find a little spare time, I want to play around with p2pool. How does one go about making the software put a vote in the coinbase transaction?
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 27, 2012, 09:17:57 PM |
|
Sooo…it seems like the consensus is BIP-16. Don't know where you got that idea.
|
|
|
|
Steve
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 27, 2012, 09:20:08 PM |
|
Sooo…it seems like the consensus is BIP-16. Don't know where you got that idea. The forum threads on the topic.
|
|
|
|
wachtwoord
Legendary
Offline
Activity: 2324
Merit: 1125
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 27, 2012, 09:22:27 PM |
|
By reading the topics on this forum.
|
|
|
|
Matt Corallo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 27, 2012, 09:47:24 PM |
|
I have to put my support behind BIP 16. Though BIP 17 is cleaner in some aspects, the serialization of a script to be placed on the scriptSig doesnt bother me and the additional restrictions on what BIP 16 scripts can do seems safer to me. Adding restrictions without preventing any additional realistic use-cases is, to me, a no-brainer.
|
|
|
|
RaggedMonk
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 27, 2012, 11:57:50 PM |
|
Sooo…it seems like the consensus is BIP-16. Don't know where you got that idea. From almost everyone except you ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif)
|
|
|
|
makomk
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 28, 2012, 09:17:30 PM |
|
It is pretty darn close to what I think would be the ideal solution. It even has a byte at the beginning of the redemption script hash that specifies what hash type to use (OP_HASH160) !
Except of course that you can't change the hash type - not even to the other hash type that Bitcoin scripts already support, plain SHA-256 - without getting everyone to upgrade and going through the whole process again. As soon as you change the opcode for the hash type the transaction stops being a P2SH transaction and there's no way to make it one anymore.
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
paraipan
In memoriam
Legendary
Offline
Activity: 924
Merit: 1004
Firstbits: 1pirata
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 28, 2012, 11:29:25 PM |
|
Sooo…it seems like the consensus is BIP-16. Don't know where you got that idea. From almost everyone except you ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) and few others if you read the threads on this issue
|
BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
|
|
|
DiThi
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 156
Merit: 100
Firstbits: 1dithi
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 29, 2012, 12:56:39 AM |
|
It is pretty darn close to what I think would be the ideal solution. It even has a byte at the beginning of the redemption script hash that specifies what hash type to use (OP_HASH160) !
Except of course that you can't change the hash type - not even to the other hash type that Bitcoin scripts already support, plain SHA-256 - without getting everyone to upgrade and going through the whole process again. As soon as you change the opcode for the hash type the transaction stops being a P2SH transaction and there's no way to make it one anymore. It wouldn't face the same issues. If there's need for change, it would be just adding a hash function in the validation code. It would be either considered a security problem (so everyone would update as soon as posible) or a non important thing (so everyone updates at its own pace and then people start using it when there's enough support).
|
1DiThiTXZpNmmoGF2dTfSku3EWGsWHCjwt
|
|
|
|