Guerre civile de Bitcoin : L’influence de l’User Activated Soft Fork (UASF)

L’année 2017 a été celle de la résolution du débat sur la scalabilité de Bitcoin et celle de l’activation de SegWit. Néanmoins, cette résolution ne s’est pas faite pacifiquement et a fait l’objet d’une bataille d’influence, notamment par le biais de l’User Activated Soft Fork.

Un UASF pour faire pression sur les mineurs

Au début de l’année 2017, les blocs commencent à atteindre leur capacité limite sur Bitcoin, ce qui crée des congestions sur le réseau et fait augmenter les frais de transaction. De ce fait, la situation devient critique et pousse la communauté à demander une décision rapide.

Le débat sur la scalabilité oppose alors deux camps principaux :

• D’un côté, le camp des partisans de l’augmentation de la taille limite des blocs, favorables à une optimisation du protocole dans ce sens, qui se rassemblent derrière l’implémentation Bitcoin Unlimited ;
• De l’autre, le camp de ceux qui s’y opposent, souhaitant activer SegWit pour faciliter le déploiement du réseau Lightning, représentés par l’implémentation principale du protocole, Bitcoin Core.

Au cours de l’année 2016, ces partisans des petits blocs ont connu un regain de popularité, notamment grâce à l’affaire Craig Wright, qui a discrédité Gavin Andresen et d’autres big blockers, et la scission entre Ethereum et Ethereum Classic, qui a montré les conséquences que pouvaient avoir un hard fork contentieux.

Les mineurs, eux, sont en grande majorité favorables à l’augmentation de la taille des blocs. Cela pose problème car la mise à niveau SegWit est à ce moment-là soumise à un signalement de la puissance de calcul (BIP-9), qui exige un seuil de 95 % de votes favorables pour enclencher l’activation, et les mineurs disposent par conséquent d’un moyen de pression pour négocier. C’est pourquoi ils refusent de voter pour SegWit, dont le signalement stagne à 25 % de la puissance du réseau.

Cela énerve considérablement les partisans des petits blocs qui considèrent que les mineurs n’ont pas à avoir un pouvoir de décision sur le protocole.

Le 25 février 2017, un développeur utilisant le pseudonyme Shaolin Fry publie un courriel sur la liste de diffusion bitcoin-dev, dans lequel il explique pourquoi l’écosystème devrait adopter les soft forks activés par les utilisateurs ou user activated soft forks (UASF). Ce type d’activation s’oppose à l’activation par les mineurs des soft forks, qui a été utilisée par le passé pour le BIP-66 (juillet 2015), pour OP_CHECKLOCKTIMEVERIFY (décembre 2015) et pour OP_CHECKSEQUENCEVERIFY (juillet 2016), et dont SegWit se sert à présent.

UASF (soft fork activé par les utilisateurs) : restriction des règles de consensus dont l’application dépend d’une hauteur de bloc ou d’un horodatage donné. Exemple : l’ajout de la limite de 1 Mo sur la taille des blocs.	MASF (soft fork activé par les mineurs) : restriction des règles de consensus dont l’application dépend d’un seuil de signalement des mineurs. Exemple : l’ajout du code opération OP_CHECKLOCKTIMEVERIFY via le BIP-9.
UAHF (hard fork activé par les utilisateurs) : modification non restrictive des règles de consensus dont l’application dépend d’une hauteur de bloc ou d’un horodatage donné. Exemple : l’ajout des codes opérations OP_NOP par Satoshi en juillet 2010.	MAHF (hard fork activé par les mineurs) : modification non restrictive des règles de consensus dont l’application dépend d’un seuil de signalement des mineurs. Exemple (non réalisé) : l’augmentation à 8 Mo de la taille limite des blocs via Bitcoin XT.

D’après Shaolin Fry les soft forks activés par les mineurs (MASF) posent 4 problèmes :

1. « Il faut faire confiance à la puissance de hachage pour valider [le soft fork] après l’activation » : l’exemple des quelques blocs minés après l’activation du BIP-66 le 15 juillet 2015 a montré que les mineurs peuvent mentir.
2. « Le signalement des mineurs leur donne un droit de veto naturel qui permet à un petit pourcentage du taux de hachage d’opposer son veto à l’activation par les nœuds de la mise à niveau. »
3. « La méthode de signalement est largement interprétée à tort comme le vote d’une proposition par la puissance de hachage et il semble difficile de corriger ce malentendu dans la communauté. »
4. « Elle attire inutilement l’attention sur les mineurs, ce qui peut devenir inutilement politique » : les mineurs subissent la pression de devoir prendre une décision pour la communauté.

