Hash de signature

Aucune signature ne couvre la transaction telle qu'elle apparaît sur le réseau. Chaque entrée reçoit son propre condensat, construit par une procédure qui a été réécrite deux fois : la procédure d'origine de 2009, le BIP143 pour les entrées segwit, et le BIP341 pour Taproot. Ce que le condensat laisse de côté, un attaquant est libre de le modifier.

Comment cela fonctionne

Construire un hash de signature revient à construire une copie modifiée de la transaction et à hacher cette copie, et non à hacher la transaction que vous êtes sur le point de diffuser.

La procédure d'origine fonctionne ainsi. Prenez la transaction, videz le script de déverrouillage de chaque entrée, insérez le script dépensé dans la seule entrée que vous signez, puis conservez, laissez vides ou supprimez les sorties selon le flag. Ajoutez le flag sous forme de nombre de quatre octets, appliquez deux fois SHA-256 à l'ensemble, et signez les 32 octets obtenus.

Cette conception avait un coût que personne n'a remarqué avant que les transactions grossissent. Comme chaque entrée reconstruit et rehache toute la transaction, le travail augmente avec le carré du nombre d'entrées. Le BIP143 chiffre cela : vérifier un bloc ordinaire de 1 Mo prend environ 2 secondes, tandis qu'une seule transaction fabriquée de 1 Mo portant 5 569 opérations de signature peut prendre 25 secondes. Une transaction qui bloque ainsi tous les nœuds du réseau pendant ce temps est un déni de service en attente d'industrialisation.

Le BIP143 a réécrit la procédure pour les entrées segwit version 0 et a corrigé deux problèmes à la fois. Trois sous-condensats couvrant les outpoints, les numéros de séquence et les sorties sont calculés une fois et réutilisés pour chaque entrée, ce qui rend le coût linéaire. Plus important pour qui détient des bitcoins, le condensat engage désormais la valeur de l'entrée signée. Auparavant, un appareil de signature devait se voir indiquer la valeur d'une entrée sans aucun moyen de la vérifier, si bien qu'un programme malveillant pouvait sous-évaluer les entrées et amener un portefeuille matériel à approuver des frais énormes.

Le BIP341 l'a réécrite une troisième fois pour Taproot. Le condensat Taproot est un hash tagué, préfixé d'une chaîne de domaine afin qu'il ne puisse jamais être confondu avec le condensat d'un autre protocole, et il engage les montants et les scripts de verrouillage de chaque entrée dépensée, et pas seulement de l'entrée signée. Il introduit aussi une valeur de flag par défaut de zéro, qui couvre tout ce que couvre la règle standard mais n'est jamais inscrite dans la signature.

Où le voit-on

Vous rencontrez le hash de signature indirectement, comme la raison du comportement de votre portefeuille matériel.

Signer une entrée legacy oblige à fournir à l'appareil la transaction précédente complète, car c'est le seul moyen pour lui d'établir lui-même la valeur de l'entrée. Sparrow et Electrum transmettent ces transactions à un Trezor ou à un Ledger avant la signature, et sur un portefeuille rempli de bitcoins anciens, c'est cette étape qui explique qu'une dépense prenne nettement plus de temps que prévu. Une entrée segwit n'a besoin que du montant, que le PSBT porte déjà.

Il apparaît directement comme le dernier octet d'une signature legacy ou segwit dans un explorateur de blocs. Une signature se terminant par 01 a été produite sous la règle qui couvre tout. Toute autre valeur mérite d'être comprise avant que vous ne vous fiiez à la transaction.

Hash de signature vs SIGHASH_ALL

Le hash de signature est le condensat ; SIGHASH_ALL est l'une des règles pour le construire. Toute signature a un hash de signature, y compris les signatures Taproot qui ne portent aucun octet de flag. Ce qui varie, ce sont les parties de la transaction qui sont entrées dans le condensat, et le flag n'est que l'étiquette de ce choix. Dire qu'une transaction « utilise SIGHASH_ALL » décrit une politique ; dire qu'elle a un hash de signature décrit ce que toute signature bitcoin de l'histoire a eu.