Segwit a été activé aujourd’hui à 3h57 (heure de Paris) au bloc 481824.

« Segregated Witness » (SegWit) est une amélioration majeure du protocole Bitcoin. Voilà une traduction d’un article qui récapitule, les bénéfices attendus par cette amélioration.

Correctifs de la malléabilité

Les transactions Bitcoin sont identifiées par un hash hexadécimal de 64 caractères appelé identifiant de transaction (txid) lequel est basé sur les fonds dépensés d’une part et sur qui sera capable de dépenser les résultats de la transaction d’autre part.

Malheureusement, la façon dont le txid est calculé permet à quiconque de faire de petites modifications à la transaction qui ne changeront pas sa signification, mais qui vont changer le txid. Ceci est appelé la malléabilité par un tiers. BIP 62 (“traiter la malléabilité”) a tenté de répondre à ces questions d’une manière fragmentaire, mais était trop compliqué à mettre en œuvre à l’aide de contrôles de consensus et a été retiré.

Par exemple, vous pourriez émettre une transaction avec le txid ef74…C309 sur le réseau, mais constater qu’un tiers, comme un nœud sur le réseau relayant votre transaction, ou le mineur qui inclut votre transaction dans un bloc, modifie légèrement la transaction, résultant en une transaction qui dépense les mêmes fonds et paye les mêmes adresses, mais est confirmée sous un txid totalement différent 683f…8bfa.

Plus généralement, si un ou plusieurs des signataires de la transaction modifient leurs signatures alors la transaction reste valable et paie les mêmes montants aux mêmes adresses, mais le txid change complètement car il intègre les signatures. Le cas général où des modifications sont apportées aux données de signature (mais pas des sorties ou une sélection d’entrées) et qui modifient donc la transaction est appelé la malléabilité scriptSig.

Segwit empêche la malléabilité par un tiers et la malléabilité scriptSig en permettant aux utilisateurs Bitcoin de déplacer les parties malléables de la transaction dans le témoin de la transaction (transaction witness), et de séparer ce témoin afin que les changements apportés au témoin n’affectent pas le calcul du txid.

Scaling linéaire des opérations de sighash

Les approches basiques d’augmentation de la taille des blocs de Bitcoin font face à un problème majeur, en effet pour certaines transactions, la procédure de hachage des signatures croit de manière quadratique plutôt que linéaire.

Linear versus quadratic

En substance, doubler la taille d’une transaction augmente à la fois le nombre des opérations de signature, mais aussi la quantité de données qui doit être hachée pour la vérification de chacune de ces signatures. Cela a déjà pu être constaté, un seul bloc peut nécessiter jusqu’à 25 secondes pour être validé, et des transactions malicieusement conçues pourraient prendre plus de 3 minutes.

Segwit résout ce problème en changeant la manière de calculer le hash de la transaction pour les signatures, afin que chaque octet d’une transaction ne soit haché que deux fois au plus. Cela permet d’offrir la même fonctionnalité plus efficacement, de sorte que même de grosses transactions peuvent être générés sans rencontrer de problème dû au hachage des signatures, même si elles sont générées par malveillance ou que des blocs beaucoup plus gros (et donc des transactions plus importantes) sont pris en charge.

Signature des montants d’input

Quand un portefeuille matériel signe une transaction, il peut facilement vérifier le montant total dépensé, mais il ne peut déterminer les frais de manière sûre qu’en ayant une copie complète de toutes les transactions d’entrée dépensées, et doit hacher chacune de celles-ci pour s’assurer qu’on ne lui a pas fourni de fausses données. Chaque transaction pouvant faire individuellement jusqu’à 1 Mo en taille, cette opération peut s’avérer coûteuse, même si la transaction que l’on signe est elle-même plutôt petite.

Segwit résout ce problème en hachant explicitement le montant de l’entrée (input). Cela signifie qu’un portefeuille matériel peut simplement recevoir le hash de la transaction, l’index, et le montant (et connaître la clé publique utilisée), et peut signer en toute sécurité la transaction qui dépense, peu importe la taille ou la complexité de la transaction dépensé.

Amélioration de la sécurité pour le multisig via pay-to-script-hash (P2SH)

Les paiements multisig utilisent actuellement P2SH qui est sécurisé par l’algorithme HASH160 sur 160 bits (RIPEMD de SHA256). Toutefois, si un des signataires souhaite voler tous les fonds, il suffit de trouver une collision entre une adresse valide dans le cadre d’un script multisig et un script qui envoie simplement tous les fonds à lui-même avec seulement 80 bits (280) de travail, ce qui est déjà dans le domaine du possible pour un attaquant extrêmement bien doté en ressources. (A titre de comparaison, à une puissance soutenue de 1 exahash/seconde, le réseau minier Bitcoin produit 80 bits de travail toutes les deux semaines)

