BIP-110 : Bitcoin doit-il filtrer les données ? Anatomie d'une bataille de consensus

En octobre 2025, une ligne de configuration a mis le feu aux poudres. Avec sa version 30, Bitcoin Core — le logiciel de nœud le plus répandu — a relevé la taille de données autorisée dans une sortie OP_RETURN de 83 octets à 100 000 octets.¹ Pour ses développeurs, c’était acter une réalité : refuser de relayer des transactions que les mineurs incluent de toute façon ne fait que pousser les utilisateurs vers des canaux détournés. Pour ses opposants, c’était ouvrir grand la porte au « spam » de données non financières.

BIP-110 a été la contre-attaque de ce camp-là. Proposé fin 2025, c’était un soft fork temporaire qui devait rebrider, au niveau du consensus, la quantité de données arbitraires qu’on peut inscrire dans une transaction. Derrière la question technique — combien d’octets, quels scripts — s’en cachait une bien plus lourde, celle qui divise réellement Bitcoin : qui a le droit de changer ses règles ?

Cet article n’a pas de camp. Il explique ce que BIP-110 changeait, comment il devait s’activer, pourquoi il a déclenché une telle bataille — et comment elle s’est terminée.

D’où vient la bagarre

Le problème : des données qui n’ont rien à faire là ?

Bitcoin sert d’abord à transférer de la valeur. Mais sa blockchain est aussi, techniquement, un espace de stockage : on peut y glisser des données qui n’ont rien de monétaire. Le débat n’est pas nouveau, mais il a changé d’échelle début 2023 avec le protocole Ordinals et ses « inscriptions », qui gravent images, textes et « jetons » BRC-20 directement dans la partie témoin des transactions Taproot.

Le reproche des puristes : ces usages encombrent la blockchain, font monter les frais pour les paiements, et surtout gonflent l’UTXO set — la mémoire que chaque nœud doit conserver pour valider les transactions. Plus cette mémoire grossit, plus faire tourner un nœud coûte cher, et plus la décentralisation — la capacité de M. Tout-le-monde à vérifier lui-même le réseau — s’érode.

Le contre-argument, tout aussi ancien : une transaction qui paie les frais du marché a le droit d’exister. Filtrer selon le contenu, c’est décider subjectivement de ce qui est un « bon » ou un « mauvais » usage de Bitcoin — une pente que beaucoup jugent contraire à sa nature sans permission.

L’étincelle : Core lève la limite

Pendant des années, Bitcoin Core limitait par défaut les données d’un OP_RETURN à environ 80 octets. Ce n’était pas une règle de consensus, seulement une politique de relais — une convention sur ce que le logiciel accepte de propager. En 2025, après un long débat, les mainteneurs de Core ont décidé de la lever dans la v30, portant le plafond par défaut à 100 000 octets.¹

Ce choix a cristallisé une rivalité qui couvait entre deux implémentations de nœud :

• Bitcoin Core, l’implémentation historique et majoritaire, qui a assoupli sa politique ;
• Bitcoin Knots, le fork plus restrictif maintenu par Luke Dashjr, qui filtre davantage les données non financières.

BIP-110 est né dans ce contexte, et c’est Knots qui embarque son support. La « guerre Core contre Knots » est le décor de toute l’affaire.

Ce que BIP-110 change techniquement

Officiellement, BIP-110 s’appelle « Reduced Data Temporary Softfork » (soft-fork temporaire de réduction des données). Il a été publié le 3 décembre 2025 sous le pseudonyme Dathon Ohm, avec Luke Dashjr crédité pour le travail de rédaction et de conseil.² Sa paternité exacte est d’ailleurs contestée dans la communauté.

Son abstract est explicite : « limiter temporairement la taille des champs de données au niveau du consensus, afin de corriger des incitations distordues […] et de recentrer les priorités sur l’amélioration de Bitcoin en tant que monnaie ».²

Concrètement, il ajoute sept règles qui rendent invalides certaines constructions — sur les sorties nouvellement créées après activation :

