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 est la contre-attaque de ce camp-là. Proposé fin 2025, c’est un soft fork temporaire qui rebride, 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 cache 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 change, comment il s’active, et pourquoi il déclenche une telle bataille — les deux camps sur la table, à toi de te faire ton opinion.

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 s’active — et pourquoi c’est 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.

C’est dans les paramètres d’activation de BIP-110 que se niche la controverse :²

• Seuil de 55 % (1109 blocs sur 2016) pour le verrouillage anticipé — bien en deçà des 95 % exigés pour les soft-forks historiques comme SegWit ou Taproot.
• Début du signalement le 1ᵉʳ décembre 2025, hauteur limite d’activation au bloc 965 664 (autour de septembre 2026).
• Durée active de 52 416 blocs, soit environ un an, après quoi les règles s’éteignent.

Ce seuil abaissé n’est pas un détail. Il rapproche BIP-110 de 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.

C’est exactement 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 ?

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ésume l’urgence dans des termes sans nuance : selon lui, sans ce garde-fou, « 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ésume 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 comptent parmi les opposants notables.⁵

Ce que le résultat raconte déjà

À l’heure où ces lignes sont écrites, le verdict penche nettement : le signalement des mineurs est quasi nul, très loin des 55 % requis, et l’échéance approche.⁶ Quelle que soit l’issue, l’épisode aura montré une chose : 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. C’est lent, c’est frustrant pour ceux qui veulent agir vite, mais c’est précisément ce qui rend les règles de Bitcoin difficiles à changer… par quiconque.

À retenir

• BIP-110 est un soft-fork temporaire qui rebride 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 ».
• Le grandfathering protège l’existant : aucune pièce créée avant l’activation ne devient indépensable, et les règles expirent après ~1 an.
• Son seuil d’activation à 55 % (contre 95 % d’usage) déplace le débat sur le terrain de la gouvernance : qui décide des règles de Bitcoin ?
• Mi-2026, l’activation échoue faute de soutien des mineurs — illustrant, quel que soit ton avis sur le fond, le très haut niveau de consensus requis pour changer Bitcoin.