Le courriel de Shaolin Fry contient également un lien vers un brouillon du BIP-8, une version modifiée du BIP-9 qui active une mise à niveau par défaut si son signalement des mineurs échoue.

Le 12 mars 2017, Shaolin Fry donne suite à son apologie et publie une première version du BIP-148, une proposition qui activerait SegWit dans le cas où il n’a pas été verrouillé entre temps. Initialement, le BIP-148 doit s’activer à compter du 1^er octobre, mais deux semaines plus tard, Shaolin Fry avance cette date au 1^er août. Il précise :

« Ce BIP sera actif entre le 1^er août 2017 à minuit (heure Unix 1501545600) et le 15 novembre 2017 à minuit (heure Unix 1510704000) si le déploiement segwit existant n’est pas verrouillé ou activé avant l’heure Unix 1501545600. Ce BIP cessera d’être actif lorsque segwit sera verrouillé.

Lorsque ce BIP est actif, tous les blocs doivent fixer à 001 les 3 bits supérieurs de l’entête nVersion ainsi que le champ de bits (1<<1) (selon le déploiement segwit existant). Les blocs qui ne signalent pas comme exigé seront rejetés. »

BIP-148: Mandatory activation of segwit deployment

Il s’agit donc d’activer indirectement SegWit en imposant aux mineurs de le signaler via le BIP-9, faute de quoi leurs blocs seront rendus invalides : un soft fork activé par l’application d’un autre soft fork en somme.

Cette proposition ne fait pas l’unanimité. L’intérêt de l’activation par les mineurs est qu’il permet de s’assurer au mieux qu’une majorité de la puissance de calcul impose le soft fork le jour de sa mise en application, pour que la modification soit effectivement « rétrocompatible  » et qu’il ne subsiste qu’une seule chaîne. Dans le cas contraire, l’activation du soft fork risque de créer deux chaînes distinctes, ce qui annule au moins partiellement l’avantage du soft fork par rapport au hard fork. Sans le soutien de la majorité des acteurs économiques du milieu et sans celui des mineurs, il est inévitable qu’un tel UASF provoque une scission.

Si certains développeurs sont favorables à l’UASF proposé par Shaolin Fry comme luke-jr, ce n’est pas le cas de tout le monde. Le 14 avril, Gregory Maxwell, contributeur et ancien mainteneur de Bitcoin Core, écrit ainsi :

« Je ne soutiens pas l’UASF du BIP148 pour les mêmes raisons que je soutiens segwit : Bitcoin a de la valeur en partie parce qu’il présente une sécurité et une stabilité élevées, segwit a été soigneusement conçu pour soutenir et amplifier cette intégrité technique sur laquelle les gens peuvent et pourront compter aujourd’hui et à l’avenir. […]

« D’abord ne pas nuire ». Nous devrions utiliser les mécanismes les moins perturbateurs disponibles, et la proposition BIP148 ne répond pas à ce critère. À entendre certaines personnes – des non-développeurs sur reddit et autres – quelques-uns voient même l’invalidation forcée des blocs mise en place par 148 comme une vertu, comme une punition des mineurs qui se comportent mal. Je ne pourrais pas être plus en désaccord avec ce point de vue. »

De même, Pieter Wuille, le principal développeur derrière SegWit, est contre. Sur IRC, il dira à luke-jr :

« je m’attends à ce que chaque nœud complet économiquement pertinent abandonne le code du bip 148 quelques heures après que le hashrate ait échoué à l’adopter […] je pense que tu es fou »

Toutefois, ce désaccord n’empêchera pas à la proposition de gagner en popularité.

La campagne de communication pour activer SegWit

Au début du printemps 2017, la mise à niveau SegWit est loin d’être activée, le signalement restant en-dessous des 30 %. Cependant, la campagne de communication déployée par les partisans des petits blocs vient changer la donne.

Le 5 avril, Gregory Maxwell accuse les mineurs chinois d’utiliser l’AsicBoost de manière secrète et de bloquer SegWit pour cette raison, se basant sur sa propre rétro-ingénierie d’une puce d’ASIC.

L’AsicBoost est une technique d’optimisation du minage, ayant été décrite un an plus tôt par Timo Hanke et Sergio Lerner, qui permettrait d’augmenter de 20 % l’efficacité du matériel (les fameux ASIC). Elle peut être implémentée de manière ouverte en bricolant l’entête du bloc, ou bien de manière secrète en jouant avec les transactions de manière plus complexe. SegWit perturbe la structure des transactions dans le bloc en ajoutant un arbre de Merkle et plaçant sa racine dans la transaction de récompense, et réduit par conséquent l’efficacité de l’AsicBoost secret. Des mineurs qui utiliseraient cette technique seraient donc incités économiquement à ne pas activer SegWit.

