Why is BIP-147 (Dealing with dummy stack element malleability, part of segwit) necessary?

0

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 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 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?

Rich Apodaca

Posted 2017-06-22T13:38:37.723

Reputation: 1 896

Answers

1

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.

Pieter Wuille

Posted 2017-06-22T13:38:37.723

Reputation: 54 032

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 – 2018-10-26T16:57:35.690

@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 – 2018-10-26T17:01:07.687

Asked: 2017-06-22T13:38:37.723

Viewed: 241 times

Active: 2017-06-22T16:35:32.483