SegWit a modifié les règles de Bitcoin en séparant les données qui prouvent le droit de dépenser, comme les signatures, de la partie servant à calculer l’identifiant principal d’une transaction. Il a aussi changé la mesure de la capacité des blocs. Pour l’utilisateur, cela peut rendre les paiements plus économes en place ; pour le développeur, l’enchaînement des transactions plus fiable.
Lors de l’envoi, le portefeuille précise quels fonds reçus auparavant il dépense et quels nouveaux montants reviennent au destinataire et, si nécessaire, à vous comme monnaie rendue. Il doit aussi prouver le droit de dépenser ces fonds. C’est le rôle des signatures et des autres données de vérification. SegWit les a placées dans une partie appelée witness. Ce mot désigne ici une preuve que les conditions de dépense sont remplies, pas une personne assistant au paiement. Ces données n’ont été ni jetées ni déplacées hors de Bitcoin : les nœuds appliquant les règles SegWit les vérifient toujours. [1]
Le portefeuille suit le paiement grâce à son txid. Une transaction ultérieure utilise aussi cet identifiant pour désigner les fonds qu’elle veut dépenser. Autrefois, modifier certaines données de signature pouvait changer le txid sans changer les destinataires ou les montants. Cela compliquait l’enchaînement de paiements non encore confirmés. SegWit calcule le txid sans le witness : modifier seulement celui-ci ne le change donc pas. Pour protéger toute la transaction contre ce problème, toutes ses entrées doivent utiliser SegWit. Modifier les destinataires ou les entrées peut toujours changer le txid. Des références plus stables ont aussi facilité Lightning Network, un réseau de paiements par canaux. Un second identifiant, wtxid, inclut au contraire le witness. [1] [4]
SegWit a introduit le poids au lieu de compter chaque octet de la même façon. Un octet de données de base coûte 4 unités de poids, un octet supplémentaire de witness en coûte 1. Un bloc entier est limité à 4 000 000 d’unités. Une transaction de 100 octets de base et 100 octets supplémentaires de witness pèse ainsi 500 unités, soit une taille virtuelle de 125 vB. Cette taille sert à calculer les frais au taux choisi en sat/vB. L’économie dépend donc de la structure, tandis que la demande de place continue d’influencer le taux. La limite de poids n’implique ni une taille identique en mégaoctets pour tous les blocs, ni des paiements SegWit toujours moins chers. [1]
Sur le réseau principal Bitcoin, les adresses SegWit natives de version 0 commencent par bc1q. P2WPKH et P2WSH distinguent deux types de conditions : un paiement habituel contrôlé par une clé et un paiement avec un script, c’est-à-dire un ensemble de règles. SegWit peut aussi être encapsulé dans l’ancien format P2SH, dont l’adresse commence par 3 ; ce 3 seul ne prouve toutefois pas l’usage de SegWit. Taproot utilise la version 1 du witness et des adresses bc1p. Le préfixe bc1 ne désigne donc pas un type unique de paiement. Au quotidien, vérifiez la compatibilité du portefeuille expéditeur et l’adresse complète du destinataire ; aucun de ces préfixes ne promet à lui seul l’anonymat. [1] [2] [3]
La modification a été conçue comme un Soft Fork : des règles plus strictes compatibles avec les anciennes. Un ancien nœud ne vérifie pourtant pas lui-même toutes les nouvelles conditions SegWit. Le witness est lié cryptographiquement au bloc par un witness commitment dans la coinbase, première transaction du bloc. Les signatures ne sont donc pas une annexe facultative que la validation complète pourrait ignorer. BIP 141 exprime aussi le poids comme trois fois la taille de base plus la taille totale ; la taille virtuelle est le poids divisé par quatre, arrondi au supérieur. Ce sont des descriptions du même calcul, pas deux limites différentes. [1]
Pour une vision complète, lisez aussi Transaction, Transaction Fees, Lightning Network, Taproot. Cette entrée est également citée par Transaction, Transaction Fees, Taproot, Lightning Network.