Miniscript représente de façon structurée une partie de Bitcoin Script, le langage qui fixe les conditions de dépense des fonds. Il permet de combiner signatures, délais et révélation de certains secrets sous une forme que le logiciel peut analyser et satisfaire. Ce n’est ni un portefeuille autonome ni un changement des règles de Bitcoin : c’est le script obtenu qui protège les fonds.
Anna souhaite utiliser ses fonds normalement avec sa propre clé. Une signature numérique prouve l’autorisation d’un paiement à l’aide d’une clé privée, une valeur numérique secrète, sans révéler cette clé. Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. Anna veut aussi prévoir une possibilité pour Peter, qui pourra les dépenser avec sa clé après 144 blocs depuis la confirmation de cette sortie. Cette intention s’appelle une spending policy, autrement dit une politique de dépense. Miniscript aide à la traduire dans une forme précise exploitable par le portefeuille. Peter a toujours besoin de sa clé : attendre ne la remplace pas. C’est un exemple simple de voies d’accès alternatives, pas un transfert automatique ni un moyen de détecter qu’Anna a perdu sa clé. [1] [2] [10]
Une règle formulée en mots n’est pas encore le programme que le réseau vérifie. Un compilateur peut choisir un Miniscript précis pour cette intention, puis le convertir en Bitcoin Script. Un Output Descriptor décrit ensuite les scripts avec les clés et leurs éventuels chemins de dérivation ; il peut aussi comporter une somme de contrôle contre les erreurs de copie. Lors de la dépense, le réseau vérifie le script réel et les données fournies, pas la phrase initiale. Miniscript n’ajoute aucune instruction et ne modifie pas le consensus, les règles communes de validité. Il ne représente pas tous les Bitcoin Scripts imaginables. [1] [3] [6]
Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Dans l’exemple de Peter, les 144 blocs se comptent depuis la confirmation de la sortie, un montant précis assorti de conditions de dépense. Ce n’est ni une journée exacte ni le temps écoulé depuis la création du portefeuille. Miniscript exprime le délai relatif avec older(n), qui s’appuie sur CSV et le champ nSequence de l’entrée qui dépense cette sortie ; BIP 68 définit le sens de ce champ pour vérifier l’ancienneté. À l’inverse, after(n) utilise CLTV et le nLockTime absolu, une hauteur ou une limite temporelle fixe. Le portefeuille doit régler correctement les champs de la transaction et respecter les autres conditions. Il ne faut pas combiner de façon incompatible les verrous en hauteur et en temps ; attendre ne déclenche aucun envoi. [1] [7] [8] [9] [11]
Présenter la description des règles ne suffit pas. Le portefeuille doit fournir les données qui satisfont une voie autorisée : par exemple des signatures, ou un secret dont le hash correspond à celui demandé, appelé preimage. Un hash est une empreinte numérique des données ; on vérifie ici que le secret fourni produit bien l’empreinte demandée. Cet accomplissement est une satisfaction ; les données nécessaires font partie du witness de la transaction. Pour combiner des branches, il peut falloir rendre une sous-condition fausse de la manière prévue afin d’emprunter une autre voie. C’est une dissatisfaction, pas l’invalidité du paiement entier. Le logiciel peut assembler le bon chemin, mais ne peut inventer une clé privée manquante ni un secret inconnu. [1] [12]
PSBT est un format qui transmet une transaction préparée et des informations complémentaires entre le portefeuille et les appareils qui signent. La prise en charge de PSBT ne suffit pas : le logiciel et la Hardware Wallet doivent comprendre le descriptor et ses conditions. Bitcoin Core a ajouté l’observation de Miniscript dans P2WSH en version 24, la signature en version 25, puis son utilisation dans les descriptors Taproot en version 26. Observer les fonds ne signifie donc pas pouvoir les dépenser. À la configuration, vérifiez sur un écran de confiance les clés, les signatures requises, les délais et toutes les voies alternatives, selon les capacités réelles de l’appareil. [3] [4] [5]
Une Seed Phrase restaure les clés, mais peut ne pas indiquer comment elles ont été combinées avec d’autres clés et le script d’une condition personnalisée. Cette sauvegarde est une suite de mots à partir de laquelle le portefeuille peut dériver ses clés. Conservez le descriptor exact avec sa somme de contrôle, la correspondance des clés, les chemins de dérivation et la distinction entre adresses de réception et de monnaie rendue. Notez séparément le réseau, la plage d’adresses et le point de départ de la recherche dans l’historique. Un descriptor public n’est pas une clé privée, mais il peut révéler l’historique des paiements. Avant d’utiliser ce dispositif, testez la restauration d’un portefeuille d’observation et chacune des voies de dépense prévues dans Regtest ou Signet. [5] [6]
pk(), older(), after() et sha256() représentent des signatures, des délais ou l’exigence d’un secret. and_v(), or_d() et thresh() combinent les conditions. Des enveloppes comme v: adaptent l’évaluation tout en conservant le sens de la sous-expression. Les types B, V, K et W encadrent la façon dont les éléments échangent des données sur la pile, l’espace de travail du script ; tous ne sont pas compatibles. Le contrôle des types peut donc repérer un assemblage incohérent. Il ne décide pas à qui Anna devrait faire confiance ni si son accès de secours est judicieux. [1] [2]
La structure permet d’analyser la taille du script et du witness, le nombre d’opérations, de vérifications de signatures et d’éléments de pile avant la dépense. Cela aide à estimer le coût des différentes voies et à détecter un dépassement des limites autorisées. Le contexte compte : P2WSH inscrit les conditions dans SegWit, tandis que Tapscript désigne les scripts employés dans Taproot. Leurs limites diffèrent sur certains points. Aux règles de consensus s’ajoutent les règles habituelles de relais des transactions. L’analyse ne certifie donc pas que tout portefeuille saura exécuter le dispositif. [1]
La clé publique sert à vérifier les signatures et n’a pas besoin de rester secrète. L’analyse de malleability examine si un tiers peut transformer une satisfaction valide en une autre qui l’est aussi. Ses garanties reposent sur des hypothèses précises : l’attaquant ne possède aucune clé privée des participants, ne connaît pas davantage de preimages que l’utilisateur honnête et ne voit qu’une satisfaction. On suppose aussi l’absence de clés publiques répétées et l’application des règles habituelles d’acceptation ; un mineur peut avoir des possibilités dont un simple nœud de relais ne dispose pas. Ce n’est pas une protection contre tout participant malveillant, une sauvegarde perdue ou une mauvaise conception de la garde. Ces questions demandent une analyse distincte. [1]
Un compilateur peut exprimer les mêmes règles de plusieurs façons, avec des tailles différentes de script et de witness. Il choisit selon un modèle de coût. Une annotation telle que 9@ sur une branche du langage de politiques indique une probabilité relative d’utilisation ; ce n’est ni un nombre de signatures ni une autorisation du réseau. Une autre compilation peut produire un autre script, donc d’autres adresses. Pour restaurer le portefeuille, il ne suffit pas de reformuler les règles et de les recompiler. Il faut la représentation exacte sauvegardée, des adresses dérivées vérifiées et une voie de signature testée. [2] [5]
Pour une vision complète, lisez aussi Bitcoin Script, Output Descriptor, Multisig, Andrew Poelstra, Timelock, Bitcoin. Cette entrée est également citée par Output Descriptor, Dead Man’s Switch, Andrew Poelstra, Simplicity.