L’accusation de Gregory Maxwell surprend. Cependant, dès le lendemain, Bitmain, l’entreprise chinoise qui fabrique les ASIC Antminers et qui gère les coopératives de minage BTC.COM et Antpool, admet avoir essayé la technique sur le réseau de test, mais dément l’avoir utilisée sur le réseau principal. L’entreprise confirme également détenir le brevet de l’AsicBoost en Chine. Que cela soit vrai ou non, cette déclaration maladroite fait planer la suspicion autour de Bitmain.

Jihan Wu, alors PDG et co-fondateur de Bitmain, s’opposera particulièrement durement à l’UASF et organisera un plan d’urgence pour le contrer, en mettant en place un User Activated Hard Fork (UAHF) planifié pour le 1^er août, qui créera Bitcoin Cash.

La controverse autour de l’AsicBoost échauffe les esprits, ce qui mène à une autre polémique. Dans la nuit du 5 au 6 avril (UTC), Joseph Poon (co-inventeur du réseau Lightning) révèle dans une dispute avec Gregory Maxwell sur la liste de diffusion de bitcoin-dev l’existence d’une « organisation spécifique gérée par Core dont le public n’est pas au courant ». Il précise sur Reddit :

« Ils ont juste un canal secret où ils organisent leurs campagnes de relations publiques et de trollage. De nombreuses personnes en ont parlé (plus de 5 personnes) et il y est fait allusion dans divers endroits accessibles au public, puisque c’est là où se prennent beaucoup de décisions concernant les relations publiques.

Je suis extrêmement contrarié qu’ils m’attaquent parce que je m’adresse à la presse alors qu’ils participent à des tactiques bien plus sournoises, et que tous les membres de Core savent parfaitement ce qu’ils font, s’ils ne contribuent pas activement. »

Les partisans des gros blocs s’emparent rapidement de cette révélation. Le 7, la vidéo d’une présentation de Bram Cohen de janvier est retrouvée, dans laquelle on peut apercevoir le canal en question pendant un bref instant.

Il s’agit d’un canal sur le groupe Slack de Bitcoin Core qui est appelé « Dragons’ Den », en référence à l’émission de téléréalité britannique du même nom où des entrepreneurs présentent leurs idées à un jury de multimillionaires (les « dragons ») pour être financés. En janvier, ce canal comportait déjà 21 membres dont BashCo (modérateur de r/bitcoin), Chris Belcher (JoinMarket) et btcdrak (contributeur pour Bitcoin Core).

Le groupe Dragons’ Den est dédié à l’organisation de campagne de relations publiques (c’est-à-dire de propagande) par le trollage intensif et la diffusion de mèmes. Pour les dragons, il s’agit essentiellement de communiquer sur Twitter et sur les autres réseaux sociaux, de créer différents sites web soutenant leur cause et de dénigrer leurs adversaires.

En avril, l’idée d’un UASF est soutenue par ce groupe, qui commence à en faire une promotion agressive. Parmi les défenseurs les plus virulents, on peut notamment citer Samson Mow (Excellion), Francis Pouliot ou Rodolfo Novak (nvk). Samson Mow en particulier conçoit des casquettes UASF, qu’il met en vente publiquement le 22 avril sur la boutique de Denarium. Ces casquettes se retrouvent dans les divers évènements de la vie réelle regroupant des bitcoineurs, et témoignent d’un soutien fort des membres importants de la communauté.

Ces casquettes deviendront un symbole fort pour se remémorer la bataille menée.

Un autre enjeu sur lequels les partisans des petits blocs se concentrent est l’activation de SegWit sur le réseau Litecoin. En effet, la mise à niveau est intégrée au code de Litecoin Core depuis début 2017, et fait alors l’objet d’un signalement analogue par les mineurs (bien qu’il ne nécessite que 75 % du taux de hachage). C’est pourquoi son activation constitue un enjeu majeur : elle montrerait que la mise à niveau est à la fois sûre et désirable.

Le 9 avril, un utilisateur de Reddit propose de procéder à un UASF pour activer SegWit sur Litecoin. Comme sur Bitcoin, l’activation de SegWit est boudée par les mineurs : le signalement a commencé le 28 janvier et en est à sa cinquième période infructueuse.

En particulier, Jiang Zhuoer, PDG de la coopérative chinoise LTC1BTC dédiée au minage de litecoin, réunit suffisamment de taux de hachage pour bloquer SegWit. Également derrière la coopérative BTC.TOP sur Bitcoin, il a intérêt à montrer que les mineurs ont un poids sur la prise de décision.

