BIP-110 explique : ce qu'un soft fork controverse revele sur le consensus de Bitcoin

La question sous le fork

BIP-110 est facile a ranger sous la longue dispute autour des Ordinals et des donnees arbitraires sur Bitcoin. Ce cadrage manque ce qui est vraiment en jeu. La proposition n'ajoute pas un filtre local que chaque operateur de noeud peut choisir. Elle change les regles de consensus qui decident quels blocs appartiennent a Bitcoin.

C'est un type de changement different. Un filtre anti-spam est une preference. Une regle de consensus est une definition. BIP-110 pose une question qui se situe au-dessus du debat sur les donnees : Bitcoin doit-il seulement verifier qu'une transaction est valide selon des regles neutres, ou les regles doivent-elles aussi interdire certains usages de l'espace dans les blocs ? Et de la premiere en decoule une seconde : jusqu'ou une minorite peut-elle aller pour imposer sa reponse preferee ?

Ceci est une analyse de ces questions et de la mecanique qui les rend urgentes ce mois-ci. CanoeBit ne prend pas position sur le prix de Bitcoin et ne formule aucune recommandation sur ce que quiconque devrait faire. Pour l'etat des lieux, le calendrier d'activation et le bug signale dans le client, voir l'actualite BIP-110 approche de la signalisation obligatoire.

Ce que BIP-110 restreint reellement

Pendant environ un an, soit 52 416 blocs, BIP-110 ajouterait sept regles de consensus. Les nouveaux scripts d'output seraient plafonnes a 34 octets, les outputs OP_RETURN etant autorises jusqu'a 83. Les data push et les elements witness servant d'arguments de script seraient limites a 256 octets. Les versions de witness et de Tapleaf non definies ne pourraient pas etre depensees, l'annex Taproot serait interdit, les control block seraient plafonnes a 257 octets, et OP_SUCCESS ainsi que les instructions OP_IF et OP_NOTIF executees seraient invalides dans Tapscript.

La nuance importante est que ces regles sont generales. Elles visent les techniques sur lesquelles reposent aujourd'hui les inscription, mais elles touchent largement Script, les donnees witness et plusieurs chemins de mise a niveau de Taproot. La specification elle-meme reconnait des cas etroits et experimentaux impliquant des transactions Taproot pre-signees, ou les fonds pourraient en theorie etre geles ou perdus, tout en prenant grand soin de proteger par grandfathering chaque piece confirmee avant l'activation.

La proposition n'est donc pas une propre "interdiction des Ordinals". C'est un durcissement large de ce a quoi peut ressembler une transaction Bitcoin valide, avec un petit risque residuel pour des usages legitimes mais non documentes. C'est un element a peser, non parce que le risque est grand, mais parce que personne ne peut enumerer chaque construction contractuelle deja en circulation.

Le steelman : pourquoi l'inquietude est legitime

La frustration derriere BIP-110 n'est pas deraisonnable, et il vaut la peine de l'exposer dans sa forme la plus forte avant de la demonter.

Les full node doivent telecharger et valider chaque bloc. Les scripts d'output non depenses vivent dans l'UTXO set, que les noeuds gardent sur une memoire rapide et ne peuvent pas elaguer. Les grandes inscription rivalisent avec les transactions monetaires pour l'espace rare dans les blocs, elles peuvent faire monter les frais des paiements ordinaires, et une partie du contenu integre est un materiel que les operateurs de noeud prefereraient ne pas heberger du tout. Si l'on croit que la premiere vocation de Bitcoin est d'etre de la monnaie, voir son espace dans les blocs se remplir de donnees qui pesent a jamais sur chaque noeud est un grief authentique.

Ce raisonnement est coherent. Le desaccord ne porte pas sur le fait que l'insertion de donnees a un cout. Il porte sur le fait qu'un changement de consensus temporaire et a seuil bas soit ou non le bon instrument pour y remedier.

Ou le raisonnement s'amincit

Deux problemes affaiblissent la proposition sur ses propres termes.

Le premier est economique. La conception originale de Satoshi contient deja un mecanisme anti-spam : les frais et une limite fixe a la taille du bloc. Quand l'espace dans les blocs se remplit, il devient couteux, et les usages qui n'apportent aucun retour monetaire tendent a etre exclus par le prix. Ce n'est pas de la theorie. Les vagues d'inscription se sont refroidies a plusieurs reprises a mesure que les frais montaient et que l'activite cessait de se financer elle-meme. Une regle de consensus qui rend seulement une methode plus difficile invite les donnees a se deplacer, non a disparaitre.

Le second probleme est pire, et c'est la que le remede pourrait nourrir la maladie. Si le stockage de donnees contigues dans les champs evidents est interdit, des acteurs determines peuvent repartir leurs charges sur de nombreux petits push ou les deguiser en donnees financieres ordinaires. Repandues sur de nombreux outputs, ces donnees peuvent finir dans l'UTXO set, la seule partie de la chaine que les noeuds ne peuvent pas elaguer. Dans l'effort pour tenir a l'ecart les donnees indesirables, le changement risque de les deplacer vers l'endroit le plus couteux pour les stocker. La proposition ne le nie pas. Elle soutient que la fragmentation et le cout plus eleve envoient tout de meme un message. C'est un point reel, mais c'est un message, pas une solution.

Comment une scission de la chaine se formerait