1. Une sortie dont le script fait plus de 34 octets devient invalide (sauf OP_RETURN, plafonné à 83 octets). 34 octets, c’est précisément la taille des adresses usuelles (Taproot, SegWit) : les paiements normaux passent, les scripts « chargés » non.
2. Les données poussées (OP_PUSHDATA) et les éléments de témoin de plus de 256 octets deviennent invalides (contre 520 auparavant), sauf le redeemScript d’un P2SH.
3. Dépenser une version de témoin ou de tapleaf encore indéfinie devient invalide (en créer une reste permis).
4. Les transactions utilisant l’annexe Taproot (un champ pour l’instant inutilisé) sont rejetées.
5. Un control block Taproot de plus de 257 octets devient invalide — ce qui plafonne l’arbre de scripts à 128 feuilles.
6. Les Tapscripts contenant un opcode OP_SUCCESS (réservé aux futures évolutions) deviennent invalides.
7. Les Tapscripts exécutant OP_IF / OP_NOTIF (les branchements conditionnels) sont rejetés.

Les quatre dernières règles visent surtout à contraindre les scripts Taproot élaborés qui servent à empaqueter de grosses données. Pas besoin de retenir chaque ligne : l’idée d’ensemble est de remettre un plafond bas sur ce qu’une transaction peut transporter comme données, tout en laissant intacts les usages monétaires.

La garde-fou : le grandfathering

Un point rassure tout le monde, y compris les opposants : rien n’est gelé. Chaque règle exempte les entrées qui dépensent des pièces créées avant la date d’activation. Autrement dit, aucun UTXO existant ne devient soudain indépensable, quelle que soit la forme sous laquelle il a été créé.² La transition se fait sans casser l’existant.

Et comme le soft-fork est temporaire, ses restrictions expirent automatiquement environ un an après leur entrée en vigueur. Luke Dashjr le présente lui-même comme une rustine : « Ce n’est pas censé être une solution idéale, juste suffisante et très simple, pour gagner du temps et concevoir une solution à long terme. »³

Comment ça devait s’activer — et pourquoi c’était le vrai sujet

Un changement de consensus ne s’impose pas d’en haut. Traditionnellement, on utilise le signalement des mineurs : ils indiquent dans les blocs qu’ils sont prêts à appliquer la nouvelle règle, et au-delà d’un seuil, elle se verrouille (lock-in) puis s’active.

BIP-110 reprenait ce mécanisme, avec trois écarts lourds de conséquences :²

• Un seuil de 55 % (1 109 blocs sur 2 016) pour le verrouillage — bien en deçà des 95 % exigés pour les soft-forks historiques comme SegWit ou Taproot.
• Aucun délai d’expiration. Un déploiement classique qui n’atteint pas son seuil finit simplement par échouer, et rien ne change. Celui-ci n’avait pas de sortie de ce genre : il devait s’activer au plus tard au bloc 965 664 (début septembre 2026), avec ou sans les mineurs.
• Une période de signalement obligatoire, du bloc 961 632 au bloc 963 647 (août 2026). Pendant cette fenêtre, les nœuds BIP-110 rejetaient tout bloc qui ne signalait pas son soutien.

Ce dernier point change tout. Si les mineurs ne suivaient pas, BIP-110 ne pouvait pas « échouer proprement » : ses nœuds allaient refuser les blocs de la quasi-totalité du réseau, et donc se retrouver seuls sur leur propre branche. C’est la logique UASF — l’idée que ce sont les utilisateurs qui font tourner un nœud, et non les mineurs, qui décident in fine des règles. Le précédent fondateur est BIP-148, en 2017, qui avait débloqué l’activation de SegWit en menaçant de rejeter les blocs des mineurs récalcitrants. Mais BIP-148 avait été suivi par une large part de l’économie ; la question était de savoir si BIP-110 le serait.

C’est là que le débat technique devient un débat de pouvoir : à partir de quel niveau d’accord a-t-on le droit de modifier les règles que tout le monde doit suivre, et que se passe-t-il quand une minorité décide de les appliquer seule ?

Ce qui s’est passé

Un seul pool signale

Le signalement est resté marginal jusqu’au bout. Sur la dernière période de 2 016 blocs avant la fenêtre obligatoire (blocs 959 616 à 961 631), 51 blocs ont signalé leur soutien, soit 2,53 % — pour 55 % requis.⁴ Et ces 51 blocs viennent tous d’un seul pool : OCEAN, cofondé par Luke Dashjr, l’inspirateur de la proposition. On peut le vérifier sur la blockchain : OCEAN a miné 69 blocs sur la période, dont 51 signalaient le bit de BIP-110. Même chez OCEAN, donc, plus d’un quart des blocs ne signalaient pas — ses mineurs choisissent eux-mêmes leurs gabarits de bloc, et certains ont refusé.

