Topic: BIP 16 big picture (Read 2781 times)

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

and few others if you read the threads on this issue

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.

From almost everyone except you  

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. 

By reading the topics on this forum.

The forum threads on the topic.

Don't know where you got that idea.

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?

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.

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

No. P2SH transactions can only have data in the scriptSig -- the OP_DUPs wouldn't be allowed.

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?

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

This can be fixed with or without P2SH of any kind.

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

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.