La mecanique de la scission est simple, et c'est en partie pourquoi le risque est credible. A partir du bloc 961 632, les noeuds BIP-110 et les noeuds Bitcoin ordinaires appliquent des regles differentes. Si un bloc active le bit 4, les deux cotes peuvent l'accepter. S'il ne le fait pas, les noeuds ordinaires le tiennent toujours pour valide, tandis que les noeuds BIP-110 le rejettent.

A cet instant, les deux groupes cessent de suivre la meme chaine. Avec l'ecrasante majorite du hashrate qui ne signale pas, la chaine Bitcoin ordinaire continuerait presque sans perturbation, tandis que les noeuds BIP-110 attendraient qu'un des rares mineurs qui signalent produise un bloc sur leur branche. Une seconde chaine peut exister sur le plan technique. Savoir si elle compte sur le plan economique est une autre question, et les donnees actuelles ne suggerent pas qu'elle compterait.

Deux choix de conception aiguisent le danger. Il n'existe aucune protection replay generale, si bien qu'une transaction peut etre valide sur les deux chaines a la fois, un danger que les forks passes ont demontre lorsque les utilisateurs deplacent leurs pieces dans les premieres heures. Et le client d'activation lui-meme porte le bug de mise a jour reproductible documente dans le rapport BlockSlop, ou deux noeuds executant les memes regles peuvent se retrouver sur des chaines differentes selon l'historique de leur repertoire de donnees. Un changement de consensus dont le propre client ne peut garantir que des noeuds identiques s'accordent n'est pas mur.

Le nombre qui decide de tout

Le seuil de signalisation est le centre silencieux de cette dispute. Taproot, une mise a niveau non controversee et purement additive, a ete deploye avec un seuil des mineurs de 90 pour cent. BIP-110, qui supprime des capacites existantes et peut declencher une scission, fixe sa barre a 55 pour cent.

Cette inversion est parlante. Le changement le plus risque demande moins d'accord que n'en demandait celui le moins risque. La defense de la proposition est qu'une regle temporaire, d'un an, n'a pas besoin d'une disponibilite quasi universelle. Lue de maniere structurelle, cependant, la barre basse ressemble moins a une marge de securite qu'a une tentative de franchir une barre qu'un soutien large ne parvient pas a atteindre seul. Et meme 55 pour cent n'est pas proche : la signalisation est restee a quelques points de pourcentage pendant tout le deploiement.

Ici l'expression "signalisation obligatoire" invite a un contresens. Elle n'oblige pas les mineurs a activer quoi que ce soit. Elle signifie seulement que les noeuds BIP-110 rejetteront les blocs non signalants a partir de cette hauteur. Si la plupart des mineurs continuent de produire des blocs ordinaires, ces blocs restent valides pour le reste du reseau, et ce sont les noeuds BIP-110 qui restent en arriere. Un soft fork active par les utilisateurs peut faire pression sur les mineurs, mais seulement quand une majorite economique credible d'exchanges, de depositaires, de wallets et d'utilisateurs refuse tout sauf la chaine la plus stricte. Aucune majorite de ce type n'est visible pour BIP-110.

Une chaine qui avancerait au ralenti

Supposons qu'une chaine BIP-110 distincte se forme et conserve le petit hashrate qui signale aujourd'hui, environ un et demi pour cent du reseau. Elle heriterait de la difficulte actuelle de Bitcoin avec une fraction de la puissance necessaire pour y repondre.

L'arithmetique est impitoyable. Les blocs arriveraient en moyenne toutes les onze heures environ au lieu de toutes les dix minutes, pres de 68 fois plus lentement. Bitcoin ne rajuste la difficulte que tous les 2 016 blocs, et a ce rythme atteindre le premier ajustement prendrait de l'ordre de 950 jours, environ deux ans et demi. Jusque-la, la chaine produirait des blocs occasionnels, pas un reseau de paiement fonctionnel. Une chaine minoritaire est techniquement possible. Une chaine utilisable, avec ces chiffres, ne l'est pas.

La lecture de CanoeBit, et ou elle tombe

Notre lecture structurelle est la suivante : BIP-110 a bien plus de chances de produire une chaine minoritaire petite, lente et largement ignoree que de changer Bitcoin, et sa conception d'activation substitue l'affirmation au consensus. Repeter qu'une proposition a le consensus ne le cree pas. Le consensus emerge quand des utilisateurs, des mineurs, des developpeurs et des entreprises independants convergent volontairement vers des regles, et cette convergence n'est pas visible ici.

Parce qu'une analyse honnete nomme ses propres conditions d'echec, voici les notres. Cette lecture tomberait si une part significative du hashrate migrait vers la branche BIP-110, ou si de grands exchanges, depositaires et fournisseurs de wallets s'engageaient a ne traiter que la chaine la plus stricte comme Bitcoin. Dans ce cas, une veritable majorite economique existerait et le calcul changerait. Elle tomberait aussi si les faibles chiffres de signalisation etaient mal mesures et que la disponibilite reelle etait bien plus elevee que ce que montrent les tableaux de bord. Aucune de ces conditions n'est evidente aujourd'hui, mais toutes deux sont observables, et toutes deux sont ce que nous surveillerions pour savoir que nous avions tort.

Le point plus restreint tient quelle que soit l'issue du fork. Un debat sur l'espace dans les blocs et le stockage de donnees vaut la peine d'etre mene. Le trancher par un changement de consensus construit a la hate et a seuil bas, applique par un client dote d'un bug de divergence connu, est une mauvaise maniere de le mener.