Skip to content

Bitcoin accepted at checkout  |  Ships from Montreal, QC, Canada  |  Expert support since 2016

Bitcoin Miniscript Reference (BIP-379): Fragments, Wrappers and Types

Raw Bitcoin Script is powerful but opaque — you cannot easily tell whether a script is spendable, how big its witness will be, or whether it is malleable. Miniscript (BIP-379) fixes that with a structured, composable language that compiles to Script yet stays machine-analyzable, which is why it now underpins descriptor wallets and multisig coordinators. This reference gives every fragment, the exact Script it produces, the wrapper set, the type system, and the resource limits. It is the spending-policy companion to the output descriptors reference.

Quick answer

Miniscript (BIP-379) is a structured language that compiles to Bitcoin Script while staying machine-analyzable: from a miniscript, software can decide whether a spend is possible, build the satisfying witness, and check size and non-malleability — things raw Script does not let you do. This reference lists all 23 fragments with the exact Script each produces, its semantics and base type, plus the 10 wrappers (a/s/c/t/d/v/j/n/l/u), the B/V/K/W type system with its correctness (z/o/n/d/u/k) and malleability (s/f/e) modifiers, and the resource limits. It is the "spending policy" companion to the output descriptors reference. BIP-379 Status: Draft.

Key facts: the top-level fragment must be type B; and_v chains a V then another fragment; or_c/or_d/or_i encode choices; thresh counts k of n satisfactions. BIP-379 defines NO "m" modifier (non-malleability is derived from s/f/e) and imposes NO key cap on multi_a. Free CSV/JSON under CC BY 4.0; as of 2026-07-26.

Download CSV Download JSON REST API →

The 23 fragments

FragmentCompiles toSemanticsType
00Always false; pushes an exact 0 (the canonical dissatisfaction, no satisfaction exists).B
11Always true; pushes a 1 (satisfied by empty input, cannot be dissatisfied).B
pk_k(key)<key>check(key): pushes the public key; a c: wrapper is still needed to CHECKSIG it.K
pk_h(key)DUP HASH160 <HASH160(key)> EQUALVERIFY check(key): reveals the key matching HASH160(key) then requires its signature.K
pk(key) = c:pk_k(key)<key> CHECKSIGcheck(key): satisfied by a valid signature for key (sugar for c:pk_k(key)).B
pkh(key) = c:pk_h(key)DUP HASH160 <HASH160(key)> EQUALVERIFY CHECKSIGcheck(key): reveal the key hashing to HASH160(key) then satisfy with its signature (sugar for c:pk_h(key)).B
older(n)<n> CHECKSEQUENCEVERIFYnSequence >= n: satisfied when the relative timelock of n is met.B
after(n)<n> CHECKLOCKTIMEVERIFYnLockTime >= n: satisfied when the absolute timelock of n is met.B
sha256(h)SIZE <0x20> EQUALVERIFY SHA256 <h> EQUALlen(x)=32 and SHA256(x)=h: satisfied by revealing the 32-byte preimage x of h.B
hash256(h)SIZE <0x20> EQUALVERIFY HASH256 <h> EQUALlen(x)=32 and HASH256(x)=h: satisfied by revealing the 32-byte preimage x.B
ripemd160(h)SIZE <0x20> EQUALVERIFY RIPEMD160 <h> EQUALlen(x)=32 and RIPEMD160(x)=h: satisfied by revealing the 32-byte preimage x.B
hash160(h)SIZE <0x20> EQUALVERIFY HASH160 <h> EQUALlen(x)=32 and HASH160(x)=h: satisfied by revealing the 32-byte preimage x.B
andor(X,Y,Z)[X] NOTIF [Z] ELSE [Y] ENDIF(X and Y) or Z: if X is satisfied then Y must be, otherwise Z must be.B/K/V (as Y and Z)
and_v(X,Y)[X] [Y]X and Y: X (a V) is verified then Y is satisfied; both required.B/K/V (as Y)
and_b(X,Y)[X] [Y] BOOLANDX and Y: both X (B) and Y (W) satisfied, combined with BOOLAND.B
and_n(X,Y) = andor(X,Y,0)[X] NOTIF 0 ELSE [Y] ENDIFX and Y with else-false: if X holds require Y, else fail (sugar for andor(X,Y,0)).B
or_b(X,Z)[X] [Z] BOOLORX or Z: satisfied if either X (Bd) or Z (Wd) is, combined with BOOLOR.B
or_c(X,Z)[X] NOTIF [Z] ENDIFX or Z (continuation): if X (Bdu) holds continue, else Z (V) must be verified.V
or_d(X,Z)[X] IFDUP NOTIF [Z] ENDIFX or Z: if X (Bdu) holds it stands, otherwise Z (B) must be satisfied.B
or_i(X,Z)IF [X] ELSE [Z] ENDIFX or Z: a witness-supplied selector (1/0) chooses the X or Z branch.B/K/V (as X and Z)
thresh(k,X_1,...,X_n)[X_1] [X_2] ADD ... [X_n] ADD ... <k> EQUALX_1 + ... + X_n = k: satisfied when exactly k of n subexpressions are (X_1 is Bdu, the rest Wdu).B
multi(k,key_1,...,key_n)<k> <key_1> ... <key_n> <n> CHECKMULTISIGk-of-n multisig via CHECKMULTISIG (P2WSH only; 1 <= k <= n <= 20).B
multi_a(k,key_1,...,key_n)<key_1> CHECKSIG <key_2> CHECKSIGADD ... <key_n> CHECKSIGADD <k> NUMEQUALk-of-n multisig via CHECKSIGADD (Tapscript only; 1 <= k <= n, no upper bound stated).B

