<p>BIP 11 is not a consensus rule, but a recommendation on how to use multisig on the network.</p>

<p>BIP 147 is correct in describing the existing network consensus rules: OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY pop one element more off the stack then needed, and ignore that element. BIP 147 changes the rule to make these opcodes not ignore the element, but require it to be a 0. To be compliant with BIP 11, transactions already had to put a 0 zero there, and in practice everyone always has. But there was no requirement that transactions follow BIP11 - it was just a recommendation for better interoperability. With BIP147 it becomes required to have a 0 there for every transaction to be valid.</p>

<p>The reason for changing this is malleability: currently, anyone can take a valid transaction that uses any of these opcodes, and take the 0 and replace it with anything else, without invalidating the transaction.</p>

<p>Ideally, we would want to fix the bug entirely, and make OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY  not pop off an unneeded stack element. However, that would be backward incompatible, and thus only apply to new transactions if we don't want to break existing software. The approach in BIP147 applies to all multisig transactions.</p>

CC BY-SA 4.0
2018-10-26T16:57:35.690Z
Is the extra-element bug addressed any differently in SegWit transactions? I'm looking at a SegWit multisig redeeming input and I think I see an "empty" stack item followed by 2 signatures, then followed by the P2SH redeem script. Is that first empty stack item `""` the dummy element for CHECKMULTISIG?
pinhead
CC BY-SA 4.0
2018-10-26T17:01:07.687Z
@pinhead Yes and no. 0 is encoded as "" on the script execution stack, so OP_0 really just pushes an empty stack element, and BIP147 doesn't actually require OP_0 - it just requires an empty stack element. In SegWit, the input stack is encoded directly rather than as a sequence of opcodes (as is the case in scriptSig). As a result, the dummy CMS argument in the witness stack is indeed just "".
Pieter Wuille
CC BY-SA 3.0
2017-06-22T16:35:32.483Z
2017-06-22T16:35:32.483Z
Pieter Wuille
<p>Given BIP-11 (M-of-N Standard Transactions) it's not clear why BIP-147 (Dealing with dummy stack element malleability) is necessary.</p>

<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki" rel="nofollow noreferrer">BIP-11</a> states:</p>

<blockquote>
  <p>OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig:</p>

<pre><code>OP_0 ...signatures...
</code></pre>
  
  <p>(OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack).</p>
</blockquote>

<p>Yet <a href="https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki" rel="nofollow noreferrer">BIP-147</a> claims:</p>

<blockquote>
  <p>A design flaw in OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY causes them to consume an extra stack element ("dummy element") after signature validation. <em>The dummy element is not inspected in any manner</em>, and could be replaced by any value without invalidating the script. ... [my emphasis]</p>
</blockquote>

<p>This statement appears to contradict BIP-11, which clearly requires OP_0 as the first validation script element.</p>

<p>I can think of two reasons for BIP-147:</p>

<ol>
<li>BIP-11 doesn't explicitly require the stack to be checked but just that a multisignature validation script begins with OP_0;</li>
<li>BIP-11 doesn't apply at all to OP_CHECKMULTISIGVERIFY.</li>
</ol>

<p>Are these indeed motivations for BIP-147, and are there others?</p>

<segregated-witness><multi-signature><transaction-malleability>
Why is BIP-147 (Dealing with dummy stack element malleability, part of segwit) necessary?
Rich Apodaca
# Why is BIP-147 (Dealing with dummy stack element malleability, part of segwit) necessary?

(Asked by: username_0 on 2017-06-22)

Given BIP-11 (M-of-N Standard Transactions) it's not clear why BIP-147 (Dealing with dummy stack element malleability) is necessary.

[BIP-11](https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki) states:

> OP\_CHECKMULTISIG transactions are redeemed using a standard scriptSig:
>
> ```
> OP_0 ...signatures...
>
> ```
>
> (OP\_0 is required because of a bug in OP\_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack).

Yet [BIP-147](https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki) claims:

> A design flaw in OP\_CHECKMULTISIG and OP\_CHECKMULTISIGVERIFY causes them to consume an extra stack element ("dummy element") after signature validation. *The dummy element is not inspected in any manner*, and could be replaced by any value without invalidating the script. ... [my emphasis]

This statement appears to contradict BIP-11, which clearly requires OP\_0 as the first validation script element.

I can think of two reasons for BIP-147:

1. BIP-11 doesn't explicitly require the stack to be checked but just that a multisignature validation script begins with OP\_0;
2. BIP-11 doesn't apply at all to OP\_CHECKMULTISIGVERIFY.

Are these indeed motivations for BIP-147, and are there others?

**Tags:** segregated-witness, multi-signature, transaction-malleability


---

## 1 answers

### Answer by username_1 on 2017-06-22. Score: 2 | Accepted answer

BIP 11 is not a consensus rule, but a recommendation on how to use multisig on the network.

BIP 147 is correct in describing the existing network consensus rules: OP\_CHECKMULTISIG and OP\_CHECKMULTISIGVERIFY pop one element more off the stack then needed, and ignore that element. BIP 147 changes the rule to make these opcodes not ignore the element, but require it to be a 0. To be compliant with BIP 11, transactions already had to put a 0 zero there, and in practice everyone always has. But there was no requirement that transactions follow BIP11 - it was just a recommendation for better interoperability. With BIP147 it becomes required to have a 0 there for every transaction to be valid.

The reason for changing this is malleability: currently, anyone can take a valid transaction that uses any of these opcodes, and take the 0 and replace it with anything else, without invalidating the transaction.

Ideally, we would want to fix the bug entirely, and make OP\_CHECKMULTISIG and OP\_CHECKMULTISIGVERIFY not pop off an unneeded stack element. However, that would be backward incompatible, and thus only apply to new transactions if we don't want to break existing software. The approach in BIP147 applies to all multisig transactions.

> **Comments:**
> **username_2**: Is the extra-element bug addressed any differently in SegWit transactions? I'm looking at a SegWit multisig redeeming input and I think I see an "empty" stack item followed by 2 signatures, then followed by the P2SH redeem script. Is that first empty stack item `""` the dummy element for CHECKMULTISIG?  
> **username_1**: @username_2 Yes and no. 0 is encoded as "" on the script execution stack, so OP_0 really just pushes an empty stack element, and BIP147 doesn't actually require OP_0 - it just requires an empty stack element. In SegWit, the input stack is encoded directly rather than as a sequence of opcodes (as is the case in scriptSig). As a result, the dummy CMS argument in the witness stack is indeed just "".  

---

