Référence Miniscript de Bitcoin (BIP-379) : fragments, enveloppes et types

Le Bitcoin Script brut est puissant mais opaque — difficile de savoir si un script est dépensable, quelle taille aura son témoin, ou s’il est malléable. Miniscript (BIP-379) corrige cela avec un langage structuré et composable qui se compile en Script tout en restant analysable par une machine, ce qui en fait aujourd’hui le socle des portefeuilles à descripteurs et des coordinateurs multisig. Cette référence donne chaque fragment, le Script exact qu’il produit, l’ensemble des enveloppes, le système de types et les limites de ressources. C’est le pendant « politique de dépense » de la référence des descripteurs. Les descriptions sont conservées en anglais.

Réponse rapide

Miniscript (BIP-379) est un langage structuré qui se compile en Bitcoin Script tout en restant analysable par une machine : à partir d'un miniscript, un logiciel peut décider si une dépense est possible, calculer le témoin de satisfaction, et vérifier la taille et la non-malléabilité — ce que le Script brut ne permet pas. Cette référence liste les 23 fragments avec le Script exact que chacun produit, sa sémantique et son type de base, plus les 10 enveloppes (a/s/c/t/d/v/j/n/l/u), le système de types B/V/K/W avec ses modificateurs de correction (z/o/n/d/u/k) et de malléabilité (s/f/e), et les limites de ressources. C'est le pendant « politique de dépense » de la référence des descripteurs. BIP-379 : statut Brouillon (Draft). Les descriptions sont conservées en anglais.

À retenir : le fragment de premier niveau doit être de type B; and_v enchaîne un V puis un autre fragment; or_c/or_d/or_i encodent les choix; thresh compte k satisfactions sur n. BIP-379 ne définit PAS de modificateur « m » (la non-malléabilité est dérivée de s/f/e) et n'impose PAS de plafond de clés sur multi_a. CSV/JSON gratuits sous CC BY 4.0.

Télécharger le CSV Télécharger le JSON API REST →

Les 23 fragments

Fragment	Script produit	Sémantique	Type
`0`	`0`	Always false; pushes an exact 0 (the canonical dissatisfaction, no satisfaction exists).	B
`1`	`1`	Always 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> CHECKSIG`	check(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 CHECKSIG`	check(key): reveal the key hashing to HASH160(key) then satisfy with its signature (sugar for c:pk_h(key)).	B
`older(n)`	`<n> CHECKSEQUENCEVERIFY`	nSequence >= n: satisfied when the relative timelock of n is met.	B
`after(n)`	`<n> CHECKLOCKTIMEVERIFY`	nLockTime >= n: satisfied when the absolute timelock of n is met.	B
`sha256(h)`	`SIZE <0x20> EQUALVERIFY SHA256 <h> EQUAL`	len(x)=32 and SHA256(x)=h: satisfied by revealing the 32-byte preimage x of h.	B
`hash256(h)`	`SIZE <0x20> EQUALVERIFY HASH256 <h> EQUAL`	len(x)=32 and HASH256(x)=h: satisfied by revealing the 32-byte preimage x.	B
`ripemd160(h)`	`SIZE <0x20> EQUALVERIFY RIPEMD160 <h> EQUAL`	len(x)=32 and RIPEMD160(x)=h: satisfied by revealing the 32-byte preimage x.	B
`hash160(h)`	`SIZE <0x20> EQUALVERIFY HASH160 <h> EQUAL`	len(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] BOOLAND`	X 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] ENDIF`	X 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] BOOLOR`	X or Z: satisfied if either X (Bd) or Z (Wd) is, combined with BOOLOR.	B
`or_c(X,Z)`	`[X] NOTIF [Z] ENDIF`	X or Z (continuation): if X (Bdu) holds continue, else Z (V) must be verified.	V
`or_d(X,Z)`	`[X] IFDUP NOTIF [Z] ENDIF`	X or Z: if X (Bdu) holds it stands, otherwise Z (B) must be satisfied.	B
`or_i(X,Z)`	`IF [X] ELSE [Z] ENDIF`	X 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> EQUAL`	X_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> CHECKMULTISIG`	k-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> NUMEQUAL`	k-of-n multisig via CHECKSIGADD (Tapscript only; 1 <= k <= n, no upper bound stated).	B

Les 10 enveloppes (wrappers)

Enveloppe	Transforme en	Rôle
`a:`	`TOALTSTACK [X] FROMALTSTACK`	Runs 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] CHECKSIG`	Appends CHECKSIG, converting a K (key) expression into a B by requiring a signature.
`t:`	`[X] 1`	t:X = and_v(X,1): appends a 1 after X, turning a V into a B.
`d:`	`DUP IF [X] ENDIF`	Makes 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] ENDIF`	Makes a Bn expression dissatisfiable by supplying an empty (zero-size) input that skips X.
`n:`	`[X] 0NOTEQUAL`	Appends 0NOTEQUAL, normalizing X's nonzero output to an exact 1 (adds the u/unit property).
`l:`	`IF 0 ELSE [X] ENDIF`	l:X = or_i(0,X): X sits on the ELSE branch (selected with a 0 witness).
`u:`	`IF [X] ELSE 0 ENDIF`	u:X = or_i(X,0): X sits on the IF branch (selected with a 1 witness).

Système de types

Types de base

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).

Modificateurs de correction

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.

Modificateurs de malléabilité

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.

Limites de ressources

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 : le bip-0379.md canonique de bitcoin/bips (statut Brouillon, consulté le 2026-07-26). [X] désigne le Script compilé du sous-fragment X. Compagnon « politique de dépense » de la référence des descripteurs (BIP-380..392); se combine aussi avec la référence PSBT.

Produits, réparations et guides connexes

Dernière révision: 26 juillet 2026.