<p>Requiring everybody to upgrade is just not realistic for such a small feature.</p>

<p>And clients must already rely on miners to fully validate transactions, because it is always possible a transaction they think is valid is actually half of a double-spend. Never accept 0- or 1-confirmation transactions unless they are from somebody you can trust.</p>

CC BY-SA 3.0
2012-01-27T06:49:17.860Z
I'm not talking about clients like mybitcoin.com who are dumb enough to consider 1 confirmation "enough".  Of course those dumb clients are trusting the miners!  **I'm talking about the other 99% of the bitcoin universe that waits for a lot more than one confirmation.**
lamont cranston
CC BY-SA 3.0
2012-02-26T15:34:29.807Z
If you are giving out a P2SH address to someone, it means you are willing to accept such transactions, and implies you're ready to do the necessary verification for it. It is true however that during the transition phase, old clients will be accepting coins that passed through a P2SH transaction somewhere, and they are indeed relying on the network to do the extra verification required.
Pieter Wuille
CC BY-SA 3.0
2012-01-27T02:23:29.567Z
2012-01-27T02:23:29.567Z
gavinandresen
<p>The <a href="https://en.bitcoin.it/wiki/BIP_0012" rel="nofollow noreferrer">OP_EVAL BIP</a> says that "Avoiding a block-chain split by malicious OP_EVAL transactions requires careful handling of two cases:</p>

<ol>
<li>An OP_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners.</li>
<li>An OP_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners"</li>
</ol>

<p>The later <a href="https://en.bitcoin.it/wiki/BIP_0016" rel="nofollow noreferrer">p2sh</a> and <a href="https://en.bitcoin.it/wiki/BIP_0017" rel="nofollow noreferrer">CHV</a> BIPS list only condition (1).</p>

<p>It sounds to me backward compatibility (avoiding situation 1) is more important than forward compatibility (avoiding condition 2).</p>

<p><strong>Question: what would be the disadvantage of making OP_EVAL/p2sh/CHV a totally new opcode, so that any "old client" would immediately reject any transaction using the new opcode?</strong></p>

<p>This would ensure that situation 1 never happens since all OP_EVAL/p2sh/CHV transactions are invalid for old clients/miners.  Old clients/miners would reject new transactions they haven't been taught about, which is pretty much what you expect to happen when you upgrade your software -- old software might not be able to read data files created by newer software.</p>

<p>You might say "well, then we have to force all the clients to upgrade instead of just the miners"... but the alternative is basically transferring trust from the clients to the miners, so avoiding a client upgrade doesn't come "for free" even though it might seem like it at first.</p>

<p>Right now the clients do all their own validity checking of the blockchain and do not rely on the miners' validity checks at all.  If 75% of the hashpower <a href="https://bitcoin.stackexchange.com/questions/1278/do-miners-have-both-the-incentive-and-ability-to-keep-the-reward-at-50btc">decided to change the validity rules</a> they couldn't -- the clients don't rely on their checks.  The clients (exchanges included!) would promptly proceed to ignore the mutinying miners.  But <strong>OP_EVAL/p2sh/CHV end that clear separation: with "forward compatibility" we are asking people who use these new transactions to consent to a state of affairs in which old clients receiving coins from them will (unknowingly) transfer validity-check responsibility to the mining pool.</strong>  Nobody seems to be talking about that.</p>

<protocol>
Why are p2sh and CHV forward-compatible but not backward-compatible?
lamont cranston
# Why are p2sh and CHV forward-compatible but not backward-compatible?

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

The [OP\_EVAL BIP](https://en.bitcoin.it/wiki/BIP_0012) says that "Avoiding a block-chain split by malicious OP\_EVAL transactions requires careful handling of two cases:

1. An OP\_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners.
2. An OP\_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners"

The later [p2sh](https://en.bitcoin.it/wiki/BIP_0016) and [CHV](https://en.bitcoin.it/wiki/BIP_0017) BIPS list only condition (1).

It sounds to me backward compatibility (avoiding situation 1) is more important than forward compatibility (avoiding condition 2).

**Question: what would be the disadvantage of making OP\_EVAL/p2sh/CHV a totally new opcode, so that any "old client" would immediately reject any transaction using the new opcode?**

This would ensure that situation 1 never happens since all OP\_EVAL/p2sh/CHV transactions are invalid for old clients/miners. Old clients/miners would reject new transactions they haven't been taught about, which is pretty much what you expect to happen when you upgrade your software -- old software might not be able to read data files created by newer software.

You might say "well, then we have to force all the clients to upgrade instead of just the miners"... but the alternative is basically transferring trust from the clients to the miners, so avoiding a client upgrade doesn't come "for free" even though it might seem like it at first.

Right now the clients do all their own validity checking of the blockchain and do not rely on the miners' validity checks at all. If 75% of the hashpower [decided to change the validity rules](https://bitcoin.stackexchange.com/questions/1278/do-miners-have-both-the-incentive-and-ability-to-keep-the-reward-at-50btc) they couldn't -- the clients don't rely on their checks. The clients (exchanges included!) would promptly proceed to ignore the mutinying miners. But **OP\_EVAL/p2sh/CHV end that clear separation: with "forward compatibility" we are asking people who use these new transactions to consent to a state of affairs in which old clients receiving coins from them will (unknowingly) transfer validity-check responsibility to the mining pool.** Nobody seems to be talking about that.

**Tags:** protocol


---

## 1 answers

### Answer by username_1 on 2012-01-27. Score: 1

Requiring everybody to upgrade is just not realistic for such a small feature.

And clients must already rely on miners to fully validate transactions, because it is always possible a transaction they think is valid is actually half of a double-spend. Never accept 0- or 1-confirmation transactions unless they are from somebody you can trust.

> **Comments:**
> **username_0**: I'm not talking about clients like mybitcoin.com who are dumb enough to consider 1 confirmation "enough".  Of course those dumb clients are trusting the miners!  **I'm talking about the other 99% of the bitcoin universe that waits for a lot more than one confirmation.**  
> **username_2**: If you are giving out a P2SH address to someone, it means you are willing to accept such transactions, and implies you're ready to do the necessary verification for it. It is true however that during the transition phase, old clients will be accepting coins that passed through a P2SH transaction somewhere, and they are indeed relying on the network to do the extra verification required.  

---

