<p>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.</p>

<p>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.</p>

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

<p>Read the post for more detail.</p>

CC BY-SA 3.0
2012-01-15T09:54:37.880Z
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
CC BY-SA 3.0
2012-01-15T09:36:47.410Z
2012-01-15T09:36:47.410Z
Pawel
<p>There are three BIPs which all aim to provide the push-to-script-hash (P2SH) feature:</p>

<p>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.<ul><li>Disadvantages: This makes Bitcoin Scripting turing-complete (it enables loops), and not statically analyzable.</li><li>Advantages: You can do things that require a turing-complete language in Scripts.</li></ul></p>

<p>BIP 16: When a magic Script template is seen, after the Script is done executing clients must then execute the top stack item also.<ul><li>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.</li><li>Advantages: Retains the current mostly-staticly-analyzable status of Scripts.</li></ul></p>

<p>BIP 17 (OP_CHECKHASHVERIFY): A new opcode hashes the Script that has already been executed, and simply compares it to the top stack item.<ul><li>Disadvantages: Cannot be used to evaluate code in any capacity.</li><li>Advantages: Statically analyzable using the same exact method as right now, and only requires a trivial opcode addition without restructuring the entire Script protocol.</li></ul></p>

<p>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.</p>

CC BY-SA 3.0
2012-01-19T01:51:02.997Z
2012-01-19T01:51:02.997Z
Luke Dashjr
<p>BIP 12 creates a new Script opcode which allows scripts to execute more script stored in a string (like <em>eval</em> 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.</p>

<p>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.</p>

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

<p>All of these proposals are designed to solve the problem of how to allow <em>recipients</em> 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.</p>

CC BY-SA 3.0
2012-01-15T09:53:15.653Z
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
CC BY-SA 3.0
2012-01-15T10:01:45.740Z
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
CC BY-SA 3.0
2012-01-15T10:05:07.573Z
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
CC BY-SA 3.0
2012-01-15T10:23:20.297Z
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
CC BY-SA 3.0
2012-01-16T23:29:04.960Z
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
CC BY-SA 3.0
2012-01-15T09:46:12.233Z
2012-01-15T09:46:12.233Z
theymos
<p>There is <a href="https://bitcointalk.org/index.php?topic=58579.0;viewResults">a discussion</a> 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.</p>

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

CC BY-SA 3.0
2012-01-15T09:57:28.180Z
Why the "TL;DR" in the question title?
D.H.
CC BY-SA 3.0
2012-01-15T10:02:22.293Z
@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
<bip12><p2sh>
What are the implications of BIP 12 vs BIP 16 and OP_CODEHASHCHECK?
ripper234
# What are the implications of BIP 12 vs BIP 16 and OP_CODEHASHCHECK?

(Asked by: username_0 on 2012-01-15)

There is [a discussion](https://bitcointalk.org/index.php?topic=58579.0;viewResults) 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?

**Tags:** bip12, p2sh

> **Comments:**
> **username_1**: Why the "TL;DR" in the question title?  
> **username_0**: @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.  

---

## 3 answers

### Answer by username_4 on 2012-01-15. Score: 3 | Accepted answer

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.

> **Comments:**
> **username_0**: 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?  
> **username_4**: 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.  
> **username_0**: 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?  
> **username_4**: 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.)  
> **username_5**: 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.  

---

### Answer by username_2 on 2012-01-15. Score: 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 username_3-Jr who proposed using his own solution, OP\_CODEHASHCHECK, instead of P2SH.

Read the post for more detail.

> **Comments:**
> **username_0**: 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.  

---

### Answer by username_3 on 2012-01-19. Score: 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.


---

