BIP-110 : pourquoi son échec semble désormais inévitable

0
55

Le BIP-110 (Reduced Data Temporary Softfork, parfois désigné RDTS) est une proposition d’amélioration de Bitcoin visant à restreindre, pendant environ un an, l’inscription de données non financières sur la blockchain. Portée par le développeur pseudonyme de Dathon Ohm et soutenue par Luke Dashjr, cofondateur et CTO du pool de minage Ocean, elle cible en particulier les inscriptions Ordinals, les jetons BRC-20, le protocole Runes et, plus largement, les données arbitraires que les défenseurs de la proposition considèrent comme du spam.

Concrètement, le BIP-110 introduirait sept nouvelles règles de consensus : il limiterait la taille des nouveaux outputs à 34 octets (sauf les sorties OP_RETURN, plafonnées à 83 octets), restreindrait les insertions de données à 256 octets, et imposerait des contraintes sur certaines fonctionnalités liées à Taproot (annexes, control blocks, certains opcodes). Les UTXO créés avant l’activation resteraient définitivement exemptés de ces règles afin d’éviter de geler des fonds existants.

L’activation repose sur un soft fork activé par les utilisateurs (UASF), avec un seuil de signalement des mineurs abaissé à 55 %, contre 90-95 % pour les précédents soft forks de Bitcoin. Pour rappel, un soft fork est une mise à jour rétrocompatible — c’est-à-dire que le logiciel continue de fonctionner pour tout le monde — qui consiste à rendre les règles du réseau plus restrictives. Dans une mise à jour classique, on s’appuie sur les mineurs (ceux qui sécurisent le réseau en créant les blocs de transactions) : ils indiquent qu’ils sont prêts pour le changement en signalant leur accord, ce qui consiste à modifier un simple bit d’information dans l’en-tête de chaque bloc qu’ils découvrent. Un UASF (User-Activated Soft Fork) propose une alternative au signalement traditionnel des mineurs en transférant le pouvoir d’activation directement aux nœuds : ce sont eux qui fixent une date butoir et menacent les mineurs de rejeter leur travail s’ils ne collaborent pas.

Selon le plan des promoteurs du BIP 110, à partir du bloc 961 632 (début août 2026), les nœuds qui soutiennent la proposition commenceraient à rejeter les blocs des mineurs qui ne signalent pas le BIP-110, dans l’espoir de les contraindre à voter « oui » pour que leur travail soit accepté. Si cette pression permettait d’atteindre le seuil de 55 % de votes favorables sur une période de deux semaines, la proposition serait alors validée (verrouillée) au bloc 963 648. Après deux semaines supplémentaires de transition, les restrictions sur les données entreraient en vigueur au bloc 965 664 (autour du 1ᵉʳ septembre 2026), avant de s’éteindre automatiquement un an plus tard (après 52 416 blocs).

Un échec prévisible

Malgré son ambition, le BIP-110 bénéficie cependant d’un soutien extrêmement faible de la part des mineurs. Depuis le début du signalement au printemps 2026, le soutien mesuré est resté anecdotique — autour de 1 % à la mi-juillet 2026. Aucun grand pool de minage ne s’est rallié à la proposition : Foundry USA et AntPool n’ont pas bougé, tandis que F2Pool s’y est explicitement opposé. La quasi-totalité des blocs signalants provient d’Ocean, le pool cofondé par Luke Dashjr, un pool de taille modeste, non comparable aux géants du secteur, complété par quelques petits opérateurs indépendants.

Côté utilisateurs, Bitcoin Core, l’implémentation majoritaire du protocole, n’intégrera pas le BIP-110. Le seul soutien viendra des nœuds Knots qui ont activement configuré leur logiciel pour rejeter les blocs non signalants.

Par ailleurs, la proposition suscite une opposition franche de figures très influentes de l’écosystème comme Adam Back, Jameson Lopp, Peter Todd, Greg Maxwell ou encore l’éditeur des BIP ayant attribué son numéro à la proposition, Mark « Murch » Erhardt, qui a publiquement critiqué le contenu du projet, pointant du doigt des failles conceptuelles et un manque de rigueur dans la rédaction des spécifications du projet, tout en précisant que l’attribution d’un numéro de BIP relève d’une pure procédure administrative et ne vaut en aucun cas approbation.