Segwit résout ce problème en utilisant l’algorithme HASH160 uniquement pour les paiements directs à une clé publique unique (où ce genre d’attaque est inutile), tout en utilisant des hashs SHA256 de 256 bits pour les paiements à un hash de script.

Versionnage des scripts

Il est possible de modifier le langage de script de Bitcoin pour permettre à la fois d’améliorer la sécurité et d’ajouter de nouvelles fonctionnalités. Cependant, tel qu’il a été conçu, le langage de script de Bitcoin n’autorise les modifications que si elles sont rétrocompatibles (soft-forking) et qu’elles sont mises en œuvre en remplaçant l’un des dix OP_NOP opcodes encore disponibles avec un nouvel opcode qui peut de manière conditionnelle faire échouer le script, mais qui ne peut rien faire d’autre. Cette technique est suffisante pour la plupart des modifications du langage de script – telles que l’introduction d’une nouvelle méthode de signature ou d’une fonctionnalité comme OP_CLTV, mais elle peut parfois ressembler à du bidouillage (par exemple, OP_CLTV doit être accompagné d’un OP_DROP) et ne peut pas être utilisée pour activer de nouvelles fonctionnalités même aussi simples que l’assemblage de deux chaînes.

Segwit résout ce problème en ajoutant aux scripts un numéro de version, de sorte qu’il est possible de créer de nouveaux opcodes en augmentant simplement le numéro de version alors qu’il aurait fallu auparavant effectuer un hard-fork pour en bénéficier dans les transactions non-segwit.

Réduction de la croissance de la base des UTXO

La base de données des sorties de transaction non dépensées (UTXO) est maintenue par chaque nœud Bitcoin validant les transactions, ceci afin de déterminer si les transactions qui arrivent sont valides ou frauduleuses. Pour permettre un fonctionnement performant du réseau, cette base de données doit être très rapide à interroger et à modifier, et devrait idéalement pouvoir être entièrement stockée en mémoire vive (RAM), donc il est important de maintenir aussi petite que possible la taille en octets de cette base de données.

Plus Bitcoin grandit plus la tâche devient difficile, chaque nouvel utilisateur doit en effet avoir au moins une entrée UTXO propre et préférera avoir des entrées multiples pour améliorer la confidentialité et la flexibilité, ou pour qu’elles soient disponibles en tant que support pour des canaux de paiement ou des contrats intelligents.

Segwit améliore la situation en rendant les données de signature, qui n’ont pas d’impact sur la taille de la base des UTXO, 75% moins coûteuse que les données qui ont un impact sur la taille de la base des UTXO. Cette réduction de coût devrait encourager les utilisateurs à privilégier l’utilisation de transactions segwit qui minimisent l’impact sur la base des UTXO car ils réduiront ainsi leurs frais de transaction, et cela devrait aussi encourager les développeurs à concevoir des contrats intelligents et des nouvelles fonctionnalités qui minimisent l’impact sur la base des UTXO.

Segwit étant déployé par soft-fork qui ne modifie pas la taille de base des blocks, le taux de croissance de la base des UTXO dans le cas le plus défavorable reste identique.

Preuves de fraude compactes (compact fraud proofs)

Avec l’augmentation de la base des utilisateurs de Bitcoin, le processus de validation de l’ensemble de la blockchain devient naturellement plus coûteux. Pour conserver la nature décentralisée et sans tiers de confiance de Bitcoin, il est important de permettre à ceux qui ne sont pas en mesure de valider l’intégralité de la blockchain d’être au moins capable d’en valider autant que possible pour un coût modique.

Grâce à segwit un futur soft-fork pourra étendre la structure de witness pour y inclure des données de commitment, ce qui permettra à des clients légers (SPV) de vérifier le respect des règles de consensus telles que le nombre de bitcoins créés dans un bloc, la taille d’un bloc, et le nombre de sigops utilisées dans un bloc.

Gains de performance en l’absence de vérification des signatures

Les signatures des anciennes transactions ont probablement moins d’intérêt que les signatures des transactions à venir – par exemple, Bitcoin Core ne vérifie pas, par défaut, les signatures des transactions antérieures au dernier point de contrôle (checkpoint), et certains clients SPV ne vérifient pas les signatures du tout, faisant confiance aux mineurs ou au autres nœuds pour l’avoir déjà fait. Cependant, les données de signature font actuellement partie intégrante de la transaction et doivent être présentes lors du calcul de la valeur de hachage de la transaction.

