3

I was reading Mastering Bitcoin and I read about a bug in CHECKMULTISIG. If the starting ideas of this command should work like this

<Signature B><Signature C> M <Public key A><Public key B> N CHECKMULTISIG

But CHECKMULTISIG works like it needs an extra parameter, so M+1 parameters in total. There's a workaround where you put a 0 at the beginning of the line, for instance, assume that M is equal to 2 and N to 3 (), like this

0 <Signature B><Signature C> 2 <Public key A><Public key B> 3 CHECKMULTISIG

Why can't we fix this? If the consensus is reached, can we fix this? Why should someone not want to fix this?

Improve this question
1
  • I think it remains for backward compatibility. If it changed, then older transactions would no longer work. So it would probably require a new opcode.
    – Zephyrus
    Jan 30 at 13:50

2 Answers 2

Reset to default
5

There are currently Bitcoin on the blockchain at various (non Taproot) addresses locked behind a script that includes the CHECKMULTISIG opcode with the bug in it. So you wouldn't want to change the scripts locking those funds because it might prevent the owner spending them. It would be changing the consensus rules for those funds without the owner's permission.

You could introduce a CHECKMULTISIG2 opcode (as a soft fork) without the bug so that could be used instead of CHECKMULTISIG for future usage. However, the Taproot soft fork introduced a more efficient replacement for CHECKMULTISIG called CHECKSIGADD that doesn't include the CHECKMULTISIG bug. If you use a SegWit v1 address (Taproot) you wouldn't use this CHECKMULTISIG opcode regardless (it was disabled for Taproot spends in BIP342) so there isn't much point introducing a CHECKMULTISIG2 opcode.

Improve this answer
2
  • 2
    You could also fix it by if (script_blockheight < CONSTANT) do_bugged_CHECKMULTISIG(); else do_fixed_CHECKMULTISIG(); that way the old ones work.
    – Joshua
    Jan 31 at 3:00
  • @Joshua or rather, output_blockheight. The script may be a P2SH script provided in a newer block. Also every wallet software has to learn two different types of input script for the same output script.
    – user253751
    Jan 31 at 13:20
3

Changing the behavior of an op-code could mean that old (unupgraded) nodes interpret a transaction with that op-code differently than new (upgraded) nodes. If nodes interpret transactions in two different ways, this may cause the network to split as some nodes accept a block as valid while others reject it as invalid. We call such a breaking change in the protocol rules a “hard fork”.

Since we cannot go back and change how old software behaves and cannot force users to upgrade their software, we are careful to introduce changes in a forward-compatible manner. If we introduce new behavior, then in a way that makes the old nodes accept it, even when old nodes cannot fully validate the underlying script. We call this style of protocol rule upgrade a “soft fork”.

Changing OP_CHECKMULTISIG to pop one fewer element off the stack would be a hard fork. Even if a majority of the nodes was upgraded when such a rule took effect, the first transaction that makes use of the new rule would cause all old nodes to stop processing the most-work chain, forking the old nodes off the network.

Improve this answer
2
  • Yeah, but this is true about lots of bitcoin changes, and it's not considered impossible to solve.
    – user253751
    Jan 31 at 12:54
  • Sure, there are ways to make it smoother, e.g. putting in the fix now to activate for outputs starting five years from now. It’s still a hard fork because anyone that will still fork off anyone that hasn’t upgraded at that time. And it would still break chains of presigned unbroadcast transactions.
    – Murch ♦
    Jan 31 at 13:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.