Le 8 août, la chaîne se scinde

Le 8 août 2026 à 19 h 35 UTC, AntPool mine le bloc 961 632, le premier de la fenêtre obligatoire, sans signaler BIP-110.⁵ Le reste du réseau l’accepte. Les nœuds BIP-110 le rejettent. À cet instant précis, la chaîne se scinde en deux : d’un côté Bitcoin, qui continue ; de l’autre, une branche minoritaire qui n’accepte que des blocs signalants.

Sur cette branche, un groupe de mineurs appelé Roughnecks, passé par OCEAN, mine un bloc 961 632 concurrent, puis un 961 633. Puis plus rien, ou presque. Huit heures plus tard, la branche BIP-110 en est toujours à deux blocs ; la chaîne principale en a ajouté 48.⁵

Pourquoi la branche a-t-elle calé si vite ? Pour une raison purement mécanique, qu’on détaille dans Le minage Bitcoin, en détail : la difficulté. Une branche qui se sépare hérite de la difficulté de la chaîne entière, calibrée pour une puissance de calcul colossale, et elle ne peut la réajuster qu’après 2 016 blocs. Même si toute la puissance qui signalait (2,53 %) avait suivi, la branche aurait trouvé en moyenne un bloc toutes les six heures et demie, et mis plus d’un an et demi à atteindre son premier ajustement. Avec moins de puissance encore, elle s’est figée.

OCEAN fait marche arrière

Le pool qui portait la proposition a dû gérer les dégâts. Une erreur de configuration avait dirigé une partie de sa puissance de calcul vers la branche BIP-110 pendant environ 18 heures, y compris pour des mineurs qui ne l’avaient pas choisie ; OCEAN s’est engagé à les dédommager, à hauteur d’environ 0,3 BTC.⁶ Dès le 9 août, son site affichait un bandeau annonçant le retour au travail « non-BIP110 » sur son point d’accès par défaut, avec un site séparé pour les mineurs voulant continuer sur la branche.⁶

Le 29 août, OCEAN a cessé tout soutien à la branche BIP-110, en annonçant qu’il ne soutiendrait aucun hard fork qui en découlerait. Il a précisé qu’aucune récompense minée sur cette branche n’avait jamais atteint les 100 confirmations nécessaires pour être dépensée.⁶

Les conséquences pour les acteurs

• Le BIP est clos. Le 10 août, BIP-110 passe au statut Closed dans le dépôt officiel des propositions, avec cette mention : « à la suite d’une scission de chaîne au minage bloqué ».⁷
• Luke Dashjr perd son rôle d’éditeur. Le même jour, sur une motion déposée par le développeur Mark Erhardt pour conflit d’intérêts, il est retiré des éditeurs des BIP, qu’il occupait depuis des années. Il dénonce un « abus de pouvoir ».⁸
• Luke Dashjr quitte OCEAN. Après un congé annoncé mi-août, il quitte le pool fin août, d’un commun accord ; la maison mère rachète ses parts, et il annonce une nouvelle structure de minage, Convoy.⁹

Le camp Knots change de chaîne

Les partisans de BIP-110 n’ont pas renoncé. Constatant que les mineurs existants ne les suivraient pas, ils ont choisi de s’en passer : changer l’algorithme de preuve de travail de leur branche, pour que les machines SHA-256 du réseau Bitcoin ne puissent plus y miner.

Le 30 août 2026, la branche produit son premier bloc en BLAKE2b, à la hauteur 961 640.¹⁰ Bitcoin Knots intègre ce changement dans sa version 29.4.1, publiée le 2 septembre, qui active en même temps les règles de BIP-110.¹¹ Ce n’est plus un soft fork : c’est un hard-fork, et la branche est désormais une chaîne à part, avec son propre algorithme, ses propres mineurs et ses propres règles. Ses promoteurs la présentent comme la continuation légitime de Bitcoin ; pour le reste du réseau, c’est une nouvelle chaîne qui partage simplement l’historique d’avant le 8 août.

