Une proposition technique qui divise l'écosystème Bitcoin
Le BIP‑110 (Reduced Data Temporary Softfork) vise à limiter, pendant environ un an, l'inscription de données non financières sur la blockchain Bitcoin. Portée par le développeur pseudonyme Dathon Ohm et soutenue par le CTO du pool Ocean, Luke Dashjr, la proposition cible explicitement les inscriptions Ordinals, les jetons BRC‑20, le protocole Runes et, plus largement, ce que ses partisans qualifient de spam de données arbitraires.
Les mesures concrètes proposées
Sur le plan technique, le BIP‑110 prévoirait l'introduction de règles de consensus restrictives :
- taille maximale des nouveaux outputs limitée à 34 octets (sauf OP_RETURN) ;
- plafond des sorties OP_RETURN à 83 octets ;
- restriction des insertions de données à 256 octets ;
- contraintes supplémentaires sur certaines fonctionnalités liées à Taproot (annexes, control blocks, opcodes ciblés).
| Élément | Valeur proposée |
|---|---|
| Durée prévue | ~1 an (temporaire) |
| Bloc d'activation | 961 632 (début août 2026) |
| Seuil de signalement mineurs | 55 % |
| Seuil usuel soft forks | ~90–95 % |
Un mécanisme d'activation politiquement chargé : l'UASF
Les auteurs ont choisi un User‑Activated Soft Fork (UASF) pour forcer l'adoption : au lieu d'attendre une large coordination des mineurs, ce sont les nœuds utilisateurs qui définissent une date d'entrée en vigueur et menacent de rejeter les blocs ne respectant pas les nouvelles règles. Historiquement, les UASF sont des leviers puissants mais risqués : ils peuvent provoquer des scissions si une part importante de l'infrastructure (mineurs, services d'échanges, validateurs commerciaux) refuse de suivre.
Pourquoi l'échec paraît inévitable
Plusieurs éléments convergent vers un rejet probable du BIP‑110. D'abord, la réduction du seuil de signalement à 55 % apparaît comme une tentative de court‑circuiter les pratiques de gouvernance habituelles et suscite une forte opposition idéologique chez les acteurs attachés à la neutralité maximale du registre. Ensuite, la communauté technique a exprimé des doutes sur la sécurité opérationnelle et la compatibilité avec des usages légitimes des données (archives, preuves, services layer‑2). Enfin, les mineurs et opérateurs d'infrastructure, moins enclins à subir une perturbation, ont peu d'incitations immédiates à se rallier à une mesure perçue comme coercitive.
Conséquences possibles et enjeux pour les services
Si l'initiative échouait, elle renforcera le principe selon lequel les changements profonds du protocole Bitcoin nécessitent une large coordination plutôt que des coups de force. En revanche, si malgré tout une fraction suffisante de nœuds l'activait, le réseau pourrait connaître des fragmentations temporaires, des rejets de blocs, et des coûts accrus pour les services afin de s'adapter aux nouvelles règles — ou au contraire pour maintenir la compatibilité avec la version précédente.
Concrètement, les développeurs d'applications, les portefeuilles et les services d'hébergement doivent surveiller les indicateurs d'activation et tester la résilience de leurs chaînes de validation. Les détenteurs d'actifs et les opérateurs d'applications basées sur Ordinals, BRC‑20 ou Runes font face à une incertitude opérationnelle qui pèse sur la valeur d'usage et, potentiellement, sur la liquidité de ces tokens.
Vers quelle gouvernance ?
La controverse autour du BIP‑110 réouvre la question de la gouvernance technique sur Bitcoin : faut‑il préserver un registre aussi permissif que possible, au risque d'y voir proliférer des usages jugés indésirables, ou bien imposer des limitations au nom d'une « propreté » du protocole ? La réponse n'est pas que technique : elle est politique, économique et normative, et elle continuera d'alimenter les débats au sein de la communauté mondiale.
