Branche de Merkle Taproot

Chaque hachage de la branche est un frère du taptree, dans l'ordre depuis votre feuille jusqu'à la racine. Le BIP-341 plafonne la branche à 128 hachages, 4 096 octets, et son arbre trié fait que la branche ne porte aucun bit de direction gauche ou droite. La longueur de votre branche est publique, donc une feuille plus profonde révèle la profondeur minimale de votre arbre et donne une indication sur le portefeuille qui a construit la sortie.

Comment cela fonctionne

Une branche de Merkle Taproot circule dans le bloc de contrôle, le dernier élément de la pile de témoins d'une dépense par chemin de script une fois toute annexe retirée.

Le bloc de contrôle a une forme fixe. L'octet zéro porte la version de feuille plus la parité de la coordonnée Y de la clé de sortie. Les octets 1 à 32 contiennent la clé publique interne. Tout ce qui suit est la branche : m hachages consécutifs de 32 octets, donc le bloc de contrôle mesure 33 + 32m octets, et m doit être un entier de 0 à 128. Toute autre longueur fait échouer la dépense avant même qu'un seul opcode s'exécute.

La vérification part du bas. Un nœud hache le script révélé sous l'étiquette TapLeaf, puis intègre chaque hachage de branche à son tour sous l'étiquette TapBranch, en comparant à chaque étape les deux valeurs de 32 octets par ordre lexicographique et en hachant d'abord la plus petite. Ce qui en ressort est la racine du taptree, qui est hachée avec la clé interne sous l'étiquette TapTweak, ajoutée au point interne, puis comparée aux 32 octets de la sortie dépensée.

Cette comparaison est toute l'astuce. Comme le BIP-341 trie les deux enfants avant de les hacher, une branche ne dit jamais de quel côté se trouvait un frère : le vérificateur le détermine. La justification est directe sur ce point, indiquant que la conception ne se soucie pas de la position de scripts précis dans l'arbre, seulement qu'ils y sont réellement engagés.

Le plafond de 128 est une limite de sécurité plutôt qu'un plafond arbitraire. La profondeur dans un arbre compacté de façon optimale avoisine le logarithme de base deux de l'inverse de la probabilité d'une feuille, donc une profondeur de 129 signifierait un script dont la probabilité d'usage est inférieure à 1 sur 2^128, ce que le BIP-341 dit pouvoir probablement être supprimé à la place. À l'autre extrémité, un taptree à une seule feuille a un m de 0, une branche vide, et un hachage de feuille qui est déjà la racine.

Où le voir

Les branches de Merkle Taproot apparaissent dans toute transaction qui dépense une sortie bc1p en révélant un script au lieu de signer avec la clé.

Le BIP-341 traite un exemple sur un arbre de cinq feuilles. A, B, C et E sont des hachages TapLeaf et AB est un hachage TapBranch des deux premiers. Pour dépenser avec le script D, le bloc de contrôle porte C, puis E, puis AB : trois hachages, 96 octets de branche, un bloc de contrôle de 129 octets. E est haché avant CD lorsque ces deux se combinent, car E se trie plus bas.

Le coût pour la vie privée est ce dont il faut tenir compte. La section sécurité du BIP-341 dit que la profondeur d'un script révèle la profondeur minimale de l'arbre, ce qui donne une indication sur le logiciel de portefeuille qui a construit la sortie et aide l'analyse de chaîne à regrouper des adresses, et il recommande de s'écarter de l'arbre que les probabilités des feuilles donneraient. La réutilisation de feuille est l'autre piège : dépenser une autre sortie peut republier les mêmes hachages de branche, donc deux dépenses partageant un frère de 32 octets paraissent liées.

Branche de Merkle Taproot vs bloc de Merkle

Une branche de Merkle Taproot prouve qu'un script appartient à une adresse ; un bloc de Merkle prouve qu'une transaction appartient à un bloc. La branche du taptree est critique pour le consensus, recalculée par chaque nœud complet qui valide la dépense, et elle est indépendante de la position car le tri a supprimé le besoin de dire gauche ou droite. Une preuve sur l'arbre des transactions d'un bloc ne peut pas emprunter cette astuce, puisque l'ordre des transactions sous la racine de Merkle d'un bloc est fixe et significatif, elle doit donc porter le parcours ainsi que les hachages.