SegWit, la modification de Bitcoin que personne ne comprenait

Segwit, abréviation de Segregated Witness, était une mise à niveau de Bitcoin ayant pour but principal de corriger la malléabilité des transactions. Proposée formellement en décembre 2015, elle a été l’un des éléments centraux du débat sur la scalabilité de Bitcoin.

L’origine : la malléabilité des transactions

SegWit tire son origine du problème de la malléabilité des transactions. Ce problème repose sur le caractère « malléable » d’une transaction qui fait qu’il est possible de modifier son identifiant avant son inclusion à la chaîne de blocs, généralement lorsqu’elle est présente dans la mempool des nœuds. Cette modification de l’identifiant peut être réalisée par le signataire qui peut utiliser un nombre aléatoire différent dans l’algorithme de signature (ECDSA) pour produire une signature conforme, mais elle peut aussi être le fait un tiers par la construction d’un script de déverrouillage (c’est-à-dire le script contenant la signature) différent mais également valide.

Ce problème n’est pas un problème très grave pour le fonctionnement de Bitcoin. En effet, puisque l’identifiant d’une transaction confirmée ne peut pas être modifié sans réécrire une partie de la chaîne de blocs, celui-ci peut être considéré comme définitif au bout d’un certain temps et on peut y faire référence sans craindre qu’il ne change. En revanche, quand il s’agit de se baser sur cet identifiant avant la confirmation (ou même la publication) de la transaction, cela devient un problème.

Ce problème est identifié dès le 19 janvier 2012 lorsque Gavin Andresen, alors mainteneur en chef du projet, évoque ce problème sur la liste bitcoin-dev. Dans son courriel, il qualifie ce comportement d’« inattendu, d’autant plus qu’il change l’identifiant de la transaction » et propose un correctif pour rendre non standard tout script de déverrouillage qui inclurait des données supplémentaires. S’en suit une discussion entre Russell O’Connor, Matt Corallo, luke-jr, Gregory Maxwell, Michael Marquardt (theymos) qui a lieu sur IRC et qui leur fait prendre conscience de l’étendue du problème.

Un an et demi plus tard, en août 2013, dans une discussion avec Peter Todd, Gregory Maxwell propose de mettre de côté le script de déverrouillage (scriptSig) dans le processus de hachage de la transaction :

« Je suggère de ne jamais hacher cette valeur dans le protocole. En gros, je dis que les scriptsigs pour une [transaction] seraient un arbre de hachage séparé. Il est toujours engagé dans la chaîne de blocs mais ce serait une branche séparée. »

Peter Todd pourrait en effet bénéficier en effet d’une correction de la malléabilité afin de mettre en place de son concept de « fidelity bonds ».

Un mois plus tard, Gregory Maxwell (encore lui) partage son idée de séparer le script de signature du reste de la transaction à Adam Back, en précisant que « sortir la [signature] de [l’identifiant de la transaction] pourrait aider mais [que] ce serait un changement très profond qui provoquerait un hard fork » et qu’il s’agirait d’un changement « délicat à sécuriser ». Il n’est donc pas question de l’implémenter.

Toutefois, le problème reste présent et surgit dans l’actualité quelques mois plus tard. C’est ainsi qu’entre le 9 et le 11 février 2014, Mt. Gox et d’autres plateformes d’échange subissent des attaques exploitant la malléabilité des transactions. Les transactions de retrait sont modifiées par les attaquants, faisant croire aux plateformes mal configurées que ces transactions n’ont pas été confirmées, ce qui leur permet de recréditer leur compte tout en conservant les bitcoins. Ces attaques mènent à une perte totale de 64 564 bitcoins.

La solution préférée à l’époque est de modifier le forme des transactions pour limiter au maximum la malléabilité des transactions. C’est dans cet esprit que le BIP-62 est créé en mars 2014, dont l’une des exigences (l’encodage standard des signatures décrit dans le BIP-66) est appliquée le 4 juillet 2015. Cependant, les changements décrits ne concernent que la malléabilité par un tiers, pas la malléabilité par le signataire, ce qui ne va pas être suffisant.

>> Jouez la sécurité, inscrivez-vous sur Binance LA référence des exchanges crypto (lien commercial) <<

La mise en œuvre en 2015

L’idée de séparer le script de signature de la transaction revient en 2015, avec l’invention du Lightning Network, dont l’implémentation pourrait être grandement facilitée par une résolution complète du problème de malléabilité. En effet, les canaux de paiements se basent sur des transactions non publiées auxquelles il faut faire référence, qui font intervenir de la multisignature, et dont l’identifiant peut par conséquent être modifié par l’une des deux parties engagées dans un canal de paiement.

Le 8 juin 2015, Blockstream annonce la version alpha modèle de sidechain appelé Elements. Ce modèle est présenté par Gregory Maxwell au cours d’un séminaire de développements de San Francisco. Il inclut une particularité appelée Segregated Witness, ou « témoin séparé » en français, qui consiste à prévoir un témoin où placer les signatures et qui supprime totalement la malléabilité des transactions. Le témoin est ici décrit par Maxwell comme « une valeur spécifique qui constitue une preuve concrète d’affirmation existentielle ».

