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

Question

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?

Answer 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.