Un paquet de règles pour réduire les données, mais à quel prix ?
Le BIP 110, désormais marqué comme « Complete » au titre du BIP 3 depuis le 25 juin, agrège sept restrictions temporaires dans le but de limiter l’emprise de données arbitraires au sein des transactions Bitcoin. L’initiative vise à contenir la taille de certains scripts, à réduire la latitude autour des blocs de contrôle de Taproot et à bloquer les dépenses utilisant des versions de témoin non définies. Les partisans du texte avancent un bénéfice immédiat : alléger les coûts pour les opérateurs de nœuds et préserver l’espace en bloc prioritairement pour des paiements.
Cette approche séduit une frange de la communauté soucieuse d’un coût d’exploitation maîtrisé et d’une capacité on-chain moins saturée par des usages non monétaires. Mais elle soulève une question qui dépasse la technique : où placer le curseur entre efficacité et neutralité du protocole ?
La charge de Michael Saylor contre un « softfork » ciblé
Sur X, Michael Saylor, président exécutif de Strategy (ex‑MicroStrategy), appelle à rejeter le texte. Selon lui, le « paquet » sacrifie la neutralité au profit d’un gain modeste sur le volume de données. Il fustige l’idée de recourir à des règles de consensus pour trier des transactions jugées légitimes par leur rentabilité mais distinctes par leur finalité.
« Reduced Data Temporary Softfork »
C’est sous cette désignation que l’orientation du BIP 110 est présentée. Saylor considère qu’elle institue une pente glissante : le protocole ne devrait pas décider a priori de l’usage des transactions. Il préfère des frais de marché et des politiques de relais volontaires, plutôt qu’un durcissement du consensus qui exclurait certains formats.
Un seuil d’activation contesté et un précédent redouté
Au cœur des critiques figure un mécanisme de signalement minier à 55 %. Pour Saylor, un tel niveau paraît trop bas au regard d’un changement potentiellement clivant. Il y voit un risque de validation hâtive, sans large assentiment de la communauté. Le texte, bien que finalisé par son auteur, ne constitue pas une preuve d’adhésion générale.
Autre point délicat : la proposition intégrerait une protection pour les UTXO créés avant activation. Si cette clause vise à rassurer en limitant les effets de bord, Saylor estime qu’elle ne répond pas au problème fondamental du précédent : une fois ouverte, la voie à des exclusions par consensus pourrait s’élargir à d’autres usages.
Objectifs partagés, méthodes irréconciliables
Un paradoxe traverse le débat. Le dirigeant reconnaît l’objectif de préserver les opérateurs de nœuds, de maintenir des frais abordables et de dissuader l’usage de Bitcoin comme solution générique de stockage de données. Mais il juge que le BIP 110 en vient à écarter des transactions valides et rémunératrices sans mesurer clairement le coût réel que ces volumes imposent au réseau. En filigrane, c’est l’arbitrage entre le marché (priorisation par les frais) et la norme (règles de consensus) qui s’invite.
Conséquences possibles pour l’écosystème
Si ce softfork devait avancer, les impacts toucheraient plusieurs maillons de la chaîne :
- Nœuds : réduction visée de la charge de stockage et de validation, au prix d’une politique plus normative.
- Mineurs : ajustement du mix de transactions en bloc, avec un filtre accru sur certains scripts ou témoins.
- Utilisateurs et services : incertitude sur la pérennité de cas d’usage non monétaires et sur la frontière entre « données utiles » et « données arbitraires ».
À ce stade, aucune consolidation communautaire large n’est établie dans la source. Le statut « Complete » signifie que l’auteur de la proposition la considère finalisée, non qu’elle ait été adoubée par l’ensemble des acteurs. En d’autres termes, le débat reste ouvert.
Un test de neutralité pour Bitcoin
Au-delà du dossier technique, la controverse interroge la gouvernance implicite de Bitcoin : faut‑il contraindre au niveau du consensus pour contenir des usages jugés indésirables, ou laisser le marché des frais et les politiques de relais orienter l’activité ? En l’état, l’issue dépendra de la capacité des développeurs, mineurs et opérateurs de nœuds à s’accorder sur la balance entre neutralité et efficience. Toute conclusion hâtive, avec un seuil de 55 % seulement, risque d’enflammer une controverse qui touche à l’ADN du protocole.
| Élément | Détail |
|---|---|
| Objet | BIP 110 (paquet de 7 règles) |
| But affiché | Réduire les données arbitraires on‑chain |
| Méthode | Restrictions temporaires de consensus |
| Statut | « Complete » (BIP 3), 25 juin |
| Seuil de signalement | 55 % de mineurs |
| Principale critique | Atteinte à la neutralité, précédent normatif |
Pour l’heure, la balle reste dans le camp des développeurs et des opérateurs de réseau. La décision, quelle qu’elle soit, servira de référence pour les arbitrages futurs entre liberté d’usage et discipline protocolaire.
