Multisignature

Wonder

1. Why does a script requiring two signatures pop three items from the stack?
2. How can an empty byte string be a consensus rule rather than just a convention?
3. What changes when ten keys aggregate into one signature that looks indistinguishable from a single signer’s?

Explore

1. Multisignature scripts mandate that at least m signatures validate against n listed public keys. The locking script lists m, the n public keys and n; OP_CHECKMULTISIG pops n, the n keys, m, and then m signatures, which must match keys in the listed order. If fewer than m valid signatures are supplied, the spend is invalid.
2. A coding error in the original implementation causes OP_CHECKMULTISIG to pop one extra stack item beyond the required signatures. This ‘dummy’ element is ignored during cryptographic verification but must be present; if absent, the stack underflows and the transaction fails. Early spenders used OP_0 as this filler, a convention that persisted for years because nodes accepted any value in that slot.
3. BIP147 (NULLDUMMY), activated with SegWit in August 2017, converted this malleability vector into a consensus rule. The dummy element must now be an empty byte array. Any non-empty value, even a single zero byte, makes the script fail. This eliminated the ability to alter transaction IDs by swapping the dummy’s content, stabilizing the transaction hash for all subsequent confirmations.
4. Standardness rules govern which multisig scripts nodes relay. Bare multisignature outputs are limited to three keys under default Bitcoin Core policy. Wrapped in P2SH, multisig can use up to 15 keys (limited by the 520-byte redeem script); in P2WSH, up to 20. This distinction allows complex corporate treasury setups to function without bloating the base transaction layer.
5. Two newer tools replace legacy multisig patterns. MuSig2 (BIP327, 2023), a separate protocol built on Taproot’s Schnorr signatures, aggregates multiple public keys into a single key and produces a standard Schnorr signature; on-chain, the spend is indistinguishable from an ordinary single-key Taproot spend. Tapscript, part of Taproot itself, adds OP_CHECKSIGADD, which allows incremental signature verification without the stack-pop bug or the 20-key limit of legacy opcodes.
6. To inspect these mechanics, open a block explorer and locate a pre-SegWit bare multisig transaction. Observe the scriptSig: it begins with OP_0 followed by signatures. Compare it with a P2WSH multisig spend, where the witness holds an empty item, the signatures and the witness script listing the keys. Note how the byte counts differ, reflecting the cost of embedding the full key list in the output versus the input.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 7
• BIP147: Dealing with dummy stack element malleability
• BIP327: MuSig2 for BIP340-compatible Multi-Signatures
• BIP342: Validation of Taproot Scripts