Dépense par chemin de script

Les dépenses par chemin de script sont la voie de secours pour sortir d'une sortie Taproot, utilisée lorsque la signature coopérative que tout le monde espérait n'est jamais arrivée. La preuve voyage dans un bloc de contrôle de 33 octets plus 32 de plus pour chaque niveau de l'arbre, et le BIP-341 plafonne cet arbre à 128 niveaux. Emprunter cette voie publie la branche utilisée, si bien que la seule condition sur laquelle vous comptiez réellement cesse d'être privée.

Comment cela fonctionne

Un nœud qui valide une dépense par chemin de script lit la pile de témoins à l'envers, car le dernier élément fait l'essentiel du travail.

Ce dernier élément est le bloc de contrôle, et sa longueur est vérifiée avant toute autre chose. Elle doit être exactement de 33 + 32m octets pour un nombre entier m compris entre 0 et 128, et toute autre longueur échoue d'emblée. Le BIP-341 fixe le plafond à 128 parce qu'un arbre rangé de façon optimale ne descend plus profondément que pour une feuille ayant moins d'une chance de 1 sur 2^128 d'être utilisée.

Le premier octet porte deux choses sans rapport. Masquez-le avec 0xfe et vous obtenez la version de feuille, 0xc0 pour les règles tapscript ; le bit masqué est la parité de la coordonnée Y de la clé de sortie, présente pour que la dépense puisse être vérifiée par lot. Les 32 octets suivants sont la clé publique interne, celle qui aurait signé une dépense coopérative ; tout ce qui suit est le chemin de merkle, 32 octets par niveau.

Le nœud reconstruit ensuite l'engagement. Il hache la version de feuille avec le script révélé pour obtenir un hachage de feuille taproot et intègre chaque élément du chemin l'un après l'autre. La direction n'est jamais transmise : les deux valeurs de 32 octets à chaque étape sont triées par ordre lexicographique avant le hachage, si bien que la comparaison décide de l'ordre et aucun bit de direction n'est envoyé. La racine et la clé interne produisent un ajustement, et la clé ajustée doit être égale aux 32 octets présents dans l'adresse, bit de parité inclus, avant que le script soit autorisé à s'exécuter.

Un octet peut tout changer avant lui. Si le témoin contient au moins deux éléments et que le dernier commence par 0x50, cet élément est retiré en tant qu'annexe avant que la validation commence. Le BIP-341 ne lui définit aucune signification et avertit que sa présence peut entraîner une "PERMANENT FUND LOSS".

Où le voit-on

Une dépense par chemin de script se reconnaît sur un explorateur de blocs à une entrée Taproot dont le témoin, annexe mise à part, contient plus d'un élément.

L'exemple détaillé du BIP-341 lui-même est un arbre de cinq scripts, de A à E. Dépenser avec le script D publie D, plus un bloc de contrôle contenant la clé interne et trois hachages : C, E, et le hachage combiné de A et B. Ce bloc de contrôle fait 129 octets pour un contrat à cinq conditions, et les quatre autres scripts ne sont jamais publiés.

La preuve révèle aussi quelque chose. La section sur la sécurité du BIP-341 note que la profondeur de la feuille révélée laisse fuiter la profondeur minimale de l'arbre, ce qui "suggests specific wallet software that created the output and helps clustering". La défense que suggère le BIP-341 est de s'écarter de l'arbre que les probabilités des feuilles rendraient sinon optimal.

La même section est directe sur la réutilisation des clés. Les clés doivent être neuves pour chaque feuille, pas seulement celle que vous avez dépensée, car une branche répétée réapparaît sous forme de hachage répété dans une preuve ultérieure, et des feuilles qui partagent des clés rendent un script non révélé peu coûteux à attaquer par force brute.

Dépense par chemin de script vs Tapscript

Une dépense par chemin de script est la voie ; tapscript est la langue parlée à son extrémité. Le BIP-341 définit tout jusqu'au moment où l'exécution commence : le bloc de contrôle, l'intégration merkle triée, la vérification de l'ajustement, le bit de parité. Ce qui s'exécute ensuite est décidé par la version de feuille.

Seul 0xc0 signifie actuellement tapscript. Une feuille portant toute autre version n'est pas une erreur, car le BIP-341 exige que l'exécution réussisse pour des versions de feuille inconnues. C'est le crochet qui permet à un futur soft fork de définir un autre langage de script dans le même format d'adresse bc1p, ce qui fait de la dépense par chemin de script la moitié durable de la paire.