Dans un article publié samedi sur medium.com, Luke Dashjr (alias Luke-Jr), développeur de Bitcoin Core, classe les modifications de la version bêta 1 de Segwit2x en cinq catégories : « Je commencerai par la partie la plus simple : le rebranding. “Bitcoin Core 0.14.1” est devenu “btc1 Core 1.14.3”. Pas grand chose à dire là-dessus mais il est intéressant de noter que “btc1 Core 1.14.3” est basé sur la version 0.14.1 plutôt que sur la 0.14.2 de Bitcoin Core qui corrige pourtant un certain nombre de bugs, notamment une vulnérabilité concernant “miniupnpc”.
La modification suivante c’est “testnet5”. Il s’agit d’un nouveau testnet, créé pour des raisons obscures. Si on souhaite tester un changement sur Bitcoin, on peut très bien utiliser le « testnet » existant, Pourquoi en créer un nouveau ? Je ne comprends pas ce choix.
Il existe ensuite quelques changements de règles qui entrent en vigueur immédiatement après le passage à btc1, sans attendre l’activation d’un “soft fork” ou d’un “hard fork”. En particulier en ce qui concerne les transactions qui sont maintenant autorisées à utiliser jusqu’à 32k sigops [1], au lieu de 16k dans Core […].
Btc1 inclut le fameux BIP 91, ce qui réduit le seuil d’activation de Segwit à 80% après quelques jours de signalement sur le bit 4 [2]. Cela ressemble au BIP 148, si ce n’est qu’on donne un droit de veto aux mineurs fournissant 20% de hashrate (c’est-à dire à Bitmain).
Enfin, nous arrivons à la question du “hard fork”. Il n’est pas signalé dans le bit 4, mais s’active environ 90 jours (12960 blocs) après l’activation de Segwit, peu importe comment Segwit est activé ; cela signifie que si Bitmain bloque Segwit2x, les nœuds btc1 déclencheront tout de même un “hard fork” 90 jours après l’activation de Segwit par le BIP 148. Le hardfork ne se produirait certes pas si Segwit n’était pas activé du tout, mais le BIP 148 se déclenchera, donc Segwit s’activera sans aucun doute.
En ce qui concerne le “hard fork” lui-même, il comprend une limite de taille de bloc maximum à 8 Mo (tout en faisant en sorte que cela ressemble à 2 Mo dans le code), une limite maximale des “sigops” de 160k (tout en faisant en sorte que cela ressemble à 20k) et une limite de poids maxi de 8M maximum (c’est-à-dire une taille de bloc attendue d’environ 4 Mo). Pour résoudre le problème de scalabilité de “Sighash” [3], une nouvelle limite de 1 Mo est imposée sur les données de base “non-witness” de chaque transaction. Pour éviter le risque de réorganisation, le premier bloc respectant les règles du “hard fork” est requis pour dépasser les 1 Mo de données “non-witness”. Utiliser le “hard fork bit” aurait été une meilleure façon de parvenir à cette fin. Cela aurait également permis d’empêcher d’éventuelles réorganisations d’affecter les clients légers “SPV” [4].
Quelques réflexions à propos de ce projet
Des tailles de blocs de 4 à 8 Mo ne sont pas saines. Même les blocs de 1 Mo sont déjà clairement dangereux pour Bitcoin. Cette proposition de “hard fork” ne me semble pas acceptable, elle le serait peut-être avec un “soft fork” qui limiterait la taille à quelque chose de raisonnable. Mais même dans ce cas je ne soutiendrais pas cette proposition : si vraiment nous devions faire un “hard fork” ce serait pour apporter des changements réellement utiles – par exemple le “native merge-mining” [5], comme l’a suggéré Satoshi il y a plusieurs années – ou encore pour régler certains problèmes insolubles comme la vulnérabilité de la chaîne de temps [6]. Je ne suis certainement pas le seul à penser cela, je peux donc affirmer avec un niveau de confiance relativement élevé que le “hard fork” de Segwit2x échouera.
Globalement il me semble que l’objectif réel de Segwit2x c’est d’essayer de bloquer Segwit. Je n’affirme pas que tous les signataires de l’accord de New York ont ce but à l’esprit, mais plutôt que la conception de Segwit2x est telle qu’elle correspond à cet objectif. Bitmain peut très bien avoir fait cela intentionnellement, mais il semble peu probable que quelqu’un d’autre l’ait voulu. Segwit2x est une diversion destinée à contrer le soft fork BIP 148 qui est déjà déployé de manière irréversible sur le réseau. En promouvant le BIP 91 et Segwit2x comme alternative au BIP 148, les mineurs tentent de reprendre le pouvoir afin de récupérer leur veto et de permettre à Bitmain de tout bloquer au dernier moment. Si la majorité économique n’a pas adopté le BIP148 en août, il suffira alors à Bitmain de miner une transaction non standard pour provoquer une scission et être suivi par un grand nombre des nœuds non BIP148.
La seule parade c’est de faire connaître le BIP 148 et de s’assurer que le plus grand nombre possible d’acteurs adopte cette proposition avant août. C’est valable également si vous soutenez le “hard fork” de Segwit2x, et même si vous vous opposez à Segwit. Tout le monde devrait adopter le BIP 148 car il n’interdit pas le déploiement de Segwit2x et n’exige de personne qu’il accepte ou qu’il utilise Segwit. La seule conséquence du BIP 148, c’est que les mineurs ne peuvent plus empêcher les autres d’adopter Segwit et, si le soutien est suffisamment fort, que les mineurs ne peuvent pas effectuer une attaque de la chaîne sans subir de perte financière. Si les participants de Segwit2x sont honnêtes, il n’y a aucun risque d’exécuter le BIP148 et s’ils sont malhonnêtes, le BIP 148 est nécessaire pour protéger votre nœud. »
Source : medium.com
Merci à Francois Masurel pour ses suggestions et son aide à la traduction.
[1] Signature operation : Il s’agit des opérations de signature des transactions Bitcoin. Opérations qui peuvent être coûteuses, d’où les limites mises en place pour éviter les attaques DoS.
[2] Bit : espace dans l’entête d’un bloc de transaction réservé au signalement des BIPs.
[3]Signature hash.
[4] Vérification de paiement simplifié : méthode utilisée par certains clients légers de Bitcoin pour vérifier, sans télécharger tout la blockchain, qu’une transaction est bien incluse dans un bloc.
[5] L’idée du « minage fusionné » c’est de permettre à un mineur de travailler sur plusieurs une chaînes de blocs en même temps.
[6] Il s’agit d’une attaque à 51% dans laquelle l’attaquant définit artificiellement les horodateurs de blocs pour abaisser la difficulté, ce qui lui permet d’obtenir une plus grande part de la récompense.
