How does an m-of-n multisig condition work?

How does the mechanism work?

A classic script-based multisig construction lists public keys and a required signature count. A 2-of-3 condition accepts an appropriate pair of signatures matching its ordered keys. Any one key alone is insufficient, while losing access to one key may still leave a satisfying pair. This is a statement about the script, not a recommendation for a personal setup.

The script may be hidden behind a hash commitment until spending. With a version-0 witness-script-hash output, the witness program is a 32-byte SHA-256 hash of the witness script. The spender supplies that script and its satisfaction data. Nodes check that its hash matches the earlier commitment before evaluating the condition.

Each signature authorises a transaction message under a signature-hash mode. Participants must agree on what they are authorising: resolved inputs, destination outputs, amounts and relevant conditions. Merely collecting signatures labelled with familiar names does not prove that they cover the same transaction. Changing committed transaction data can invalidate signatures already gathered.

Before counting signatures, establish the complete policy the output committed to. A threshold label can omit alternative branches, time conditions or recovery paths. Each changes what a valid spend may look like. Key ordering also matters to reconstructing the same script hash, even if the set of participants sounds unchanged in prose. A backup description should identify the actual construction instead of recording only a slogan such as several keys required. This helps explain why losing coordinator metadata can be different from losing a signing secret: recovery needs enough information both to find the output and to satisfy its precise conditions.

How do the protocol numbers work in an example?

Consider an invented witness script containing OP_2, three compressed 33-byte public keys, OP_3 and OP_CHECKMULTISIG. Each key needs a one-byte push prefix. The length is 1 + 3 × 34 + 1 + 1 = 105 bytes. The version-0 funding output commits to its 32-byte script hash; its output script is 34 bytes including version and push length.

To spend using the first and third keys, supply their signatures in the order compatible with the script’s key sequence, along with the witness script. The classic CHECKMULTISIG mechanism also consumes an extra dummy stack item; the applicable rules require that dummy to be empty. Omitting it is not corrected by having the right two signatures.

The 105-byte script length does not determine the whole input size. Signature lengths, witness item length prefixes and the transaction’s base fields also contribute. Nor does a 2-of-3 script split the value into thirds. The valid spend consumes the entire referenced output, then creates whatever permitted payment and change outputs the transaction specifies.