Miniscript

Plain Bitcoin Script is easy to write and close to impossible to reason about: nothing tells you whether a script is spendable, how big its witness will be, or whether a branch is dead. Miniscript restricts the grammar to a set of composable fragments that carry those answers with them. Bitcoin Core has understood it in descriptors since version 24.0 and could sign for it from version 25.0.

How it works

Miniscript is built from fragments that each map onto a known pattern of opcodes, and from combinators that glue fragments together without breaking their guarantees.

The vocabulary is small. Fragments name conditions: pk(key) for a signature, older(4320) for a relative timelock, after(800000) for an absolute one, sha256(h) for a hash preimage. Combinators name structure: and_v, or_d, thresh and andor cover almost everything anyone builds. A recovery wallet reads as or_d(pk(daily_key),and_v(v:pk(backup_key),older(52560))), which is a policy a human can check and a compiler can turn into script.

Every fragment carries a type and a set of properties, and the type system is what makes the whole thing work. Composition is only allowed where the properties line up, so a policy that would produce a script nobody can satisfy, or one that a third party could mutate in flight, fails to compile rather than failing on chain with your money inside it.

Because the structure is known, three questions get exact answers before you fund anything. How big is the worst case witness, in weight units. Which combinations of keys, preimages and elapsed time can actually spend this. Does the script fit inside the limits, meaning 10,000 bytes by consensus and a tighter 3,600-byte standardness cap on a P2WSH witness script that decides whether nodes will relay your spend at all.

The last piece is satisfaction. Given a script and the material a signer holds, a Miniscript implementation can construct the cheapest valid witness on its own. That is why a wallet can support arbitrary policies without shipping bespoke signing code for each one.

Where you see it

Miniscript is invisible until you want a wallet that does something other than one key, one signature.

Bitcoin Core reached it in stages: version 24.0 parsed Miniscript inside P2WSH descriptors for watching, and version 25.0 added the ability to sign for them, which is the release that made policy wallets usable from the reference client. Ledger's Bitcoin app registers policies through the wallet policy format defined in BIP-388, so a hardware device can display and approve a script it has never seen before.

The clearest consumer product is Liana, a wallet whose entire premise is a Miniscript policy: spend today with your normal key, or after a set number of blocks with a recovery key held by someone else. Inheritance planning and business accounts with an escalating approval path are the same shape.

If you hold a single-signature wallet, none of this touches you. It starts to matter when you want a backup path that does not depend on a company staying in business, and it matters most at the point where a homemade script would otherwise be the only option.

Miniscript vs output descriptor

A descriptor says which keys and which script type; Miniscript says what the script does inside. They are layers, not alternatives, and they nest: wsh(or_d(pk(A),and_v(v:pk(B),older(52560)))) is a descriptor whose inner expression is Miniscript.

Before Miniscript, descriptors could only name a fixed menu of templates such as wpkh, sortedmulti and tr. Anything outside that menu meant hand-written hex and a wallet that could watch the address but never spend from it. Miniscript opens the inner slot to arbitrary policies while keeping the descriptor's checksum, key origins and derivation paths exactly as they were, which is why a Miniscript backup is still a single line of text you can print.