témoin séparé : Algorithme de signature SegWit et son amélioration
Pour être clair, cela parle de la façon dont le message qui est signé est calculé. Il n’est pas lié aux hachages de transaction ou de bloc et à l’algorithme de signature lui-même, à la manière dont Bitcoin détermine quelles données sont réellement couvertes par la signature et comment elles sont sérialisées. Ces données sont hachées afin d’être utilisées dans l’algorithme de signature. C’est ce qu’on appelle l’algorithme sighash. Ce sighash est généré par le signataire et les vérificateurs, de sorte que les signataires et les vérificateurs doivent pouvoir générer exactement le même sighash, sinon les signatures seront invalides.
Avant segwit, l’algorithme sighash prendrait l’intégralité de la transaction de dépense, supprimerait tous les scriptSigs de chaque entrée, puis remplirait l’entrée dans laquelle la signature ira avec le scriptPubKey ou le rachatScript (pour P2SH) et signerait cela. Cela finit par être O(n^2) car à mesure que le nombre d’entrées augmente, la quantité de données hachées par pour chaque entrée augmente également. Ainsi, la quantité totale de hachages de données augmente de manière quadratique. La quantité de données hachées peut avoir un effet important sur la rapidité avec laquelle les transactions sont validées.
Par exemple, une transaction avec 2 entrées nécessitera le calcul de 2 sighashs, dans lesquels 2 entrées de données devront être hachées dans chaque sighash. La quantité totale de données hachées est de 4 entrées de données. Si une transaction a 4 entrées, il y aura 3 sighashs calculés, avec 3 entrées de données dans chaque sighash, pour un total de 9 entrées hachées.
Segwit résout ce problème en définissant un nouvel algorithme sighash utilisé lors de la dépense d’entrées segwit uniquement. Au lieu de cela, il précalcule le hachage des entrées qui est ensuite utilisé dans les soupirs pour chaque entrée. Comme cela n’est fait qu’une seule fois pour l’ensemble de la transaction, la quantité de données hachées n’augmente que de manière linéaire – chaque entrée supplémentaire est un peu plus de données à hacher dans le hachage précalculé, et un soupir supplémentaire à calculer.
Comme Segwit définit un nouvel algorithme sighash pour les entrées segwit uniquement, cet algorithme peut également inclure de nouvelles informations qui n’étaient pas couvertes auparavant par le sighash. Cela inclut donc également le montant de l’entrée dépensée, pas seulement le scriptPubKey. Cela permet aux signataires hors ligne d’être sûrs que certains types d’attaques leur mentent sur la valeur d’une entrée.
Les signataires hors ligne ont besoin de connaître la valeur d’une entrée afin d’effectuer des vérifications sur les montants et de s’assurer que la transaction ne fait rien d’inattendu avec les montants. Si le signataire hors ligne vient d’être informé du montant par le portefeuille en ligne, il ne peut pas être sûr que le montant est réellement correct. Ainsi, pour les entrées non-segwit, ils demandent la totalité de la transaction précédente. De cette façon, ils peuvent vérifier le montant dans la sortie elle-même et s’assurer que l’identifiant de transaction correspond.
Avec Segwit, le montant est directement inclus dans le sighash lui-même. Cela signifie que si le signataire hors ligne recevait le mauvais montant, son sighash contiendrait le mauvais montant. Lorsqu’un vérificateur vérifie la transaction, il calcule un sighash différent contenant le montant correct, ce qui entraîne l’échec de la signature, et donc l’échec de la transaction. Étant donné que les signataires hors ligne savent qu’un montant erroné entraînera simplement une transaction invalide, ils n’ont pas besoin de l’intégralité de la transaction précédente pour être sûrs que le montant qui leur est donné est correct.
/a/113785/48884 a une réponse plus détaillée sur les attaques qui incluent les montants atténués, et les attaques qui sont encore possibles.