Le 20 avril, il publie un article dans lequel il s’oppose à l’UASF, qu’il appelle « DASF » (Developer Activated Soft Fork), et demande à rencontrer Charlie Lee pour « prendre cette décision ensemble ». Dans l’article, qui concerne autant Bitcoin que Litecoin, il s’attriste du fait que Bitcoin Core refuse d’augmenter la taille de base des blocs :

« Si Core avait simplement inclus le code pour une future augmentation de la taille des blocs, ou même indiqué clairement dans sa feuille de route un plan pour rendre les blocs plus gros, alors nous aurions pu éviter ces multiples années de querelles intestines, nous aurions toujours une communauté et une industrie unies, et Bitcoin serait toujours en mouvement. »

Jiang Zhuoer, Why I Am Still Not Voting for Segwit, 20 avril 2017

Il dénonce également les attaques par déni de service que subissent les coopératives qui refusent de signaler SegWit.

Le lendemain, une table ronde a lieu (faisant écho à la table ronde de Hong Kong) entre les principaux mineurs chinois et Charlie Lee, au terme de laquelle les participants se mettent d’accord pour que SegWit soit activé par les mineurs et qu’une augmentation de la taille limite des blocs de Litecoin soit mise en place lorsque l’usage de la chaîne dépassera les 50 % de capacité.

SegWit est finalement verrouillé sur Litecoin le 27 avril, puis activé deux semaines plus tard, le 10 mai 2017. C’est une victoire pour les partisans de l’UASF, car la menace de cet UASF semble avoir porté ses fruits.

L’activation de SegWit sur Bitcoin

Tous ces évènements poussent la communauté à aller vers l’activation de SegWit, si possible en recherchant un compromis. Ainsi, le 31 mars 2017, Sergio Lerner propose SegWit2Mb, un projet d’implémenter dans le protocole le compromis de l’activation de SegWit et du doublement de la taille limite de base.

Le 23 mai 2017, durant la conférence Consensus 2017, les représentants des principales plateformes d’échange, des coopératives de minage majeures (83 % du taux de hachage) et de différents prestataires de services (portefeuilles, etc.) de l’écosystème se réunissent au sein d’une réunion confidentielle organisée par Barry Silbert du Digital Currency Group. Cette réunion aboutit à un accord, le « Bitcoin Scaling Agreement at Consensus 2017 », qui sera par la suite appelé l’accord de New York. Basé sur la proposition de SegWit2Mb de Sergio Lerner datant du 31 mars, cet accord engage les signataires à :

• Activer le soft fork Segregated Witness avec un seuil de signalement de 80 % de la puissance de calcul ;
• Activer un hard fork doublant taille limite des blocs dans les 6 mois.

Le projet est pris en charge par Jeff Garzik, un développeur historique de Bitcoin. Le 31 mai, le projet prend le nom SegWit2X. Il est développé au travers de l’implémentation btc1, un fork logiciel de Bitcoin Core.

L’accord prévoyait initialement de réaliser un nouveau signalement direct (via le bit 4), mais le BIP-91 de James Hilliard est rapidement préféré. Ce dernier inclut une compatiblité avec l’activation de SegWit classique ainsi qu’avec l’UASF : après un signalement de 80 % du taux de hachage (via le bit 4), le BIP-91 force le signalement de SegWit en rendant invalides tous les blocs qui ne signalent pas.

La situation au début de l’été 2017 est ainsi très complexe, comme le résume le schéma de Morgan Phuc ci-dessous :

Heureusement, tout se passe comme prévu et les mineurs suivent le plan. Le signalement pour le BIP-91 commence le 17 juillet 2017 ; ce dernier est verrouillé le 21 au bloc 476 784 et est activé 336 blocs plus tard, le 23 juillet.

L’UASF s’active le 1^er août 2017 sur les nœuds l’ayant implémenté, mais n’a aucun effet, puisque le BIP-91 impose déjà ses conditions. SegWit est finalement verrouillé le 9 août, et il est activé le 24 août au bloc 479 824.

Ainsi, l’activation de SegWit a été un lent et douloureux périple. Il est difficile d’estimer l’influence qu’a pu avoir l’User Activated Soft Fork, mais son rôle a été important, en dépit des risques non négligeables qu’il faisait peser sur la santé économique de Bitcoin. En définitive, l’UASF a constitué la première preuve que les mineurs ne possédaient aucun pouvoir sur la détermination du protocole.

Cependant, l’activation de SegWit n’a pas été la conclusion du débat sur la scalabilité. SegWit2X prévoyait en effet un doublement de la taille limite des blocs en novembre 2017, chose à laquelle les partisans se sont opposés avec les mêmes moyens que ceux mis en œuvre en faveur de l’UASF.

Pour écrire cet article, je me suis basé sur l’ouvrage The Blocksize War de Jonathan Bier.