Avec un soutien très faible des pools de minage comme des noeuds et une opposition presque unanime des leaders d’opinion, l’activation du BIP 110 sur la chaine principale semble aujourd’hui très improbable. Si les nœuds faisant tourner BIP-110 (principalement ceux basés sur Bitcoin Knots) commencent malgré tout à rejeter les blocs non signalants à l’échéance d’août, cela n’aboutira qu’à la création d’une chaîne minoritaire isolée vouée à disparaitre. L’immense majorité de l’écosystème (les nœuds Bitcoin Core, l’essentiel du hashrate, les plateformes d’échange et les portefeuilles) continuera de fonctionner sur la chaîne principale sans aucune interruption.

Et le spam ?

Néanmoins, si le BIP-110 est indiscutablement une proposition mal conçue, mal engagée et condamnée à l’échec en raison de sa méthode d’activation agressive, il n’en demeure pas moins que la problématique du « spam » sur la Timechain de Bitcoin est bien réelle et mérite une attention légitime.

Il convient toutefois de distinguer la nature de ce spam pour en comprendre le véritable danger. Le pire spam n’est pas celui qui contribue simplement au gonflement global de la taille de la blockchain (le stockage sur disque dur). En effet, l’évolution de ce stockage est physiquement plafonnée par la taille maximale des blocs (la limite théorique de 4 Mo liée à SegWit), ce qui rend cette croissance prévisible, linéaire et gérable. Le véritable péril réside plutôt dans l’explosion du nombre d’UTXO (Unspent Transaction Outputs).

Contrairement à l’historique de la blockchain qui peut être stocké sur un disque dur classique (HDD) bon marché, l’ensemble des UTXO actifs (l’« UTXO set ») doit être intégralement conservé dans la mémoire vive (RAM) ou sur des disques SSD par les nœuds du réseau afin de pouvoir valider en temps réel les nouvelles transactions. En multipliant de minuscules sorties non dépensées et inutilisables (les dust outputs créées par les protocoles de jetons ou d’inscriptions), ce spam sature l’UTXO set. Cela augmente drastiquement la configuration matérielle minimale requise pour faire tourner un nœud complet, menaçant à terme la décentralisation même du réseau en excluant les utilisateurs modestes. S’inquiéter de ce phénomène n’est donc pas une posture dogmatique, mais une nécessité technique essentielle pour éviter qu’un jour (même s’il est lointain) Bitcoin ne devienne un réseau validé uniquement par des serveurs professionnels et des institutions.

Quelles solutions ?

Face à ce défi, la communauté des développeurs privilégie l’ingénierie à la censure. Plusieurs solutions sont actuellement à l’étude pour accroître la résilience des nœuds domestiques sans restreindre arbitrairement l’usage de la Timechain. La piste la plus prometteuse est sans doute Utreexo, un projet d’accumulateur cryptographique qui permet de compresser la taille de l’UTXO set, déchargeant ainsi la mémoire vive des nœuds. En parallèle, des optimisations comme AssumeUTXO facilitent déjà la synchronisation rapide de nouveaux nœuds via des instantanés fiables, tandis que des propositions de nettoyage économique visent à faciliter la destruction ou le regroupement des micro-sorties (dust). C’est vraisemblablement par ces avancées technologiques et architecturales, plutôt que par des hard forks ou soft forks conflictuels, que Bitcoin préservera durablement sa décentralisation.

Sources

– Unchained Crypto — Saylor and Back Reject Bitcoin’s BIP-110 Fork as Deadline Nears With Almost No Miner Support
– Incrypted — Bitcoin Nears BIP-110 Deadline — Support for Upgrade Is Practically Nonexistent
– Journal du Coin — BIP-110 : Le fork qui menace de fracturer Bitcoin, et personne ne veut le signer
– Cryptoast — BIP-110 : La nouvelle tentative de Bitcoin Knots pour bannir les données non-monétaires
– CryptoSlate — Power struggle hits Bitcoin network over anti-spam proposal with claims of faked node support
– Bitfinex Blog — BIP-110 and Bitcoin’s High Bar for Consensus Change
– The Bitcoin Manual — What Is BIP-110?