Séparer les données de signature du reste du bloc permet aux nœuds qui ne sont pas intéressés par les données de signature de les supprimer du disque voire de ne pas les télécharger du tout, et faire ainsi des économies de ressource.

Augmentation de la capacité/taille des blocs

Comme les anciens nœuds ne téléchargeront que le bloc de base sans les “témoins”, ils appliqueront uniquement la règle limitant la taille maximum des blocs à 1 Mo sur ces données. Les nouveaux nœuds sachant interpréter le bloc complet incluant les données “témoin” peuvent donc remplacer cette limite par une nouvelle permettant d’obtenir des blocs de plus grande taille. Segregated witness tire profit de cette possibilité pour augmenter la taille limite des blocs à presque 4 Mo, et ajoute une nouvelle limite de coût pour s’assurer que le traitement des blocs reste raisonnable dans l’utilisation des ressources (cela se traduit au final par une limite réelle plus proche des 1,6 à 2 Mo).

Vers une seule limite unifée de la taille des blocs

Actuellement, le consensus impose deux règles qui concernent la taille des blocs : la taille du bloc ne peut pas être supérieure à 1 Mo et il ne peut y avoir plus de 20.000 vérifications de signatures effectuées pour l’ensemble des transactions du bloc.

Trouver la sélection de transactions la plus rentable à inclure dans un bloc avec une seule limite est un cas typique du problème du sac à dos, qui peut être facilement et presque parfaitement résolu avec un simple algorithme glouton. Cependant, l’ajout d’une seconde contrainte rend la recherche d’une solution beaucoup plus difficile dans certains cas, et ce problème théorique a été exploité dans la pratique pour forcer certains blocs à être minés avec une taille bien inférieure à la capacité maximale.

Il est impossible de résoudre ce problème sans un hardfork ou une diminution significative de la taille des blocs. Segwit ne pouvant pas non plus résoudre ce problème, il se contente de ne pas l’aggraver : en particulier, plutôt que d’introduire une nouvelle limite spécifique pour les données witness, segwit applique une seule limite qui combine le poids des données UTXO et des données witness, permettant aux deux d’être limités simultanément comme une seule entité combinée.

Et maintenant ?

Segwit optimise donc l’espace des blocs afin d’y inclure un plus grand nombre de transactions et corrige surtout le problème de la malléabilité des transactions, ouvrant ainsi la voie à de nouvelles améliorations :

– MAST (Merkelized Abstract Syntax Trees), une amélioration qui exploite à la fois les transactions Pay to script hash (P2SH) et les arbres de Merkle. MAST pourrait permettre d’effectuer sur Bitcoin des « smart contracts » plus complexes tout en réduisant la quantité de données nécessaires à leur exécution et en améliorant la confidentialité. (en savoir plus)

– Schnorr signature, une façon plus parcimonieuse et plus sûre de signer les transactions (notamment les transactions à entrées multiples ou les transactions multi-signatures). Schnorr signature permet de gagner de l’espace et pourrait également contribuer à améliorer la confidentialité du protocole CoinJoin en combinant les signatures des participants. (en savoir plus)

– TumbleBit, un service de mixage sans tiers de confiance visant à améliorer la confidentialité des transactions Bitcoins. (en savoir plus)

– Le Lightning Network, un réseau de canaux de paiement permettant d’effectuer un nombre illimité de transactions (y compris de micro-transactions) de façon quasi-instantanée, pour un coût dérisoire et sans encombrer la blockchain Bitcoin (seules les transactions de création et de clôture d’un canal de paiement sont enregistrées dans la blockchain). (en savoir plus)

Différentes implémentations du Lightning Network sont actuellement en phase de test. Lightning Labs vient de publier hier sa version alpha 0.3 : « Cette version englobe presque toutes les fonctionnalités que nous souhaitons développer avant une version « mainnet ». Cela dit, nous ne publierons pas de version MainNet de Lightning Network Daemon tant que notre implémentation ne sera pas complètement testée et stable. » – Elizabeth Stark, CEO de Lightning Labs.

Pierre-Marie PADIOU, confondateur d’Acinq qui envisage de publier prochainement une démonstration d’un paiement cross-implémentations, confirme qu’il faudra encore être patient : « Le niveau de maturité de LN et de compatibilité entre les implémentations n’est à cette heure pas suffisant pour que cela se passe sans confusion et sans risque pour les fonds des utilisateurs. Les autres implémenteurs partagent ce constat et nous sommes tombés d’accord pour ne pas nous lancer dans une course à l’échalote sans intérêt. »

Acinq, Lightning Labs et Blockstream devraient publier prochainement une déclaration commune pour faire le point sur les avancées et fixer les prochaines étapes.

source