TYPE 0x0002 · SIGNATURE FAMILY

MULTISIG

K-of-N threshold signature verification. The N pubkeys are committed via an inner Merkle root in conditions; at spend time the witness reveals K signers as (PUBKEY, MERKLE_PROOF, SIGNATURE) triplets. Unrevealed slots cost no on-chain bytes and cannot carry attacker-chosen data.

Signature Non-Invertible

Ladder Diagram

Fields

Field	Data Type	Size	Side	Description
threshold (K)	NUMERIC	1 B	Conditions	Required number of valid signatures. K must satisfy 1 ≤ K ≤ N (N = supplied pubkey count, max 16). Out-of-range K is rejected at fund time by `createrungtx` (F25) and at consensus by the spend-time evaluator.
scheme	SCHEME	1 B	Conditions	Signature scheme (Schnorr, ECDSA, FALCON-512, …) shared by all signers
pubkey_root	HASH256	32 B	Conditions	Inner Merkle root over the N pubkey set (tagged-hash domain `LadderMultisigPubkey/v1`)
pubkey[i]	PUBKEY	32-33 B	Witness	Position i of K signer triplets — revealed pubkey
merkle_proof[i]	MERKLE_PROOF	0-128 B	Witness	Inclusion proof for pubkey[i] against pubkey_root (depth ≤ 4)
signature[i]	SIGNATURE	64-65 B	Witness	Signature under pubkey[i]

v2 inner-Merkle commitment: pubkey_root binds the N-pubkey set in conditions; the witness carries exactly K (PUBKEY, MERKLE_PROOF, SIGNATURE) triplets. Unrevealed slots are not on the wire.

Wire Format Breakdown

Conditions side (committed in the rung leaf; size independent of N because the N pubkeys are folded into a single 32-byte inner Merkle root):

0x0002 0 3 NUMERIC K · 1B SCHEME · 1B HASH256 root · 32B = 38 bytes

Witness side (example 2-of-3 — depth-2 inner tree, 1 sibling per proof):

0x0002 0 6 PK · 33B PROOF · 64B SIG · 64B PK · 33B PROOF · 64B SIG · 64B = ~330 bytes

Total (conditions + witness, 2-of-3) ~368 bytes

Conditions size is fixed at 38 bytes regardless of N. Witness scales as K · (PUBKEY + MERKLE_PROOF + SIGNATURE); the proof grows logarithmically in N (max 128 bytes per signer for N=16).

Evaluation Logic

1. Read threshold K from the conditions NUMERIC field. If K < 1 → ERROR

2. Witness must contain exactly K triplets (PUBKEY, MERKLE_PROOF, SIGNATURE) in strict ascending pubkey-lex order. Otherwise → ERROR

3. For each triplet: verify the MERKLE_PROOF against pubkey_root (the conditions HASH256) using the inner pubkey-Merkle scheme — tagged hash LadderMultisigPubkey/v1 for leaves, LadderMultisigInternal/v1 for interior nodes, LadderMultisigPadding/v1 for empty-leaf padding. Proof failure → UNSATISFIED

4. For each triplet: verify the SIGNATURE against the revealed PUBKEY using the conditions SCHEME. Any signature fails → UNSATISFIED

5. All K Merkle proofs and K signatures valid → SATISFIED

Return Values

Condition	Result
Conditions missing NUMERIC(K), SCHEME, or HASH256(pubkey_root)	ERROR
Threshold K < 1	ERROR
Witness triplet count != K, or triplets not strict-ascending by pubkey	ERROR
Any inner-pubkey-Merkle proof fails to reconstruct pubkey_root	UNSATISFIED
Any signature fails verification against its pubkey	UNSATISFIED
All K Merkle proofs and K signatures valid	SATISFIED

JSON Wire Format

Conditions (committed in the rung leaf, 2-of-3 example)

{
  "type": "MULTISIG",
  "inverted": false,
  "fields": [
    { "type": "NUMERIC", "value": 2 },
    { "type": "SCHEME", "hex": "01" },
    { "type": "HASH256", "hex": "<pubkey_root, 32 bytes>" }
  ]
}

The N pubkeys themselves never appear in the conditions — only the root binds them. createrungtx / signrungtx accept the N-pubkey list as a side hint and compute the root automatically.

Witness (input, 2-of-3 example — K=2 ordered triplets)

{
  "type": "MULTISIG",
  "inverted": false,
  "fields": [
    { "type": "PUBKEY",       "hex": "02abc1...33 bytes" },
    { "type": "MERKLE_PROOF", "hex": "<sibling hashes, 0–128 bytes>" },
    { "type": "SIGNATURE",    "hex": "<sig under pubkey #1>" },
    { "type": "PUBKEY",       "hex": "03def2...33 bytes" },
    { "type": "MERKLE_PROOF", "hex": "<sibling hashes, 0–128 bytes>" },
    { "type": "SIGNATURE",    "hex": "<sig under pubkey #2>" }
  ]
}

Triplet ordering is strict-ascending by pubkey lex; reordering triplets changes the wtxid and is rejected at deserialisation.

Use Cases

Multi-Party Escrow

A 2-of-3 MULTISIG where buyer, seller, and arbitrator each hold a key. Any two parties can release funds, enabling trustless escrow with dispute resolution.

Corporate Treasury

Organizational funds protected by M-of-N threshold policy. Requires multiple officers to authorize spending, preventing single-point-of-compromise theft.

Backup Key Schemes

A 1-of-3 setup where the primary key, a hardware wallet backup, and a social recovery key can each independently spend. Prevents permanent loss from any single key compromise or loss.

← SIG ADAPTOR_SIG →