Gavin Andresen - 2012-01-20 16:53:31

I haven't seen discussion of BIP 17 anywhere besides IRC, so I thought I'd start one.

I'll start by saying that I'm trying hard to put aside my biases and dispassionately evaluating the proposal on its merits (I'll just say that I'm not happy with the way BIP 17 came to be, but it is what it is).

Quick executive summary of BIP 17:

A new opcode is proposed, OP_CODEHASHVERIFY, that replaces OP_NOP2.

It is used in a new "standard" scriptPubKey that looks like:

Code:
<hash> OP_CODEHASHVERIFY OP_POP

... which is redeemed using a scriptSig like (for example, a 2-of-2 CHECKMULTISIG):

Code:
OP_0 <signature> OP_CODESEPARATOR 2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG


OP_CODEHASHVERIFY is defined to take the hash of everything in the scriptSig from the last OP_CODESEPARATOR and compare it to the top item on the stack. If the hashes match, then it is a no-op, otherwise script validation fails. (see the spec for all the details for what happens if there is no CODESEPARATOR or a CODEHASHVERIFY is put in the scriptSig)


BIP 17 is an alternative to BIP 16, which has a scriptPubKey:

Code:
OP_HASH160 <hash> OP_EQUAL

... which is redeemed with:

Code:
OP_0 <signature> OP_PUSHDATA(2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG)


I see the appeal of BIP 17 -- the redeeming opcodes aren't "hidden" as serialized bytes, they're right there in the scriptSig. That feels less like a hack.

However, there are a couple of practical reasons I like BIP 16 better:


I also have some theoretical, "just makes me feel uncomfortable" reasons for disliking BIP 17: