6

There is a discussion about two different Bitcoin Improvement Proposals - BIP 12 and BIP 16, and probably only one of them is going to be included in Bitcoin 0.6 (miners will decided which by a majority vote of mining power). LukeJr proposed an alternative to BIP 16 called OP_CODEHASHCHECK.

Can anyone summarize the core differences between the three proposals, and their respective advantages / disadvantages?

Improve this question
2
  • Why the "TL;DR" in the question title?
    – D.H.
    Commented Jan 15, 2012 at 9:57
  • 1
    @D.H. - well, I originally put it there because the answers I seek might be contained in the long discussion I linked to ... but you're right, the question is legit without this prefix.
    – ripper234
    Commented Jan 15, 2012 at 10:02

3 Answers 3

Reset to default
3

BIP 12 creates a new Script opcode which allows scripts to execute more script stored in a string (like eval functions in other languages). There's not much debate about BIP 12: it will not be used. It's very complicated, it allows some looping (which Script should not support), and it makes it difficult to analyze scripts without executing them.

With BIP 16, scripts are allowed to execute scripts stored in a string one time (not recursively), and there are also other restrictions that eliminate all of the BIP 12 drawbacks mentioned above.

CODEHASHCHECK does the same thing as BIP 16, but some technical differences make it arguably more elegant.

All of these proposals are designed to solve the problem of how to allow recipients to choose which restrictions to place on coins they receive at an address (two-factor authentication, etc.). Currently senders always define the restrictions on sent coins, which is inconvenient in many cases.

Improve this answer
5
  • Thanks. I updated my question to be about the comparison between all three proposals. Can you please elaborate on the technical differences between BIP 16 and CODEHASHCHECK?
    – ripper234
    Commented Jan 15, 2012 at 9:53
  • With BIP 16, scripts that match a certain template (OP_HASH160 hash OP_EQUAL) have additional checks applied to them even though these additional checks are not specified explicitly in the script. BIP 16 creates no new opcodes. CODEHASHCHECK does create a new opcode to do the checking. BIP 16 would be the only case of "template-based" behavior in Script, so I think that CODEHASHCHECK is more consistent with the rest of Script and should be preferred.
    – theymos
    Commented Jan 15, 2012 at 10:01
  • So ... is the difference between them merely a matter of style? Is there a functional difference? Could you explain it as if I were a ten year old? (Or just someone without much knowledge in the core Bitcoin protocol), perhaps with an example of why this matters?
    – ripper234
    Commented Jan 15, 2012 at 10:05
  • 2
    For me it's mostly a matter of style. CHC does not use ugly scripts-within-strings or template-matching. BIP 16 has lower data size and a simpler implementation, but it's clearly a hack. This will define a protocol which may last years, so style counts. (I don't care that much, though -- either would be acceptable.)
    – theymos
    Commented Jan 15, 2012 at 10:23
  • 1
    I strongly disagree that CHC is more elegant. It adds an opcode that behaves differently based on whether or not the opcode appears in the scriptSig or the scriptPubKey.
    – gavinandresen
    Commented Jan 16, 2012 at 23:29
2

The biggest drawback of OP_EVAL (BIP 12) was making the scripting system used for transactions turing complete, thus blowing any attempt at static analysis out of the water. This was regarded as a very serious issue and BIP12 has been pretty much shot and buried.

P2SH (BIP 16) is intended as another approach to the same problem of introducing multiple-key authorized transactions at protocol level. It is specifically designed (as the original scripting system was) not to be turing complete.

There was a lively discussion between the core developers and Luke-Jr who proposed using his own solution, OP_CODEHASHCHECK, instead of P2SH.

Read the post for more detail.

Improve this answer
1
  • 1
    Thanks for the info. I updated my question to include OP_CODEHASHCHECK in the comparison as well - what I'd really like to know is what is the big difference between OP_CODEHASHCHECK and BIP 16. I might go and read the post, but until I do (and for those who don't), it would be good to summarize the core difference here.
    – ripper234
    Commented Jan 15, 2012 at 9:54
0

There are three BIPs which all aim to provide the push-to-script-hash (P2SH) feature:

BIP 12 (OP_EVAL): A new opcode takes a value off the stack (from anywhere) and executes it as if it were part of the Script itself.

  • Disadvantages: This makes Bitcoin Scripting turing-complete (it enables loops), and not statically analyzable.
  • Advantages: You can do things that require a turing-complete language in Scripts.

BIP 16: When a magic Script template is seen, after the Script is done executing clients must then execute the top stack item also.

  • Disadvantages: Requires special-casing a Script template and behaving differently than simply executing it as a Script. Cannot be used in combination with the current Bitcoin Script protocol, yet does not deprecate it.
  • Advantages: Retains the current mostly-staticly-analyzable status of Scripts.

BIP 17 (OP_CHECKHASHVERIFY): A new opcode hashes the Script that has already been executed, and simply compares it to the top stack item.

  • Disadvantages: Cannot be used to evaluate code in any capacity.
  • Advantages: Statically analyzable using the same exact method as right now, and only requires a trivial opcode addition without restructuring the entire Script protocol.

Also note, that BIP 17 does not preclude BIP 12 or 16 from being implemented in the future, should some other need for their more complicated capabilities arise.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.