The 10 wrappers

WrapperScript transformMeaning
a:TOALTSTACK [X] FROMALTSTACKRuns X against the alt stack, converting a B into a W (reads its input one below the top of stack).
s:SWAP [X]SWAPs the top two elements before running X, converting a Bo into a W.
c:[X] CHECKSIGAppends CHECKSIG, converting a K (key) expression into a B by requiring a signature.
t:[X] 1t:X = and_v(X,1): appends a 1 after X, turning a V into a B.
d:DUP IF [X] ENDIFMakes a Vz expression dissatisfiable (a B): a witness element selects whether X runs.
v:[X] VERIFY (or the VERIFY form of X's last opcode)Appends VERIFY, converting a B into a V (continues without pushing, cannot be dissatisfied).
j:SIZE 0NOTEQUAL IF [X] ENDIFMakes a Bn expression dissatisfiable by supplying an empty (zero-size) input that skips X.
n:[X] 0NOTEQUALAppends 0NOTEQUAL, normalizing X's nonzero output to an exact 1 (adds the u/unit property).
l:IF 0 ELSE [X] ENDIFl:X = or_i(0,X): X sits on the ELSE branch (selected with a 0 witness).
u:IF [X] ELSE 0 ENDIFu:X = or_i(X,0): X sits on the IF branch (selected with a 1 witness).

Type system

Basic types

B Base — Takes inputs from the top of the stack; on satisfaction pushes a nonzero value, on dissatisfaction pushes an exact 0. Required for the top-level expression.
V Verify — Takes inputs from the top of the stack; on satisfaction continues without pushing anything and cannot be dissatisfied (it aborts instead).
K Key — Takes inputs from the top of the stack but always pushes a public key, for which a signature is still required (convert to B with c:).
W Wrapped — Takes inputs one below the top of the stack; every W is either s:B (SWAP) or a:B (TOALTSTACK ... FROMALTSTACK).

Correctness modifiers

z Zero-arg: always consumes exactly 0 stack elements.
o One-arg: always consumes exactly 1 stack element.
n Nonzero: always consumes at least 1 element; no satisfaction needs the top input to be zero.
d Dissatisfiable: a dissatisfaction can always be constructed (no signature, preimage or timelock required for it).
u Unit: when satisfied, puts an exact 1 on the stack (not just any nonzero value).
k No timelock mixing: does not mix a heightlock and a timelock of the same type.

Malleability modifiers

s Signed: satisfying always requires a signature.
f Forced: dissatisfying always requires a signature.
e Expressive: a unique unconditional dissatisfaction exists, and all conditional dissatisfactions require a signature.

Resource limits

  • P2WSH scripts larger than 3600 bytes are invalid by standardness; Tapscript is only implicitly bounded by the ~1,000,000 vbyte block size.
  • P2WSH: satisfactions where non-push opcodes plus the keys in all executed CHECKMULTISIG exceed 201 are invalid by consensus.
  • Both contexts: satisfactions that make the stack exceed 1000 elements before or during execution are invalid.
  • P2WSH: satisfactions whose witness has over 100 stack elements (excluding the script) are invalid by standardness.
  • multi(): 1 <= k <= n <= 20 (CHECKMULTISIG key cap). multi_a(): 1 <= k <= n (BIP-379 states no explicit upper key bound).

Source: the canonical bip-0379.md from bitcoin/bips (Status: Draft, fetched 2026-07-26). [X] denotes the compiled Script of subexpression X. The "spending policy" companion to the output descriptors reference (BIP-380..392); pairs with the PSBT reference too.