CONCEPT // KEYS + CUSTODY
What is multisig?
m-of-n: several keys, a quorum to spend. Trading single points of failure for setup work.
A single key is one point of failure. Lose it and the coins are stuck. Someone else finds it and the coins are theirs. Multisig replaces that single key with a quorum: n keys exist, and m of them must sign. Two-of-three is the usual first pattern.
What it buys
Loss and theft stop being the same event. In a 2-of-3, one destroyed key does not stop a spend, because the other two still meet the quorum. One stolen key is not enough to move the coins either. You have bought redundancy against loss and a threshold against theft. You have paid for it in setup.
The descriptor is part of the backup
Each key still has its own seed phrase. The seeds are not sufficient. You also need the wallet configuration: which keys, in which order, under which script. Output descriptors (BIP380) are the text form of that configuration. Restore enough seeds to sign but lose the descriptor, and you may not be able to rebuild the addresses at all: the script needs every cosigner’s public key, including the ones whose seeds you are not holding.
Some setups add a timelock, so that after a delay a smaller set of keys can spend. That is a real script rule (absolute or relative timelocks). The delay you choose is a policy, not a protocol constant. A “one year” lock in a game is a sample of that idea.
When to bother
For a small first amount, a single signature and a careful backup is the usual start. Multisig earns its complexity when the amount, or the number of people, makes a single key unacceptable. It does not remove the need to keep each seed offline. It multiplies that job by n, and adds the descriptor.
Facts checked against protocol constants · no invented stats.