I haven't seen discussion of BIP 17 anywhere besides IRC, so I thought I'd start one.
I was waiting until I finished a reference implementation to post about it, but thanks for the early review. 
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.
Quote
With BIP 17, both transaction outputs and inputs fail the old IsStandard() check, so old clients and miners will refuse to relay or mine both transactions that send coins into a multisignature transaction and transactions that spend multisignature transactions.
Since scriptSigs must always follow scriptPubKey, does this really make a big difference? ie, if people can't send them, they can't receive them anyway.
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.
Quote
OP_CHECKSIG feels like it was originally designed to be in the scriptPubKey-- "scriptSig is for signatures." Although I can't see any way to exploit an OP_CHECKSIG that appears in the scriptSig instead of the scriptPubKey, I'm much less confident that I might have missed something.
It's evaluated the exact same way in all 3 scripts, and already accepted in scriptPubKey. If there is an attack vector here (which seems very unlikely), it is there both with or without BIP 17.
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.