<p>It's not prepending a script with OP_0. It's a data push that contains the witness program hash, prepended by OP_0.</p>

<p>Old nodes will evaluate this as a script that just pushes two data items onto the stack (a 0 and a hash). That's obviously spendable by all, as the requirement is having a non-zero item as last element on the stack.</p>

CC BY-SA 3.0
2016-01-18T00:01:23.793Z
Thanks. Does 'OP0 hash' evaluate to true automatically to release the coins? And why is the hash of the witness needed? Doesn't that reintroduce malleability back into the txid?
pinhead
CC BY-SA 3.0
2016-01-18T00:02:30.277Z
Any non-zero item left on the stack is interpreted as successful execution. And it's not the hash of the witness, but the hash of the witness program.
Pieter Wuille
CC BY-SA 3.0
2016-01-18T00:28:51.823Z
Then why is OP_0 needed at all? And what is the witness program? The usual 'dup hash equalverify checksig'?
pinhead
CC BY-SA 3.0
2016-01-18T00:31:06.950Z
The witness program is the actual versioned script (the equivalent of the redeemscript in P2SH), which is stored inside the witness. The pubkey commits to it using that hash. The OP_0 before is the witness version number. We can later use higher values to make any script change at all in a softforkable manner.
Pieter Wuille
CC BY-SA 3.0
2016-01-18T00:53:19.430Z
So the actual opcode CHECKSIG is in the witness? Not the scriptPubKey? The examples in the bip141 mediawiki are confusing me
pinhead
CC BY-SA 3.0
2016-01-18T00:53:48.800Z
Then BIP141 needs improvement! I'll relay the message :)
Pieter Wuille
CC BY-SA 3.0
2017-03-15T16:40:39.227Z
@PieterWuille I thought this check meant that successful execution happens only if a non-zero item is on top of the stack AND is the only element on the stack: https://github.com/bitcoin/bitcoin/blob/8152d3fe57a991e9088d0b9d261d2b10936f45a9/src/script/interpreter.cpp#L1508 
So in the case of the witness program the final stack would be [0, <hash>], how would this be interpreted as ANYONECANSPEND by old nodes?
Simone Bronzini
CC BY-SA 3.0
2017-03-15T17:33:18.277Z
@SimoneBronzini The line of code you're referring to is enclosed within a ` `(flags & SCRIPT_VERIFY_CLEANSTACK) != 0` conditional, which is only set for checking standardness, not consensus. So while old clients wouldn't relay such transactions, they are absolutely valid within a block.
Pieter Wuille
CC BY-SA 3.0
2016-01-17T23:30:34.817Z
2016-01-18T00:16:33.050Z
2016-01-18T00:16:33.050Z
Pieter Wuille
<p>Reading the BIP:</p>

<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki" rel="nofollow">https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki</a></p>

<p>I see that the scriptPubKey in a transaction that funds a segwit redemption is the same as a normal P2PKH but merely prepended with <code>OP_0</code>. </p>

<p>Is this opcode what tells older clients that the Tx is "anyone can spend" meaning that there will be no signature data in the redemption Tx?</p>

<p>Of course upgraded nodes will know to look for the actual scriptSig in the witness data to verify the Tx. But how does this <code>OP_0</code> fool old nodes into ignoring the scriptSig on the redemption Tx?</p>

<segregated-witness><blockchain-fork><anyone-can-spend>
Segregated witness soft fork: how is the funding Tx made "ANYONECANSPEND"
pinhead
# Segregated witness soft fork: how is the funding Tx made "ANYONECANSPEND"

(Asked by: username_0 on 2016-01-17)

Reading the BIP:

<https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki>

I see that the scriptPubKey in a transaction that funds a segwit redemption is the same as a normal P2PKH but merely prepended with `OP_0`.

Is this opcode what tells older clients that the Tx is "anyone can spend" meaning that there will be no signature data in the redemption Tx?

Of course upgraded nodes will know to look for the actual scriptSig in the witness data to verify the Tx. But how does this `OP_0` fool old nodes into ignoring the scriptSig on the redemption Tx?

**Tags:** segregated-witness, blockchain-fork, anyone-can-spend


---

## 1 answers

### Answer by username_1 on 2016-01-17. Score: 6 | Accepted answer

It's not prepending a script with OP\_0. It's a data push that contains the witness program hash, prepended by OP\_0.

Old nodes will evaluate this as a script that just pushes two data items onto the stack (a 0 and a hash). That's obviously spendable by all, as the requirement is having a non-zero item as last element on the stack.

> **Comments:**
> **username_0**: Thanks. Does 'OP0 hash' evaluate to true automatically to release the coins? And why is the hash of the witness needed? Doesn't that reintroduce malleability back into the txid?  
> **username_1**: Any non-zero item left on the stack is interpreted as successful execution. And it's not the hash of the witness, but the hash of the witness program.  
> **username_0**: Then why is OP_0 needed at all? And what is the witness program? The usual 'dup hash equalverify checksig'?  
> **username_1**: The witness program is the actual versioned script (the equivalent of the redeemscript in P2SH), which is stored inside the witness. The pubkey commits to it using that hash. The OP_0 before is the witness version number. We can later use higher values to make any script change at all in a softforkable manner.  
> **username_0**: So the actual opcode CHECKSIG is in the witness? Not the scriptPubKey? The examples in the bip141 mediawiki are confusing me  
> **username_1**: Then BIP141 needs improvement! I'll relay the message :)  
> **username_2**: @username_1 I thought this check meant that successful execution happens only if a non-zero item is on top of the stack AND is the only element on the stack: https://github.com/bitcoin/bitcoin/blob/8152d3fe57a991e9088d0b9d261d2b10936f45a9/src/script/interpreter.cpp#L1508  So in the case of the witness program the final stack would be [0, <hash>], how would this be interpreted as ANYONECANSPEND by old nodes?  
> **username_1**: @username_2 The line of code you're referring to is enclosed within a ` `(flags & SCRIPT_VERIFY_CLEANSTACK) != 0` conditional, which is only set for checking standardness, not consensus. So while old clients wouldn't relay such transactions, they are absolutely valid within a block.  

---

