Lorsqu’une transaction unique de 66 ko est inscrite sur la blockchain Bitcoin, elle ne se limite pas à contenir une image : elle constitue un défi technique à l’encontre d’un protocole proposé. Fin février 2026, le débat autour des données que le réseau Bitcoin doit stocker s’est déplacé d’arguments idéologiques vers une confrontation directe au niveau du code. Le développeur slovaque Martin Habovštiak, à travers une preuve de concept ingénieuse, a intégré un fichier image TIFF dans la blockchain Bitcoin au sein d’une seule transaction continue. Ce geste a permis de tester directement les limites réglementaires défendues par les partisans de la proposition BIP-110, notamment ceux proches de Bitcoin Knots. Avec un cours du Bitcoin à 66 311 $ le 2 mars 2026, le bras de fer technique persistant entre prévention du spam et résistance à la censure semble redéfinir la logique fondamentale de l’écosystème crypto.
Aperçu de l’événement : une expérimentation d’intégration de données « propre »
Le 27 février 2026, Martin Habovštiak, mainteneur de la bibliothèque Rust Bitcoin, a mené une démonstration technique que de nombreux membres de la communauté ont jugée provocatrice. Il a inscrit de façon permanente une image TIFF de 66 ko sur la blockchain via une transaction unique.
Ce qui distingue cette transaction, ce n’est pas son contenu, mais la méthode employée. Habovštiak a précisé que la transaction n’utilisait aucune des principales instructions de portage de données visées par la proposition BIP-110 :
- Absence d’OP_RETURN : Cet opcode, couramment utilisé pour stocker des données arbitraires dans les transactions, est la cible principale de BIP-110, qui propose de le limiter à 83 octets.
- Non-recours à Taproot : La transaction s’appuie sur SegWit v0, sans utiliser les scripts Taproot.
- Pas d’OP_IF : Ceci permet d’éviter la complexité des instructions conditionnelles susceptibles de faciliter l’intégration sophistiquée de données.
En contournant ces restrictions, Habovštiak a démontré qu’il reste possible d’inscrire des données relativement volumineuses (66 ko) sous forme de flux continu sur la blockchain, sans activer les ensembles d’instructions visés par BIP-110. Cette transaction a été vérifiée publiquement sur la chaîne, et ses données hexadécimales peuvent être décodées et visualisées directement avec un logiciel d’image standard.
De BIP-444 à BIP-110 : le débat sur le filtrage des données
Cette expérimentation ne constitue pas un cas isolé, mais s’inscrit dans la continuité d’un débat de longue date au sein de la communauté Bitcoin sur le filtrage des données. Pour en mesurer la portée, il est utile de revenir sur les étapes clés de l’année écoulée :
Le déclencheur : Bitcoin Core v30 lève les restrictions (mi-2025)
Le client principal de Bitcoin, Bitcoin Core, a supprimé la limite historique de 83 octets sur les sorties OP_RETURN dans sa version 30. Les puristes ont vu dans cette évolution une ouverture à l’inscription de données non financières, estimant qu’il s’agissait d’un éloignement de la vocation première de Bitcoin comme réseau de paiement et de réserve de valeur.
La riposte : propositions BIP-444 et BIP-110 (octobre–décembre 2025)
Sous l’impulsion de Luke Dashjr, mainteneur de Bitcoin Knots, les partisans d’un retour aux restrictions se sont mobilisés. Un développeur anonyme, Dathon Ohm, a d’abord proposé BIP-444 pour restreindre temporairement les données arbitraires. Peu après, la proposition plus stricte BIP-110 a vu le jour, suggérant un soft fork temporaire d’un an, avec notamment une limitation d’OP_RETURN à 83 octets et un plafonnement des pushs de données à 256 octets.
Controverse sur le mécanisme d’activation : le seuil de 55 % en débat (fin 2025–début 2026)
Le seuil d’activation proposé par BIP-110, fixé à seulement 55 % de la puissance de hachage, a suscité encore plus de controverses que les détails techniques eux-mêmes. Des détracteurs comme Adam Back, PDG de Blockstream, ont qualifié ce seuil de « tyrannie de la majorité », estimant qu’une barre aussi basse pourrait remettre en cause l’immuabilité de Bitcoin. Durant cette période, la part des nœuds soutenant BIP-110 est passée lentement d’environ 2,38 % en janvier à près de 8,8 % récemment.
Réfutation technique : la preuve de concept de Habovštiak (fin février 2026)
Au cœur de débats idéologiques vifs, l’expérimentation de Habovštiak a recentré la discussion sur les fondamentaux techniques. Sa démonstration ne portait pas seulement sur l’intégration de données, mais constituait une réponse directe aux partisans de BIP-110, qui insistaient sur la nécessité de restrictions techniques.
Analyse technique : comment les restrictions ont été contournées
D’un point de vue structurel, la transaction de Habovštiak illustre une ingéniosité technique remarquable.
Analyse de la construction de la transaction
L’innovation principale de cette transaction réside dans l’exploitation de la flexibilité du système de scripts Bitcoin, sans recourir aux opcodes de stockage de données classiques. Habovštiak a découpé les données de l’image TIFF de 66 ko et les a insérées dans des scripts d’entrée de transaction apparemment standards, tirant parti de la gestion des données témoin (witness) par SegWit v0. Structurellement, la transaction s’apparente davantage à un transfert complexe de fonds qu’à une simple opération de stockage de données.
Comparaison avec les restrictions de BIP-110
| Indicateur technique | Limite proposée par BIP-110 | Implémentation de Habovštiak | Analyse comparative |
|---|---|---|---|
| Utilisation d’OP_RETURN | Limitée à 83 octets | Non utilisée | Évite la voie réglementaire la plus directe |
| Dépendance à Taproot | Peut restreindre certaines versions | Utilise SegWit v0 | Montre que les scripts hérités peuvent aussi porter des données |
| Continuité des données | Vise à empêcher le stockage non standard | Flux de données continu obtenu | Montre que limiter certains opcodes ne supprime pas l’intégration de données |
| Volume total de données | Vise à réduire fortement les données on-chain | Transaction unique de 66 ko | Volume modeste, mais crée un précédent |
Habovštiak est allé plus loin en créant une transaction image conforme à BIP-110 et en la testant sur un environnement regtest. Il affirme que la version conforme était même plus volumineuse que l’originale, suggérant que les restrictions de BIP-110 pourraient en réalité augmenter les besoins de stockage sur la blockchain en raison de la restructuration des données. Cela remet directement en cause l’objectif central de BIP-110, à savoir la réduction des données on-chain.
Les camps en présence derrière l’expérimentation technique
Cet événement a attiré une large attention car il a cristallisé l’opposition concrète de deux courants historiques de la communauté.
Arguments des partisans de BIP-110
- Position de principe : Luke Dashjr et d’autres estiment que l’abus de données non financières constitue du spam, accroît les risques matériels et juridiques pour les opérateurs de nœuds et, à terme, menace la décentralisation de Bitcoin.
- Réaction à l’expérimentation : Après l’événement, Dashjr a contesté la démonstration de Habovštiak sur X, affirmant que la transaction n’était pas réellement continue et cherchant à réfuter le défi technique. Cela montre la volonté des partisans de défendre la légitimité technique de leur position.
Arguments des opposants à BIP-110
- Position de principe : Des détracteurs comme Adam Back et Wang Chun (Shenyu) estiment que l’immuabilité de Bitcoin prime sur tout. Toute modification des règles justifiée par la lutte anti-spam, surtout avec un seuil aussi bas (55 %), ouvrirait la boîte de Pandore des risques de gouvernance, pouvant conduire à terme à une censure à l’échelle des adresses.
- Réaction à l’expérimentation : Les opposants voient dans cette expérience une réfutation à la fois de la faisabilité technique et de la nécessité de BIP-110. Habovštiak lui-même a déclaré que sa motivation était de s’opposer à ce qu’il qualifie de « mensonges » du camp Knots.
Délimiter les faits, opinions et spéculations
Il est essentiel de distinguer clairement les différentes natures d’informations dans l’analyse de cet événement.
- Faits : Un développeur a réalisé avec succès une transaction intégrant 66 ko de données image TIFF sur le réseau principal Bitcoin. La transaction n’utilise ni OP_RETURN, ni Taproot, ni OP_IF, et peut être validée par tout nœud complet.
- Opinions : Considérer ou non cela comme un contournement de BIP-110 dépend de la définition retenue du terme. Les partisans peuvent y voir la révélation de nouvelles failles, justifiant le besoin de restrictions ; les opposants y voient la preuve de leur inutilité.
- Spéculations : Quant à savoir si cette expérience déclenchera une nouvelle vague d’inscriptions de type NFT, Habovštiak a déclaré qu’il ne publierait pas le code et ne souhaite pas encourager de telles initiatives. Rien n’indique à ce stade qu’il s’agisse du début d’une nouvelle vague d’attaques ; il s’agit avant tout d’un geste symbolique de protestation.
Répercussions pour les nœuds, mineurs et développeurs
Bien qu’il s’agisse d’une expérience isolée, cet événement pourrait avoir des conséquences pour différents acteurs de l’écosystème crypto.
- Opérateurs de nœuds : Pour ceux qui exploitent des nœuds Bitcoin Core, cette transaction n’a rien d’inhabituel et n’impose aucune charge supplémentaire. En revanche, pour les nœuds Bitcoin Knots cherchant à appliquer préventivement les règles de BIP-110, cette transaction conforme soulève une question philosophique : si les règles ne parviennent pas à restreindre le comportement visé, sont-elles réellement efficaces ?
- Mineurs et sécurité du réseau : L’événement a relancé le débat sur l’utilisation de l’espace de bloc. Les partisans de BIP-110 estiment que les inscriptions de données profitent des remises SegWit, créant une concurrence déloyale sur le marché des frais. Les opposants (dont des mineurs) rétorquent que, les récompenses de bloc diminuant régulièrement (offre actuelle autour de 19,99 M), tous les revenus de frais sont précieux et ne doivent pas être écartés. Les données montrent que les transactions de type inscription ont généré près de 10 millions de dollars de frais en une seule journée. La position des mineurs sur ce type de transaction devient plus nuancée.
- Communauté de développeurs : Le client d’activation BIP-110 a déjà été signalé comme comportant de nombreux bugs techniques, échouant même aux tests conçus par ses propres promoteurs. À l’inverse, la démonstration technique élégante de Habovštiak contraste fortement avec les imperfections du client BIP-110, ce qui pourrait affecter la confiance de la communauté dans la maturité technique de la proposition.
Analyse de scénarios : quelles perspectives pour la suite ?
Au vu des faits actuels, plusieurs scénarios d’évolution peuvent être envisagés.
| Scénario | Condition de déclenchement | Impact sur le réseau |
|---|---|---|
| Scénario 1 : Patch technique | Les partisans de BIP-110 ajoutent la méthode d’intégration de Habovštiak à une nouvelle liste de restrictions, proposant un BIP-xxx encore plus strict. | Déclenche un jeu du chat et de la souris ; les règles se complexifient sans jamais éliminer totalement l’intégration de données. |
| Scénario 2 : Retour au consensus | Compte tenu des bugs du client BIP-110 et du contournement récent, des opérateurs de nœuds se désengagent, l’adoption stagne ou régresse. | BIP-110 est mis de côté ; le débat redevient idéologique ; le réseau principal poursuit son fonctionnement habituel. |
| Scénario 3 : Risque de fork | Malgré un soutien insuffisant, les défenseurs de la proposition tentent une activation avec le seuil bas de 55 %, déclenchant une forte opposition communautaire. | Peut entraîner une division sévère du consensus, avec des chaînes Bitcoin aux règles divergentes et un impact négatif sur la valeur de la marque. |
| Scénario 4 : Pression réglementaire | Les régulateurs constatent que le contenu on-chain peut inclure des données illicites ou litigieuses, imposant des exigences de conformité aux opérateurs de nœuds. | Indépendamment de l reforme BIP-110, le risque juridique demeure un enjeu de long terme pour toutes les transactions de stockage de données. |
Conclusion
Une simple image de 66 ko a mis en lumière les dilemmes profonds de l’évolution de Bitcoin : dans un univers de code visant la résistance absolue à la censure, comment définir ce qui relève du « spam » ? Qui en décide ? L’expérimentation de Habovštiak n’a pas attaqué le réseau Bitcoin, mais a ciblé la logique d’une proposition visant à modifier les règles par défaut du protocole. Elle rappelle que chaque étape de l’évolution de Bitcoin requiert non seulement un consensus idéologique, mais aussi une mise en œuvre technique robuste. Quel que soit le sort de BIP-110, ce débat sur les limites de l’inscription de données s’inscrira comme un chapitre marquant de la gouvernance de Bitcoin.
