By the way... if there is no fully-functional reference implementation yet, you really shouldn't be putting "CHV" in your coinbases yet. The string in the coinbase really aught to mean "this code is all ready to support this feature," because full support from a majority of hashing power is what we want to measure.
@s{quotedtext} @s{quotedtext}
Imagine you're an early adopter. You ask people to send you money into your spiffy new ultra-secure wallet.
With BIP 16, transactions TO you will take longer to get into a block because not everybody is supporting the new feature.
But transactions FROM you will look like regular transactions, so the people you are paying won't have to wait.
That is not a big difference, but it is an advantage of the BIP 16 approach.
@s{quotedtext} @s{quotedtext}
No, they are not evaluated in the same way. The bit of code in bitcoin transaction validation that makes me nervous is:
Code:
txTmp.vin[nIn].scriptSig = scriptCode;
... in SignatureHash(), which is called from the CHECKSIG opcodes. scriptCode is the scriptPubKey from the previous (funding) transaction, txTmp is the transaction being funded.This is the "Copy the scriptPubKey into the scriptSig before computing the hash that is signed" part of what OP_CHECKSIG does.
I like BIP 16 better than OP_EVAL/BIP 17 because BIP 16 does two complete validations, once with the scriptPubKey set to HASH160 <hash> OP_EQUAL and then once again with the scriptPubKey set to (for example) <pubkey> OP_CHECKSIG.
BIP 16 essentially says "If we see a P2SH transaction, validate it, then treat it is a normal, standard transaction and validate it again."
BIP 17 will run OP_CHECKSIGs when it is executing the scriptSig part of the transaction, which is a completely different context from where they are executed for the standard transactions we have now.
Again, I can't see a way to exploit that but it makes me very nervous.