Cependant, cette fonctionnalité représente toujours un hard fork, ce que veulent éviter à tout prix les développeurs de Bitcoin Core. Ils considèrent que la chose est moins sûre qu’un soft fork, mais sutout qu’elle ne pourrait pas être mise en œuvre sans provoquer une scission. En effet, c’est à cette époque que la guerre civile dans la communauté commence à faire rage, suite à la sortie de Bitcoin XT. Bitcoin Core a donc tout intérêt à représenter la voix de la raison en prônant la stabilité.

En octobre, entre les deux conférences de Scaling Bitcoin, au détour d’une conversation sur IRC, le développeur luke-jr suggère indirectement que SegWit pourrait se faire par un soft fork. Cette suggestion inspire alors les autres développeurs pour construire la mise à niveau sous cette forme. Par la suite, Peter Todd ira même jusqu’à décrire comment toute modification peut se faire sous la forme d’un soft fork.

C’est ainsi que le 7 décembre 2015, lors de la conférence Scaling Bitcoin II à Hong Kong, SegWit est officiellement introduit à la communauté par Pieter Wuille. Dans une présentation ayant pour titre « Segregated Witness for Bitcoin », il décrit les avantages procurés par la mise à niveau :

• Une correction complète de la malléabilité (par un tiers et par un signataire) ;
• Une réduction de 75 % sur la façon dont les données du témoins sont comptées ;
• Un versionnage des scripts ;
• La possibilité de mettre en place des preuves de fraude ;
• Une réduction de la bande passante pour les portefeuilles légers et pour la synchronisation initiale des nœuds ;
• Une compatibilité pour les anciens nœuds via l’emboîtement dans P2SH.

Le même jour, SegWit est cité dans le courriel récapitulatif de Gregory Maxwell publié sur la liste de diffusion bitcoin-dev, courriel qui deviendra par la suite la feuille de route de Bitcoin Core.

Dans la foulée, des propositions d’amélioration de Bitcoin sont écrites pour formaliser SegWit :

• Le BIP-141 est créé le 21 décembre 2015 par Eric Lombrozo, Johnson Lau et Pieter Wuille, et décrit la mise à niveau de manière générale, dont notamment :
  • La correction de la malléabilité via le remplacement de l’identifiant par deux nouveaux identifiants : l’identifiant de la transaction qui prend en compte la transaction sans les scripts de déverrouillage (et qui n’est donc pas sujet à la malléabilité), et l’identifiant du témoin qui prend en compte uniquement le témoin.
  • Une augmentation de la capacité transactionnelle : le témoin (contenant les scripts de déverrouillages) est placé en dehors de la connaissance des nœuds pré-SegWit, ce qui permet de les « tromper » sur la taille réelle des transactions. Une nouvelle unité de mesure est mise en place : la taille virtuelle qui est définie comme la somme de la taille de base (transaction sans le témoin) et du quart de la taille du témoin, c’est-à-dire sv = sb + sw/4.
  • Le versionnage des scripts.
  • L’incrustation dans P2SH pour permettre la compatiblité avec tous les portefeuilles.
• Le BIP-142 est créé le 24 décembre 2015 par Johnson Lau, et définit un système d’adresses pour SegWit. Celui-ci sera par la suite annulé au profit du BIP-173.
• Le BIP-143 est créé le 3 janvier 2016 par Johnson Lau et Pieter Wuille, et propose de modifier l’algorithme de signature des transactions SegWit pour éviter les hachages redondants dans l’algorithme de signature et améliorer la signature hors-ligne.
• Le BIP-144 est créé le 8 janvier 2016 par Eric Lombrozo et Pieter Wuille dans le but de mettre à jour les services de communication entre les pairs sur le réseau.
• Le BIP-145 est créé le 30 janvier 2016 par luke-jr, et décrit comment mettre à jour le message getblocktemplate sur le réseau.

Au début de l’année 2016, SegWit est ainsi une idée à peu près bien formulée, même si des détails seront modifiés par la suite. SegWit devient alors défendable mais aussi criticable, et fait son entrée dans le débat sur la scalabilité.

SegWit et le débat sur la scalabilité de Bitcoin

SegWit s’inscrit pleinement dans le débat sur la scalabilité en constituant une mise à niveau accompagnant le passage à l’échelle de Bitcoin. D’une part, il résout le problème de la malléabilité des transactions, et permet par là une implémentation simple de Lightning. D’autre part, il augmente la capacité transactionnelle du réseau, pour atteindre un doublement à maturité.

Néanmoins, ces aspects sont mal compris car le défaut majeur de SegWit est sa complexité, chose qui lui sera reprochée à de nombreuses reprises et qui rendra le débat peu audible des deux côtés.

En 2016, le débat prend un autre tournant : les partisans de l’augmentation de la taille limite des blocs ont échoué à activer Bitcoin XT (qui amenait la limite à 8 Mo) et en sont réduits à soutenir une augmentation moins agressive de 2 Mo. Ils s’opposent à SegWit directement, voyant dans cette étrange mise à niveau un moyen politique de détourner l’attention du problème réel.

