Multisig & Timelocks

Multisig means multiple keys must cooperate to spend. Timelocks add “not before” constraints. Together they power vaults, inheritance designs, and Lightning’s security model.

Complete Step 1 // Required reading in the study plan above, then continue here.

Step 2 — Core idea: thresholds and time

Shared custody without multisig is usually a single point of failure. Lightning’s justice system depends on relative timelocks. Blurring absolute vs relative time creates unsafe contracts.

Analogy: Multisig is a safe deposit box needing two keys. A timelock is a time-delay lock that refuses to open until a date — or until enough time has passed since the box was last sealed.

Classic Script uses OP_CHECKMULTISIG for on-chain m-of-n. Modern approaches often prefer Taproot + MuSig2 so cooperative spends look like single-sig.

Policy example: 2-of-3 keys OR (1 key after 90 days)

• CLTV (BIP-65): absolute — unlock after a block height or timestamp
• CSV (BIP-112 / BIP-68): relative — unlock after the output has confirmed for a relative period

Lightning commitments lean on CSV so old states become punishable after delays.

Done when: You can say when you’d pick CLTV vs CSV for a recovery path.

Step 3 — Try it: sketch a policy (lab)

Write one custody policy in plain language, then map it:

Optionally on regtest:

bitcoin-cli -regtest getdescriptorinfo "wsh(multi(2,...))"

(Use a real descriptor from your wallet docs — do not invent keys for mainnet.)

Common mistakes

• Building 2-of-3 without tested recovery paths and key ceremonies
• Using absolute locks where relative locks were required (and vice versa)
• Forgetting that mempool policy may delay non-standard scripts

Done when: Lab evidence (policy line + BIP pointer + optional descriptor) is complete.

Next lesson

Mempool & Fees — how unconfirmed transactions compete and how fee bumping works.