Le pari de « licencier les mineurs » a vite rencontré une limite. Des machines spécialisées en BLAKE2b existaient déjà — conçues pour d’autres cryptomonnaies — et leurs opérateurs se sont mis à miner la nouvelle chaîne, sans en partager le projet. Les notes de version suivantes de Knots les qualifient d’attaquants et durcissent les règles en conséquence : en septembre, les bitcoins nouvellement minés deviennent indépensables pendant 45 jours ; fin octobre, pendant 180 jours, et ce jusqu’à l’expiration prévue des règles de BIP-110, en septembre 2027.¹¹

Enjeux et risques : les deux camps

Pour BIP-110

• Préserver Bitcoin comme monnaie. Recentrer l’espace de bloc sur les paiements, plutôt que sur des données arbitraires qui font grimper les frais.
• Protéger la décentralisation. Contenir la croissance de l’UTXO set et du coût d’un nœud, pour que vérifier le réseau reste à la portée du plus grand nombre.
• Une intervention minimale et réversible. Soft-fork temporaire, avec grandfathering : on ne gèle rien, on ne casse rien, et ça s’éteint tout seul.

Luke Dashjr résumait l’urgence dans des termes sans nuance : selon lui, « si BIP-110 échoue, Bitcoin échoue avec lui », le réseau risquant à ses yeux de devenir indistinguable d’une monnaie numérique de banque centrale.¹²

Contre BIP-110

• Un dangereux précédent. Filtrer selon le contenu d’une transaction, c’est décider subjectivement de ce qui est un usage légitime — un glissement vers la censure que Bitcoin est censé rendre impossible.
• Invalider des transactions payantes. Michael Saylor résumait l’objection : la proposition « transforme un différend sur le spam en un changement de consensus qui invaliderait certaines transactions actuellement valides et payantes ».¹³
• Le risque de scission. Activer un changement contesté sans large accord fait planer la menace d’un chain split — deux chaînes, deux monnaies — comme lors des guerres de la taille des blocs en 2017. Michael Saylor comme Adam Back comptaient parmi les opposants notables.¹³

Ce que l’issue raconte

Le risque de scission s’est réalisé, mais pas comme ses opposants le craignaient. Il n’y a pas eu deux chaînes rivales au coude-à-coude : la branche minoritaire a calé en quelques blocs, et le réseau a continué sans à-coup visible pour l’immense majorité des utilisateurs. Les deux lectures de l’épisode restent pourtant irréconciliables. Pour la plupart des acteurs, c’est un UASF qui a échoué faute d’adhésion. Pour le camp Knots, ce sont les mineurs qui ont refusé une règle voulue par les nœuds, et l’algorithme BLAKE2b est la réponse.

Une chose ressort, quel que soit ton avis sur le fond : sur Bitcoin, aucune minorité, fût-elle très motivée, ne peut imposer un changement de règles sans emporter une large adhésion — mineurs, nœuds, entreprises, utilisateurs. Elle peut, en revanche, partir avec ses propres règles. C’est lent, c’est brutal, mais c’est précisément ce qui rend les règles de Bitcoin difficiles à changer… par quiconque.

La question de fond, elle, n’est pas réglée : la place des données non financières dans les blocs reste débattue. Le prochain changement de consensus discuté, BIP-54 (Consensus Cleanup), est d’une tout autre nature — des corrections techniques ciblées, sans rapport avec les données.

À retenir

• BIP-110 était un soft-fork temporaire destiné à rebrider les données arbitraires dans les transactions Bitcoin : sorties ≤ 34 octets, OP_RETURN ≤ 83 octets, pushes ≤ 256 octets, et plusieurs restrictions sur les scripts Taproot.
• Il est né en riposte à Bitcoin Core v30 (octobre 2025), qui avait relevé la limite d’OP_RETURN de 83 à 100 000 octets — au cœur de la rivalité « Core contre Knots ».
• Son activation ne pouvait pas échouer proprement : seuil de 55 %, pas de délai d’expiration, et signalement obligatoire à partir du bloc 961 632.
• Seul OCEAN a signalé (2,53 % des blocs). Le 8 août 2026, les nœuds BIP-110 se sont séparés du réseau ; leur branche a calé en quelques blocs, et le BIP a été clos.
• Fin août, le camp Knots a relancé sa branche avec une preuve de travail BLAKE2b : c’est désormais une chaîne distincte de Bitcoin, que suit Bitcoin Knots depuis sa version 29.4.1.