Ainsi, Mike Hearn, dans son article d’adieu du 14 janvier, qualifie SegWit d’« astuce comptable » et dit la chose suivante à son sujet :

« Elle nécessite d’apporter d’énormes changements à presque tous les logiciels liés à Bitcoin. Au lieu de faire quelque chose de simple et d’augmenter la limite, elle choisit de faire quelque chose d’incroyablement compliqué qui pourrait prendre des mois tout au plus, en supposant un énorme effort coordonné. »

Cet argument de la complexité d’implémentation est le premier argument du panel développé par les big blockers. C’est ce qui fait dire à certains d’entre eux que SegWit devrait se faire sous la forme d’un hard fork, comme par exemple le mineur Jonathan Toomim qui déclarait dès le 8 décembre 2015, le lendemain de sa présentation :

« Mon attitude est que c’est laid et maladroit et que ce n’est pas une manière intuitive. Je vois juste qu’ils mettent un témoin séparé ici parce que ce sera un soft fork, mais qui est mieux comme un hard fork, où il sera plus élégant et plus sûr. »

Cet argument est tout à fait valable, et même Peter Todd, pourtant partisan de la limitation de la taille des blocs et considérant que les soft forks sont plus sûrs que les hard forks, critique durement cette implémentation. Néanmoins, c’est le prix à payer pour activer SegWit sans provoquer une scission de la chaîne.

Cela nous amène au deuxième argument qui est que SegWit est une « coercition par effet de réseau », argument notamment défendu par Vitalik Buterin, qui soutient l’augmentation de la taille limite des blocs. En effet, à l’inverse d’un hard fork, qui crée nécessairement des protocoles incompatibles, le soft fork oblige la partie la plus libérale à suivre celle la plus restrictive. Si appliqué par une majorité de la puissance de calcul, il force les opposants à procéder à un hard fork pour parvenir à maintenir un protocole correct.

Un troisième argument est que SegWit ne serait pas une réelle augmentation de la taille des blocs : puisque les anciens nœuds maintiendraient leur limite à 1 Mo, selon l’ancienne définition rien n’aurait changé. Bien que cet argument soit utilisé par les détracteurs de SegWit comme par ses partisans, il est complètement bancal puisque les nœuds complets validateurs (dont les mineurs font partie) doivent vérifier l’intégralité des signatures, et doivent donc télécharger les témoins en plus des transactions classiques ce qui correspond à une charge supplémentaire. Les anciens nœuds ne valident en réalité que partiellement la chaîne.

Un quatrième argument, qui est lié à cette incompréhension, est que SegWit diminue la sécurité du réseau en séparant les signatures du reste des transactions. Cette vision est probablement issue des premières présentations de SegWit réalisées par Gregory Maxwell et Pieter Wuille qui insistaient sur le fait que les signatures ne pouvaient plus être vérifiées dans certains cas (notamment la synchronisation initiale). Cependant, même s’il est vrai que les nœuds suivant les anciennes règles ne vérifient pas les signatures utilisant SegWit, les nœuds suivant le protocole mis à niveau vérifient l’intégralité des signatures.

Il n’est donc pas vrai de dire, à l’instar de Peter Rizun, que « les pièces SegWit ne sont pas des bitcoins » et qu’elles ne sont pas conformes à la définition du livre blanc, à savoir des « chaînes de signatures numériques ». Du point de vue des anciens nœuds, les pièces SegWit sont verrouillées par un script dit « anyone-can-spend », c’est-à-dire que tout le monde peut les dépenser, ce qui est une qualité requise pour faire de SegWit un soft fork efficace. Néanmoins, si jamais quelqu’un cherchait à les dépenser sans fournir de signature valide, que les anciens nœuds acceptaient cette transaction, et qu’un mineur l’incluait dans son bloc, ce bloc serait rejeté par la majorité de la puissance de calcul du réseau. Ce caractère « anyone-can-spend » n’a donc rien de dangereux, à condition que suffisamment de mineurs appliquent le soft fork.

Ainsi, à partir de 2016, SegWit constitue un point central dans le débat sur la scalabilité de Bitcoin. Il devient à ce moment l’amélioration prônée par le camp des partisans des petits blocs, et l’essentiel du débat se polarise autour de deux alternatives : SegWit par un soft fork ou l’augmentation de la taille des blocs par hard fork. SegWit finira par être activé en août 2017, suite à une longue période de lutte et d’incertitude.

Pour écrire ce texte, je me suis basé sur l‘ouvrage The Blocksize War de Jonathan Bier et sur l’article « The Long Road to SegWit » de Aaron van Wirdum.

Le Journal du Coin est fier de pouvoir vous conter les petites et grandes histoires de Bitcoin et des cryptomonnaies. Pour soutenir le journal dans ce type d’initiative et garantir son indépendance, n’hésitez pas à passer par les liens affiliés du média, que vous souhaitiez acheter vos premiers bitcoins, les trader sur une plateforme ultra-robuste, voire pourquoi pas les miner vous-même !