BIP 16 big picture

[Gavin Andresen]

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.

[1715268192]

1715268192

[1715268192]

1715268192

[1715268192]

1715268192

[1715268192]

1715268192

[1715268192]

1715268192

[interlagos]

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]

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]

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]

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]

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.

[Costia]

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]

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.

[Steve]

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]

Sooo…it seems like the consensus is BIP-16.

Don't know where you got that idea.

[Steve]

Sooo…it seems like the consensus is BIP-16.

Don't know where you got that idea.

The forum threads on the topic.

[wachtwoord]

By reading the topics on this forum.

[Matt Corallo]

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]

Sooo…it seems like the consensus is BIP-16.

Don't know where you got that idea.

From almost everyone except you  

[makomk]

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.

[paraipan]

Sooo…it seems like the consensus is BIP-16.

Don't know where you got that idea.

From almost everyone except you  

and few others if you read the threads on this issue

[DiThi]

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