Start with spending intent
A policy describes who may spend and under what conditions: for example, two operational keys now, or one recovery key after a delay. Turning that intent directly into hand-written Script can make correctness, fee estimation and recovery analysis difficult.
Miniscript represents supported conditions through composable fragments with defined properties. Software can compile a policy into Script while preserving the distinction between business intent, key ownership and on-chain enforcement.
Types prevent invalid compositions
Miniscript fragments carry type and property information describing how they behave on the Script stack and what kind of satisfaction they require. Composition rules reject many constructions that would be invalid, malleable or unsafe before funds are committed.
This is static analysis, not a replacement for consensus validation. The final witness and Script still have to satisfy the ordinary rules enforced by every full node.
Satisfactions can be analysed
For a given set of keys, hashes and timelock conditions, tooling can determine possible satisfactions and dissatisfactions, estimate witness sizes and identify whether a branch is available. That helps wallets select a practical route and estimate its fee.
Analysis also exposes trade-offs. A recovery path may be secure but expensive; an immediate path may require devices that are not geographically independent; one branch may reveal more policy information than another when used.
Descriptors preserve the wallet structure
Output descriptors can carry script construction, key origins and derivation information. A Miniscript expression inside a compatible descriptor can therefore describe both the spending policy and how a wallet derives the keys used by it.
Backups must preserve the descriptor or equivalent policy, key fingerprints, derivation information and any timelock assumptions. A seed by itself may not tell recovery software which multisignature or delayed policy to reconstruct.
Scope and support must be explicit
BIP379 specifies Miniscript for P2WSH. Other descriptor and Taproot policy tooling may use related ideas, but do not assume every wallet supports every fragment, script context or import/export format.
Check maintained wallet documentation, round-trip the descriptor through every required signer, and exercise each recovery path with valueless test funds. A policy that exists on paper but cannot be recovered by the available tools is not operationally complete.
Visual recap
From human policy to a tested spend
Structured policy helps software analyse routes before the resulting Script is funded.
Write spending intent
Choose supported fragments
Type-check policy
Compile descriptor
Test each satisfaction
Back up policy and keys
Key vocabulary
Terms worth knowing
- Policy
- A human-oriented expression of acceptable spending conditions before compilation into a script form.
- Satisfaction
- Witness data that makes one available spending path evaluate successfully.
- Descriptor
- A checksummed expression describing how output scripts and keys are constructed.
Worked example
Operational keys plus delayed recovery
A treasury wants two of three operational keys for normal spending and one separate recovery route after a long delay.
- 1State the policy in plain language
- 2Map keys and delay to supported fragments
- 3Analyse every satisfaction path
- 4Estimate witness sizes
- 5Export and test the complete descriptor backup
The useful result is not merely compilable Script. It is a policy whose normal and recovery paths are understood, affordable and recoverable with actual tools.
Common misconceptions
What learners often get wrong
Misconception
Miniscript is a new Bitcoin smart-contract language enforced by new consensus rules.
More accurate
It structures a supported subset of existing Script conditions for analysis and construction.
Misconception
Backing up the seeds always reconstructs the policy.
More accurate
Recovery may also require descriptors, derivation information, key origins and timelock details.
Try it yourself
Review a fictional recovery policy before funding it.
- List every spending path
- Identify keys and delays
- Estimate each witness
- Check wallet and signer support
- Demonstrate recovery from the documented backup
Use fictional values and public information only. Never enter seed words, private keys or other wallet secrets into a learning exercise.
Key takeaways
- Miniscript structures supported spending conditions without changing consensus.
- Fragment types make many invalid compositions detectable before funding.
- Tooling can analyse satisfaction paths and estimate witness costs.
- Descriptors help preserve both policy and key derivation context.
- BIP379's specified scope and each wallet's actual support must be checked.
Lesson recap
Check what you learned
Reveal each model answer, then honestly mark whether you understood it or need another review.
1 of 3
Recall
Does using Miniscript make a spending condition valid under new consensus rules?
References
