Scripts and miniscript

Almost everything written about bitcoin describes ownership as holding a key. That is the common case, not the rule. What the network actually enforces is a condition — and "a valid signature from this key" is merely the simplest condition anyone writes.

The conditions can be considerably richer: two of these three keys, or this one key after a year has passed, or this key today and that key from next March. The chain enforces all of it mathematically, with no institution involved and no way to appeal.

1Outputs carry conditions, not owners

Every output on the chain has a small program attached, written in a language called Script. To spend that output, you supply data satisfying the program. Nodes run it, and the coins move only if it succeeds.

For an ordinary payment the program says: provide a signature matching this public key. That is why we talk about keys as ownership — in the overwhelming majority of cases, they are the whole condition.

But Script has other pieces available. It can require several signatures. It can check that a certain block height has passed, or that a specified duration has elapsed since the coin was created. It can offer alternative routes and accept whichever is satisfied. Combine those and you can express arrangements no bank product corresponds to.

2Timelocks: conditions that arrive later

The piece that makes genuinely interesting arrangements possible is bitcoin's ability to enforce time.

• Absolute timelocks make an output unspendable until a stated block height or date. "Not before 2030" is enforceable by every node.
• Relative timelocks count from when the coin was created. "Not until six months after this coin appeared" — useful because the clock starts when you move funds in, rather than at a fixed calendar point you must keep updating.

Crucially, timelocks can sit on one branch of a condition while other branches remain available immediately. That is what turns them from a curiosity into the basis of real inheritance and recovery designs: the normal path works today, and a fallback path quietly becomes available if the normal one goes unused for long enough.

A bank of safe deposit boxes with three different keyholes on one door, and a small brass dial beside them showing a date rather than a combination.

Image to come

3Why nobody wrote raw Script

Script is a low-level stack language, and writing it by hand is genuinely dangerous. The failure modes are not the friendly kind where something does not work — they are the kind where it works today and locks your money away permanently under conditions you did not intend.

• A subtly wrong script can be unspendable. The coins arrive, the address is valid, and nothing you ever do will move them again.
• It can be spendable by the wrong person, if a branch you did not think through is satisfiable more easily than you assumed.
• You often cannot tell by reading it which of those you have written. Analysing an arbitrary script for these properties is not something a person can do reliably by eye.
• Wallets cannot estimate fees for it, because they cannot know what a spend will cost without understanding the script's structure.

The practical result was that complex conditions stayed the preserve of specialists writing bespoke code, and everyone else used plain multisig even when it fitted their problem poorly.

4Miniscript

Miniscript is a restricted, structured way of writing the useful subset of Script — and the restriction is the entire point. By limiting how pieces may be assembled, it makes the resulting policy something software can analyse rather than merely execute.

• It can be checked for correctness. Software can prove a miniscript is spendable by the parties intended, and cannot be spent by anyone else. The catastrophic failure of a hand-written script becomes a compile-time error.
• It composes. Conditions can be built from smaller ones — this key AND that timelock, OR two of these three — without the combination producing surprises.
• Wallets can work with it. They can compute the cost of each spending path, so fee estimation works and coin selection behaves.
• It is readable. A policy can be written in a form a careful person can actually check against what they meant, and it travels inside a descriptor alongside the keys and derivation paths.
• It is not a new protocol. Miniscript compiles to ordinary Script that existing nodes already validate. Nothing had to change for it to work.

A policy might read, in plain English: three of five company keys can spend at any time; or two of five, but only after ninety days; or a single recovery key after one year. Ordinary multisig cannot express that at all — it has exactly one quorum, fixed forever. Miniscript expresses it, proves it does what it says, and produces an address that looks utterly unremarkable.

5What this makes possible

• Inheritance that does not need a lawyer to execute. You spend normally; if your key goes unused for a year, an heir's key becomes able to spend. No custodian, no dead man's switch to maintain, no trust in anyone's cooperation.
• Degrading quorums. A high bar for normal operation that relaxes over time, so losing keys becomes survivable without making theft easy today.
• Business controls. Two officers to move funds during the week, more required for larger amounts, a slow recovery path if the company reorganises.
• Collaborative custody with a real exit. A partner co-signs while the arrangement is active, and drops out automatically if they stop being available.

That last pattern is worth a concrete example, because a live product implements it and it demonstrates the whole idea better than any abstract description.

A worked example: AnchorWatch

AnchorWatch is a Lloyd's of London coverholder offering insured bitcoin custody, and its Trident Vault is built on miniscript rather than plain multisig. The reason is precisely the expressiveness described above.

While the insurance policy is active, AnchorWatch is a required co-signer — which is what makes the coverage underwritable, since they can enforce controls on how funds move. They cannot spend unilaterally at any point. And the vault carries timelocked recovery paths, so if keys are lost, destroyed, or become unavailable through death or staff changes, different combinations of keys become usable as time passes.

The elegant part is what happens when the policy lapses. The timelocks expire and the vault degrades into plain self-custody — the customer's keys alone become sufficient, with no cooperation from AnchorWatch required and no action needed from them to release it. Renewing the policy restarts the clocks. The company's continued existence is not a dependency, which is a property no amount of contract drafting can provide.

6Before you build one

Everything above is real and available today. It is also a place where enthusiasm outruns caution, so a few things need saying plainly.

• A complex policy is more to back up, not less. Rebuilding it needs the full descriptor — every public key, every path, every condition. Keys alone will not do it, exactly as with multisig, and the consequences of losing that record are the same.
• Wallet support is uneven. Miniscript handling has improved considerably, but not every wallet and not every signing device copes with every policy. Verify your whole chain of tools before funding anything.
• Timelocks are unforgiving. A path that unlocks in a year unlocks in a year. There is no early release and nobody to ask.
• Test every branch. Not just the everyday path — the recovery path, the timelocked path, the one your family would need. On a testnet or with trivial amounts, before it matters.
• Complexity you cannot explain is complexity you should not deploy. If you cannot describe the policy in one paragraph to the person who would have to use the fallback, it is not finished.

The short version

Bitcoin outputs carry conditions, and conditions can involve multiple keys, deadlines, and alternative routes that open over time. Writing those in raw Script risks locking funds away forever. Miniscript constrains the language so software can prove what a policy does before you rely on it, which moves these arrangements from specialist territory into something a careful person can use.

The obligation that comes with it is the same one multisig carries, only larger: the keys are not enough. The description of the policy is part of your backup, and without it the money is unreachable no matter how many keys you hold.