SegWit

Le changement était structurel, pas cosmétique. Les signatures sont allées dans une section témoin que les anciens nœuds ne téléchargent jamais, ce qui a permis de livrer une augmentation de capacité sous forme de soft fork, et les octets du témoin coûtent une unité de poids chacun au lieu de quatre. Dépenser depuis une adresse bc1q coûte donc environ la moitié de ce que coûte une entrée héritée.

Comment cela fonctionne

Segregated Witness divise une transaction en deux parties et les hache séparément.

La partie de base contient la version, les entrées, les sorties et le locktime. La partie témoin contient, pour chaque entrée, la pile d'éléments qui l'autorise, généralement une signature et une clé publique. L'identifiant de transaction est calculé sur la partie de base seule, donc rien dans le témoin ne peut le modifier. Un second identifiant, le wtxid, couvre les deux, et la racine de merkle de tous les wtxid d'un bloc est inscrite dans la transaction coinbase pour que les données du témoin ne puissent pas non plus être altérées.

La capacité découle d'un changement de comptabilité plutôt que d'un changement de la limite. Chaque octet hors du témoin coûte quatre unités de poids, chaque octet à l'intérieur coûte une, et un bloc peut contenir 4 000 000 unités de poids. Les données hors témoin ne peuvent donc toujours pas dépasser 1 000 000 octets, exactement comme avant, tandis que les signatures voyagent dans le budget restant. Un nœud antérieur à 2017 mesurant à l'ancienne voit un bloc légal et n'élève aucune objection, ce qui explique précisément pourquoi la mise à niveau n'a pas eu besoin d'un hard fork.

Le BIP-143 a réécrit la façon dont une entrée témoin est signée, et le gain pratique est plus important qu'il n'y paraît. L'ancien algorithme de hachage de signature rehachait des parties de la transaction une fois par entrée, donc signer une transaction à nombreuses entrées croissait de façon quadratique. Le nouveau réutilise des hachages précalculés et, surtout, s'engage sur le montant dépensé. Avant cela, un portefeuille matériel pouvait se voir mentir sur la valeur d'une entrée et être amené à autoriser des frais énormes.

SegWit a aussi numéroté ses types de sortie. La version témoin 0 couvre P2WPKH et P2WSH ; la version témoin 1 a été laissée vide et remplie plus tard par Taproot. De nouveaux types de sortie peuvent désormais être ajoutés sans un nouvel argument de format d'adresse à chaque fois.

Pourquoi cela compte quand vous achetez du bitcoin

Trois choses dans votre propre usage du bitcoin remontent directement à cette mise à niveau.

La première est ce que vous payez pour déplacer des bitcoins. Une entrée SegWit native fait environ 68 vbytes contre environ 148 pour une entrée héritée, donc un portefeuille qui dépense trois entrées à un taux de frais de 20 sat/vB économise plusieurs milliers de satoshis sur une seule transaction. Cette économie se matérialise quand vous dépensez, pas quand vous recevez, donc c'est le type d'adresse qu'utilise votre propre portefeuille qui compte, pas celui depuis lequel votre plateforme d'échange effectue le retrait.

La deuxième est ce que votre portefeuille matériel peut vous indiquer en toute sécurité. Parce que le BIP-143 s'engage sur le montant de l'entrée, les frais affichés sur un écran Trezor ou Ledger sont dérivés de données que l'appareil peut vérifier plutôt que de données que l'ordinateur connecté affirme. Cela a fermé une véritable attaque, et c'est pourquoi signer une entrée héritée exige encore que l'appareil reçoive la transaction précédente entière pour vérifier lui-même le montant.

La troisième est Lightning, et donc toute plateforme d'échange construite dessus. Strike déplace de la valeur sur Lightning par défaut, et les canaux Lightning sont financés dans des sorties SegWit parce que le protocole ne peut pas fonctionner sans un txid stable. Pas de SegWit, pas de canaux, pas de produit de règlement instantané par-dessus.

Le bug de malléabilité qu'il fallait d'abord éliminer

La malléabilité des transactions ressemble à un cas limite et était le plus grand obstacle à la construction de quoi que ce soit par-dessus le bitcoin.

Une signature ECDSA a plus d'un encodage valide. Avant SegWit, un tiers surveillant le mempool pouvait prendre une transaction non confirmée, réencoder une signature sans l'invalider, et la rediffuser. Les bitcoins allaient toujours au même endroit pour le même montant. Seul l'identifiant de transaction changeait, et tout logiciel ayant enregistré l'identifiant d'origine croyait désormais que le paiement avait disparu. Mt. Gox a publiquement imputé l'arrêt des retraits à la malléabilité en février 2014, une affirmation que d'autres développeurs ont contestée à l'époque, mais la faille sous-jacente était réelle.

Les canaux de paiement la rendaient fatale plutôt que gênante. Un canal fonctionne en détenant une transaction de remboursement signée qui dépense une sortie de financement identifiée par son txid, avant même que cette transaction de financement soit diffusée. Changez le txid et le remboursement devient impossible à dépenser, laissant une partie capable de prendre l'argent de l'autre en otage. L'article de 2015 sur le Lightning Network de Joseph Poon et Thaddeus Dryja désignait une correction de la malléabilité comme prérequis dans son propre texte.

SegWit a éliminé le problème à la racine en sortant les signatures de la préimage de l'identifiant. Toute entrée dépensant une sortie témoin a un txid qu'aucun tiers ne peut modifier, et les protocoles de canaux ont enfin pu être construits comme prévu.

SegWit vs données témoin

SegWit est la mise à niveau ; les données témoin sont la structure qu'elle a créée. L'une est un événement avec une date, le 24 août 2017, et une spécification, le BIP-141. L'autre est un champ qui existe dans la plupart des transactions du réseau aujourd'hui, portant des signatures et des scripts, et qui a sa propre sérialisation et son propre poids réduit. Dire qu'une transaction « utilise SegWit » est une façon abrégée de dire qu'elle dépense des entrées dont l'autorisation réside dans ce champ.

SegWit vs Taproot

Deux soft forks, à quatre ans d'intervalle, tous deux portant sur les témoins. SegWit a créé la structure témoin et défini les types de sortie de version 0, ceux dont les adresses commencent par bc1q. Taproot a rempli la version 1, ajouté les signatures Schnorr et changé la façon dont les scripts à l'intérieur d'un témoin sont évalués, produisant des adresses commençant par bc1p. Taproot n'a pu être déployé aussi peu coûteusement que parce que SegWit avait déjà construit le système de versionnage, ce qui fait que les deux se lisent mieux comme un seul design réalisé par étapes.