Le BIP-110 constitue l’une des propositions les plus controversées apparues récemment dans l’écosystème Bitcoin. Son titre officiel, Reduced Data Temporary Softfork, peut se traduire par « soft fork temporaire de réduction des données ».

Cette proposition vise à modifier temporairement les règles de consensus de Bitcoin. Elle limiterait plusieurs méthodes utilisées pour inscrire des données arbitraires dans les transactions. Elle ne cherche toutefois pas à supprimer toutes les formes possibles de stockage de données.

Le BIP-110 veut surtout empêcher la normalisation de Bitcoin comme réseau de stockage de fichiers. Ses auteurs défendent une vision précise : Bitcoin doit rester principalement un système monétaire décentralisé, résistant à la censure et accessible aux opérateurs de nœuds.

Ses opposants contestent cette approche. Ils estiment qu’une règle de consensus ne devrait pas décider quels usages économiques sont légitimes. Ils soulignent également que les restrictions proposées peuvent être contournées par des méthodes plus complexes.

Le débat ne se limite donc pas aux inscriptions, à OP_RETURN ou aux images stockées dans les témoins Taproot. Il concerne directement la gouvernance de Bitcoin, le rôle des politiques de relais et les limites acceptables d’un soft fork.

Pourquoi ce dossier sur le BIP-110 est nécessaire

De nombreuses discussions publiques résument le BIP-110 à une opposition entre les paiements et les inscriptions. Cette présentation reste trop simple. La proposition contient plusieurs règles distinctes, une méthode d’activation particulière et une durée d’application limitée.

Elle prévoit également une protection pour les bitcoins déjà présents dans l’ensemble des UTXO avant son activation. Cette disposition, appelée UTXO grandfathering, joue un rôle essentiel. Elle cherche à éviter que des sorties créées sous les anciennes règles deviennent soudainement impossibles à dépenser.

Pour comprendre le BIP-110, il faut donc étudier plusieurs sujets ensemble :

• la différence entre les règles de consensus et les politiques de relais ;
• l’histoire du stockage de données dans Bitcoin ;
• le fonctionnement d’OP_RETURN ;
• l’arrivée des inscriptions utilisant Taproot et les données témoins ;
• les restrictions techniques prévues par le BIP-110 ;
• son mécanisme d’activation et d’expiration ;
• ses conséquences possibles pour les nœuds, mineurs et portefeuilles ;
• les arguments techniques de ses partisans et de ses opposants.

Ce dossier examine ces éléments séparément. Il distingue les faits vérifiables, les objectifs déclarés des auteurs et les conséquences encore débattues.

Qu’est-ce qu’un BIP dans Bitcoin ?

Le sigle BIP signifie Bitcoin Improvement Proposal. Un BIP constitue un document formel qui présente une information, une norme, un processus ou une modification possible concernant Bitcoin.

Un BIP ne possède aucun pouvoir automatique. Son acceptation dans le dépôt officiel ne transforme pas son contenu en règle du réseau. Elle signifie principalement que la proposition dispose d’une spécification publique et d’un numéro permettant de la référencer.

Les développeurs, opérateurs de nœuds, entreprises, mineurs et utilisateurs peuvent ensuite analyser cette proposition. Ils peuvent la soutenir, la critiquer, l’ignorer ou développer une implémentation concurrente.

Certains BIP décrivent des standards applicatifs. Le BIP-32 définit, par exemple, les portefeuilles déterministes hiérarchiques. Le BIP-39 décrit une méthode de création de phrases mnémoniques. D’autres BIP modifient les règles de consensus du réseau.

Le BIP-110 appartient à cette dernière catégorie. Son adoption imposerait temporairement des règles supplémentaires aux blocs et aux transactions concernés.

Un BIP ne représente pas une décision collective

L’attribution d’un numéro ne prouve pas qu’une proposition bénéficie d’un consensus. Elle ne garantit pas davantage son activation future.

Bitcoin ne possède aucun parlement central chargé d’adopter les BIP. Aucun développeur ne peut imposer seul une nouvelle règle à tous les utilisateurs. Un dépôt GitHub ne contrôle pas non plus les nœuds installés dans le monde.

Une modification des règles de consensus devient réellement applicable lorsque des participants exécutent un logiciel qui l’impose. Pour un soft fork, les nœuds mis à jour appliquent des règles plus strictes que les anciens nœuds.

Les anciens nœuds peuvent encore reconnaître les blocs conformes aux nouvelles règles. Cependant, ils ne détectent pas nécessairement toutes les violations introduites par la nouvelle restriction.

Cette compatibilité descendante distingue généralement un soft fork d’un hard fork. Elle ne supprime pourtant pas les risques de désaccord, de division ou de chaîne minoritaire.

Consensus et politique de relais : la distinction fondamentale

Le débat autour du BIP-110 repose largement sur la différence entre les règles de consensus et les politiques de relais. Ces deux catégories ne remplissent pas la même fonction.

Les règles de consensus

Les règles de consensus déterminent si un bloc ou une transaction intégrée dans un bloc reste valide. Chaque nœud applique ces règles lorsqu’il vérifie la chaîne de blocs.

Un bloc qui viole une règle de consensus est rejeté par les nœuds qui appliquent cette règle. Le montant de travail accumulé ne suffit pas à rendre valide un bloc qui crée trop de bitcoins ou dépense une sortie inexistante.

Les règles de consensus contrôlent notamment :

• la validité des signatures ;
• l’existence et la disponibilité des UTXO dépensés ;
• l’absence de double dépense ;
• la création monétaire autorisée ;
• la taille et le poids maximaux des blocs ;
• certaines limites liées aux scripts ;
• les conditions d’exécution de Bitcoin Script.

Une modification du consensus exige donc une grande prudence. Une erreur peut affecter la validation des blocs, la sécurité des fonds ou la continuité de la chaîne.

Les politiques de relais

Les politiques de relais déterminent principalement quelles transactions non confirmées un nœud accepte dans sa mempool. Elles contrôlent aussi les transactions qu’il transmet à ses pairs.

Une transaction peut respecter les règles de consensus tout en étant refusée par la politique standard d’un nœud. Elle reste alors valide, mais ce nœud ne la relaie pas automatiquement.

Un autre nœud peut utiliser une politique différente. Un mineur peut également recevoir directement cette transaction puis l’intégrer dans un bloc. Les autres nœuds devront accepter ce bloc si la transaction respecte le consensus.

Les politiques de relais offrent donc une protection locale. Elles réduisent certains risques de spam, d’utilisation excessive des ressources ou de propagation de transactions problématiques. Cependant, elles ne rendent pas ces transactions invalides dans un bloc.

Pourquoi cette différence se trouve au centre du BIP-110

Historiquement, Bitcoin Core et d’autres logiciels ont utilisé des politiques standards pour limiter certaines formes de données arbitraires. La limite appliquée aux sorties OP_RETURN constitue l’exemple le plus connu.

Ces politiques n’empêchaient pas toujours un mineur d’inclure une transaction non standard dans un bloc. Elles augmentaient surtout les difficultés de propagation et décourageaient certains usages.

Le BIP-110 propose de déplacer plusieurs restrictions vers le consensus. Une transaction qui les enfreindrait ne serait plus seulement non standard. Elle deviendrait invalide dans les blocs soumis aux nouvelles règles.

Ce changement représente le cœur du désaccord. Les partisans du BIP-110 jugent les politiques locales insuffisantes. Selon eux, elles ne peuvent plus freiner efficacement l’utilisation de Bitcoin comme système de stockage de fichiers.

Les opposants estiment, au contraire, que le consensus ne doit pas imposer ce type de préférence. Ils privilégient les frais, les politiques locales et le marché de l’espace de bloc.

Le contexte monétaire défendu par les auteurs

Le texte officiel du BIP-110 défend explicitement Bitcoin comme monnaie native d’Internet. Il considère le stockage arbitraire comme un usage non pris en charge, susceptible de détourner les ressources du réseau.

Selon cette logique, chaque octet consacré à un fichier entre en concurrence avec les transactions monétaires. Une forte demande pour les inscriptions peut donc augmenter les frais payés par les utilisateurs qui transfèrent des bitcoins.

Les auteurs associent également le stockage de données à plusieurs coûts pour les opérateurs de nœuds. Ces coûts concernent l’espace disque, la bande passante, le temps de validation et la croissance éventuelle de l’ensemble des UTXO.

Le BIP affirme ainsi vouloir préserver la décentralisation. Son raisonnement repose sur une idée simple : moins un nœud coûte cher, plus un particulier peut vérifier Bitcoin sans déléguer cette fonction.

Cette motivation représente toutefois la position des auteurs. Elle ne constitue pas une conclusion universellement acceptée. Plusieurs critiques contestent la mesure réelle des coûts, l’efficacité des restrictions et la nécessité d’utiliser le consensus.

L’apparition des inscriptions à partir de 2022

Le BIP-110 situe le début de la controverse actuelle en 2022. Des développeurs ont alors exploité les possibilités offertes par Taproot et la remise appliquée aux données témoins.

Cette technique permet d’inscrire des données dans les éléments utilisés lors de la dépense d’une sortie Taproot. Les données peuvent apparaître dans un script révélé au moment de la transaction.

Les protocoles d’inscriptions ont ensuite utilisé cette possibilité pour intégrer des images, du texte, du code et d’autres fichiers dans la chaîne Bitcoin.

Ces données restent soumises à la limite de poids des blocs. Elles doivent également payer des frais. Toutefois, elles peuvent occuper une part importante de l’espace disponible lorsque la demande augmente.

Pour les partisans des inscriptions, cet espace appartient au marché. Un utilisateur qui paie les frais demandés devrait pouvoir choisir l’usage de sa transaction.

Pour les partisans du BIP-110, ce raisonnement ignore les coûts supportés par les nœuds. Il encourage également des modèles économiques qui présentent Bitcoin comme une plateforme permanente de stockage.

Le BIP-110 ne prétend pas éliminer toutes les données

Le BIP-110 ne peut pas interdire chaque forme imaginable de donnée arbitraire. Son texte reconnaît explicitement cette limite.

Un utilisateur peut dissimuler des informations dans des valeurs qui possèdent aussi une signification financière ou cryptographique. Il peut également découper un fichier en nombreux fragments plus petits.

La stéganographie rend impossible une distinction parfaite entre une donnée monétaire et une donnée externe. Une signature, une clé publique ou un nombre peuvent toujours encoder une information choisie.

La proposition cherche donc principalement à rendre le stockage direct plus difficile. Elle limite les grands blocs de données contiguës et plusieurs formats considérés comme favorables aux inscriptions.

Cette nuance doit rester présente pendant toute l’analyse. Le BIP-110 propose une restriction et un signal politique. Il ne promet pas une suppression mathématique de toutes les données non monétaires.

Une proposition volontairement temporaire

Le BIP-110 ne décrit pas un changement permanent. Les règles nouvelles expireraient automatiquement après 52 416 blocs.

Avec un intervalle moyen proche de dix minutes, cette durée représente approximativement une année. La durée réelle peut varier selon le rythme de production des blocs.

Après l’expiration, les règles supplémentaires cesseraient de s’appliquer. Les transactions retrouveraient alors les possibilités autorisées par les règles précédentes, sauf nouvelle modification du consensus.

Les auteurs présentent cette durée limitée comme une période de réduction des données. Elle devait permettre à l’écosystème de réévaluer les usages et les politiques sans imposer immédiatement une restriction permanente.

Cette caractéristique soulève néanmoins une question importante. Même temporaire, une règle de consensus peut modifier les pratiques, les logiciels et les attentes économiques du réseau.

Les principales restrictions annoncées

Lorsque le soft fork devient actif, le BIP-110 introduit les principales règles de consensus suivantes :

• Les scriptPubKey ordinaires ne peuvent pas dépasser 34 octets.
• Les scriptPubKey commençant par OP_RETURN restent autorisés jusqu’à une taille maximale de 83 octets.
• Les charges utiles OP_PUSHDATA ainsi que les éléments du Witness utilisés comme arguments de script sont limités à 256 octets, sous réserve des exceptions prévues par la spécification.
• Les dépenses utilisant une version de Witness ou une version de Tapleaf non définie deviennent invalides.
• La présence d’une Annex Taproot rend la dépense invalide.
• Les Control Blocks Taproot ne peuvent pas dépasser 257 octets.
• Tout Tapscript contenant un opcode OP_SUCCESS* devient invalide.
• Tout Tapscript exécutant OP_IF ou OP_NOTIF devient invalide.

Un débat qui dépasse les inscriptions

Le BIP-110 soulève une question plus profonde que la simple présence d’images ou d’autres données arbitraires dans la blockchain. Il demande jusqu’où le consensus peut aller pour décourager un usage considéré comme nuisible.

Bitcoin doit-il rester neutre face à toute transaction valide qui paie ses frais ? Les règles de consensus doivent-elles limiter certaines constructions techniques utilisées pour transporter des données arbitraires ? Une restriction temporaire peut-elle protéger la décentralisation sans fragiliser la stabilité du protocole ?

Ces questions ne disposent pas de réponses automatiques. Elles opposent plusieurs conceptions légitimes de Bitcoin.

La première privilégie la fonction monétaire. Elle considère le stockage arbitraire comme une utilisation parasitaire qui impose des coûts durables au réseau.

La seconde privilégie la neutralité des règles. Elle considère que le marché des frais doit arbitrer l’utilisation de l’espace de bloc.

Une troisième approche accepte certaines restrictions de politique, mais refuse leur transfert vers le consensus. Elle cherche ainsi à décourager ces usages au moyen des politiques de relais, sans modifier les règles de consensus ni la validité des blocs.

Chapitre 2

Pourquoi les données arbitraires sont devenues un sujet de consensus

Le BIP-110 ne propose pas une simple modification du logiciel Bitcoin. Il intervient dans un débat beaucoup plus profond. Ce débat concerne la fonction même du réseau, l’usage de l’espace limité des blocs et le rôle des règles de consensus.

Pour comprendre cette proposition, il faut donc revenir à une question fondamentale. Bitcoin doit-il servir principalement au transfert de valeur, ou doit-il également devenir un support permanent pour stocker des fichiers et des données sans fonction monétaire directe ?

Cette question peut sembler philosophique. Pourtant, elle entraîne des conséquences techniques très concrètes. Chaque donnée ajoutée dans une transaction doit être téléchargée, vérifiée et conservée par les nœuds concernés.

Le débat porte également sur les frais, la croissance de la chaîne, l’ensemble UTXO et le coût d’exploitation d’un nœud. Enfin, il concerne la manière dont Bitcoin définit les usages qu’il accepte durablement.

Bitcoin transporte déjà des données

Une transaction Bitcoin ne contient pas seulement un montant envoyé entre deux personnes. Elle contient aussi des entrées, des sorties, des scripts, des signatures et différents éléments nécessaires à sa validation.

Ces informations constituent déjà des données. Elles possèdent toutefois une fonction précise. Elles permettent au réseau de vérifier qu’un bitcoin peut être dépensé et que les règles monétaires restent respectées.

Le problème ne consiste donc pas à supprimer toute donnée de Bitcoin. Une telle suppression rendrait les transactions impossibles. Le véritable débat concerne les données qui ne servent pas directement à valider un transfert ou une condition de dépense.

On parle alors de données arbitraires. Ce terme désigne des contenus dont le protocole n’a pas besoin pour comprendre la transaction monétaire.

Il peut s’agir d’un texte, d’une image, d’un fichier, d’un document ou d’un fragment de programme. Le réseau traite alors ces octets comme une partie de la transaction, même si leur signification dépend d’un logiciel extérieur.

La différence entre une donnée monétaire et une donnée arbitraire

Une signature cryptographique prouve qu’un utilisateur possède l’autorisation nécessaire pour dépenser une sortie. Une clé publique permet également de vérifier certaines conditions prévues par le script.

Ces données possèdent donc une signification directe pour Bitcoin. Les règles de consensus savent comment les interpréter et comment vérifier leur validité.

À l’inverse, une image insérée dans une transaction n’a aucune fonction monétaire native. Bitcoin ne sait pas qu’il s’agit d’une image. Il voit seulement une suite d’octets intégrée dans une structure autorisée.

Un logiciel externe peut ensuite extraire ces octets et reconstruire le fichier. La signification apparaît donc en dehors du protocole Bitcoin.

Cette distinction forme le cœur du BIP-110. Ses défenseurs ne cherchent pas à limiter les données nécessaires aux paiements. Ils veulent limiter certaines structures utilisées pour intégrer de gros volumes de données non monétaires.

Pourquoi l’espace des blocs représente une ressource rare

Bitcoin produit approximativement un bloc toutes les dix minutes. Chaque bloc possède une capacité maximale définie par les règles du protocole.

Cette capacité limitée crée un marché. Lorsque de nombreuses transactions souhaitent entrer dans le prochain bloc, les utilisateurs augmentent leurs frais.

Les mineurs choisissent généralement les transactions offrant le meilleur revenu par unité d’espace. Ainsi, les paiements monétaires et les inscriptions de données utilisent le même espace disponible.

Un utilisateur qui souhaite transférer des bitcoins peut donc se retrouver en concurrence avec une activité destinée à stocker une image ou un fichier. Cette concurrence reste permise par les règles actuelles lorsque la transaction respecte le consensus.

Pour les opposants au BIP-110, ce marché doit rester neutre. Celui qui paie les frais requis devrait pouvoir utiliser l’espace disponible.

Pour les défenseurs du BIP-110, cette vision ne suffit pas. Ils considèrent que Bitcoin doit protéger sa fonction monétaire avant qu’un usage non monétaire devienne structurel.

Pourquoi les frais ne règlent pas tout

Un argument fréquent affirme que les frais constituent le filtre naturel de Bitcoin. Selon cette logique, une donnée ne peut entrer dans un bloc que si son auteur paie le prix demandé.

Cet argument décrit correctement le fonctionnement du marché des frais. Toutefois, il ne répond pas entièrement aux préoccupations soulevées par le BIP-110.

Les frais rémunèrent principalement le mineur qui confirme la transaction. En revanche, les milliers de nœuds qui téléchargent et vérifient le bloc ne reçoivent pas directement ces frais.

Le coût d’une transaction ne repose donc pas seulement sur son auteur. Il se répartit aussi sur l’infrastructure décentralisée qui conserve et vérifie l’historique.

Les partisans du BIP-110 parlent alors d’externalités. L’utilisateur paie le mineur, mais il impose également un travail et une consommation de ressources aux opérateurs de nœuds.

Les opposants répondent que cette charge reste encadrée par les limites maximales des blocs. Selon eux, le réseau connaît déjà sa croissance maximale possible, que les blocs transportent des paiements ou des fichiers.

Le désaccord ne concerne donc pas uniquement la quantité d’espace utilisée. Il concerne également la finalité de cet espace et les incitations créées par le protocole.

L’importance de l’ensemble UTXO

Une partie du débat concerne l’ensemble UTXO. Cet ensemble regroupe les sorties de transactions qui n’ont pas encore été dépensées.

Un nœud complet utilise ces informations pour vérifier qu’une transaction dépense réellement des bitcoins disponibles. Il doit donc accéder rapidement à cet ensemble lors de la validation.

Contrairement à certaines données historiques, l’ensemble UTXO ne peut pas être simplement ignoré. Il représente l’état monétaire actuel du réseau.

Le BIP-110 limite notamment les nouveaux scriptPubKey à 34 octets. Une exception autorise jusqu’à 83 octets lorsque le premier opcode est OP_RETURN.

Cette distinction possède une raison précise. Une sortie OP_RETURN est considérée comme définitivement non dépensable. Les nœuds n’ont donc pas besoin de la conserver dans l’ensemble UTXO.

À l’inverse, une sortie potentiellement dépensable doit rester disponible tant qu’aucune transaction ne l’a consommée. Un script de sortie volumineux peut alors augmenter durablement la taille de cet ensemble.

Le document officiel du BIP-110 présente cette limite comme une protection contre l’augmentation inutile du coût des nœuds. Il mentionne également le risque de transactions ou de blocs particulièrement longs à valider.

Le rôle historique de la politique de relais

Bitcoin distingue deux niveaux de règles. Les règles de consensus déterminent la validité des transactions et des blocs. Les règles de politique définissent ce qu’un nœud accepte généralement de relayer dans son mempool.

Une transaction peut donc respecter le consensus tout en étant refusée par la politique standard d’un nœud. Dans ce cas, elle reste théoriquement valide, mais sa propagation devient plus difficile.

Les politiques de relais permettent aux opérateurs de nœuds de filtrer certains usages sans modifier les règles fondamentales du réseau. Elles évoluent aussi plus facilement qu’un soft fork.

Cependant, un mineur peut recevoir directement une transaction non standard. Il peut ensuite l’inclure dans un bloc lorsqu’elle respecte les règles de consensus.

Une fois la transaction confirmée, tous les nœuds doivent accepter le bloc valide. Leur politique locale ne peut plus écarter cette transaction.

Cette différence explique la stratégie du BIP-110. La proposition ne se limite pas à renforcer un filtre de mempool. Elle veut rendre certaines structures invalides pendant une période définie.

Pourquoi le BIP-110 veut agir au niveau du consensus

Le BIP-110 part du principe que les politiques de relais ne suffisent plus à envoyer un signal clair. Selon son auteur, certains formats de stockage ont commencé à apparaître comme des usages officiellement tolérés.

La proposition cherche donc à rapprocher temporairement les règles de consensus de limites auparavant appliquées par la politique standard.

Son objectif déclaré consiste à limiter les champs de données au niveau du consensus. L’auteur souhaite ainsi réduire les incitations liées à la standardisation du stockage arbitraire.

Le BIP-110 ne prétend pas supprimer toute possibilité de cacher des données. Une interdiction absolue serait pratiquement impossible.

Un utilisateur peut toujours fragmenter un fichier, encoder des informations ou les dissimuler dans des structures financières. Toutefois, ces méthodes deviennent plus complexes, moins directes et plus coûteuses.

Le but consiste donc à rendre le stockage massif moins simple. La proposition veut également éviter que Bitcoin présente ce stockage comme une fonction normalement prise en charge.

Le tournant provoqué par les inscriptions

Le document officiel du BIP-110 situe le début du phénomène moderne des inscriptions en 2022. Cette méthode a facilité l’intégration de contenus arbitraires dans les témoins de transactions.

Ces contenus peuvent ensuite être interprétés par des indexeurs externes. Ceux-ci reconstruisent des images, des textes ou d’autres objets numériques à partir des données présentes dans la chaîne.

Pour le protocole Bitcoin, ces objets ne constituent pas des images ou des jetons natifs. Ils restent des données placées dans une transaction valide.

Cette nuance reste essentielle. Bitcoin valide la transaction, mais il ne valide pas nécessairement l’interprétation commerciale ou artistique créée autour du contenu.

Malgré cela, les inscriptions ont créé de nouveaux marchés. Elles ont également généré une demande spécifique pour l’espace des blocs.

Les défenseurs de ces usages considèrent qu’ils renforcent le marché des frais. Selon eux, cette demande pourrait soutenir les revenus des mineurs lorsque la subvention diminue.

Les partisans du BIP-110 répondent qu’un marché des frais ne doit pas dépendre d’un usage qui détourne Bitcoin de sa fonction monétaire. Ils craignent aussi qu’un tel modèle augmente les coûts supportés par les utilisateurs ordinaires.

Pourquoi la limite de 256 octets occupe une place centrale

Le BIP-110 fixe plusieurs limites techniques. La plus visible concerne les charges utiles placées avec les opérations OP_PUSHDATA et certains éléments de la pile témoin.

Ces éléments ne pourraient pas dépasser 256 octets pendant l’application du soft fork. Une exception concerne le redeemScript utilisé dans les scriptSig définis par le BIP-16.

L’auteur considère que 256 octets restent suffisants pour les nombres et données utilisés par des opérations cryptographiques légitimes.

Dans le même temps, cette limite complique l’intégration directe d’images et de fichiers plus volumineux. Le contenu doit alors être fragmenté en plusieurs morceaux.

Le chiffre de 256 octets ne représente donc pas une frontière magique entre un paiement et un fichier. Il constitue un compromis choisi pour préserver les usages monétaires connus.

Les critiques soulignent toutefois que la fragmentation reste possible. Selon eux, la règle ajoute de la complexité sans empêcher réellement l’intégration de données.

Les défenseurs répondent que la proposition n’a jamais promis une suppression totale. Elle cherche surtout à retirer la simplicité et la reconnaissance implicite de cet usage.

Pourquoi les images sont particulièrement visées

Le texte du BIP-110 accorde une attention particulière aux images. Son auteur estime qu’elles représentent l’un des usages les plus susceptibles de créer une demande massive.

Une image possède une valeur visuelle immédiate. Elle peut devenir un objet de collection, un support spéculatif ou un produit vendu sur une plateforme.

Cette facilité de commercialisation peut multiplier rapidement le nombre d’utilisateurs souhaitant inscrire des fichiers dans la chaîne.

Le BIP précise que certaines images compressées peuvent tenir dans quelques centaines d’octets. Une limite fixée à 256 octets rendrait leur intégration directe plus difficile.

L’objectif reste cependant plus large que les seules images. Les restrictions concernent plusieurs méthodes pouvant transporter des données contiguës importantes.

Une proposition temporaire, et non une interdiction permanente

Le nom complet du BIP-110 est Reduced Data Temporary Softfork. Le mot « temporaire » joue donc un rôle essentiel.

Les règles supplémentaires doivent s’appliquer pendant environ une année. Le déploiement prévoit précisément une durée de 52 416 blocs.

À raison d’un bloc toutes les dix minutes en moyenne, cette période correspond approximativement à douze mois.

Après l’expiration, les restrictions cesseraient automatiquement. Les sorties redeviendraient soumises aux règles normales du protocole.

Cette durée limitée sert plusieurs objectifs. Elle réduit d’abord le risque d’imposer immédiatement une orientation permanente.

Elle crée ensuite une période d’observation. Les développeurs, les mineurs, les opérateurs de nœuds et les utilisateurs pourraient étudier les conséquences réelles du changement.

Enfin, elle donne au réseau le temps de discuter d’une solution plus durable. Cette solution pourrait reprendre certaines règles, les modifier ou les abandonner.

Le principe de protection des anciens UTXO

Le BIP-110 contient un mécanisme appelé UTXO grandfathering. Ce mécanisme protège les sorties créées avant l’activation.

Lorsqu’une entrée dépense un UTXO créé avant la hauteur d’activation, les nouvelles restrictions ne s’appliquent pas à cette dépense.

Une pièce existante ne deviendrait donc pas inutilisable uniquement parce que son script ne respecte pas les nouvelles limites.

Les règles concerneraient seulement les UTXO créés à partir de la hauteur d’activation. Après l’expiration du soft fork, toutes les sorties retrouveraient les règles habituelles.

Cette protection cherche à éviter le gel accidentel de bitcoins. Elle limite aussi les effets sur les portefeuilles et constructions déjà déployés avant l’activation.

Cependant, elle ne supprime pas toutes les difficultés possibles. Une application pourrait créer de nouvelles sorties pendant la période d’activation sans respecter correctement les nouvelles contraintes.

Les développeurs doivent donc analyser les règles avant de produire des transactions destinées à cette période.

Pourquoi un soft fork reste une décision majeure

Un soft fork ajoute de nouvelles conditions de validité. Les blocs acceptés après l’activation doivent respecter un ensemble de règles plus strict.

Cette compatibilité apparente ne rend pas le changement anodin. Un désaccord prolongé peut provoquer une divergence entre les participants.

Les nœuds qui appliquent le BIP-110 rejetteraient un bloc contenant une transaction interdite. Les nœuds qui n’appliquent pas ces règles pourraient considérer ce même bloc comme valide.

La stabilité dépend donc du comportement des mineurs, des opérateurs économiques et des utilisateurs. Une activation sans adhésion suffisante peut créer une chaîne minoritaire ou une séparation durable.

C’est pourquoi le débat ne peut pas se limiter à une préférence personnelle concernant les inscriptions. Le BIP-110 touche directement aux règles utilisées pour déterminer la chaîne valide.

Un débat sur la neutralité du protocole

Les opposants au BIP-110 défendent souvent la neutralité transactionnelle. Selon eux, Bitcoin ne doit pas décider quelle utilisation mérite l’espace des blocs.

Une transaction qui respecte les règles et paie les frais requis devrait rester valide. Le protocole n’aurait pas à distinguer un paiement, une inscription ou une construction expérimentale.

Les défenseurs du BIP-110 contestent cette interprétation. Ils rappellent que Bitcoin impose déjà de nombreuses limites.

Le protocole limite la taille des blocs, les opérations de script, les éléments de pile et plusieurs structures de transactions. Bitcoin n’est donc pas un système sans contraintes.

La question consiste alors à déterminer quelles contraintes protègent sa fonction essentielle. Pour les partisans du BIP-110, la monnaie doit rester prioritaire.

Pour ses opposants, une telle sélection ouvre une porte dangereuse. Une majorité pourrait ensuite vouloir interdire d’autres transactions jugées indésirables.

Ce risque explique pourquoi chaque règle doit être analysée séparément. Le débat ne peut pas reposer uniquement sur le mot « spam ».

Le mot « spam » complique le débat

Le mot « spam » possède une forte charge émotionnelle. Il décrit généralement une activité considérée comme inutile, abusive ou nuisible.

Cependant, les participants ne partagent pas toujours la même définition. Une transaction peut sembler inutile à un opérateur et précieuse pour son auteur.

Une définition purement subjective ne suffit donc pas pour établir une règle de consensus. Le protocole doit appliquer des conditions mesurables.

Le BIP-110 ne demande pas aux nœuds d’évaluer le contenu d’un fichier. Il impose des limites de taille et interdit certaines structures précises.

Cette approche évite une analyse sémantique. Un nœud n’a pas besoin de savoir si les données représentent une image, un contrat ou un texte.

Il vérifie seulement la longueur d’un champ, la version d’un témoin, la présence d’une annexe ou l’usage de certains opcodes.

Ce que le BIP-110 cherche réellement à obtenir

Le BIP-110 ne peut pas empêcher toute forme de stockage arbitraire. Son auteur le reconnaît dans le document officiel.

Un utilisateur déterminé pourrait fragmenter ses données. Il pourrait aussi les dissimuler dans des clés, des signatures ou d’autres structures.

La proposition cherche plutôt à modifier les incitations. Elle veut rendre le stockage plus coûteux, moins direct et moins facilement standardisable.

Elle veut également envoyer un message protocolaire. Bitcoin accepterait les données nécessaires à la monnaie, mais ne reconnaîtrait pas le stockage de fichiers comme une fonction centrale.

Cette intention explique la durée temporaire du soft fork. Le BIP-110 se présente comme une mesure de protection et de recentrage.

Ses critiques y voient au contraire une intervention inefficace. Selon eux, elle perturberait des usages légitimes sans arrêter les utilisateurs réellement motivés.

Ce chapitre permet de comprendre la suite

Le débat autour du BIP-110 ne se résume pas à une opposition entre les paiements et les images. Il touche à la définition même des responsabilités du protocole.

Il oppose deux visions de la neutralité. La première considère que les frais doivent décider des usages. La seconde estime que les règles doivent protéger explicitement la fonction monétaire.

Il oppose également deux méthodes. Les uns privilégient les politiques locales de relais. Les autres veulent inscrire temporairement certaines limites dans le consensus.

Enfin, il pose une question de gouvernance. Qui peut décider qu’une utilisation représente un abus, et comment Bitcoin peut-il modifier ses règles sans créer de précédent dangereux ?

Examinions précisément les règles techniques du BIP-110 dans le chapitre 3. Chaque restriction sera étudiée séparément, avec ses objectifs, ses conséquences et ses limites.

Chapitre 3

Les règles techniques du BIP-110 expliquées une par une

Le débat philosophique autour du BIP-110 ne suffit pas à comprendre sa portée. Pour mesurer ses conséquences, il faut désormais examiner son contenu technique. Contrairement à certaines propositions très générales, le BIP-110 décrit précisément quelles structures deviennent temporairement invalides et dans quelles conditions.

L’objectif n’est pas de réécrire entièrement le langage de script de Bitcoin. La proposition ajoute un ensemble limité de restrictions pendant une période déterminée. Ces restrictions visent plusieurs mécanismes utilisés depuis l’apparition des inscriptions et de certaines méthodes de stockage de données arbitraires.

Chaque règle possède sa propre justification. Certaines cherchent à limiter la taille des données transportées. D’autres empêchent des techniques particulières introduites avec Taproot. Enfin, plusieurs mesures visent à réduire la création de nouvelles méthodes de stockage qui pourraient apparaître à l’avenir.

Une approche fondée sur des limites mesurables

Le BIP-110 ne demande jamais à un nœud d’interpréter le contenu d’une transaction. Le logiciel ne doit pas reconnaître une photographie, un document PDF ou un jeton numérique. Il applique uniquement des règles techniques parfaitement objectives.

Chaque nœud mesure la taille d’un élément de données, vérifie certains opcodes ou contrôle la présence de structures précises. Si une règle n’est pas respectée, la transaction devient invalide durant la période d’application du soft fork.

Cette méthode présente un avantage important. Tous les nœuds obtiennent exactement le même résultat. Aucune interprétation humaine n’intervient dans la validation.

Les huit principales mesures techniques du BIP-110

Le BIP-110 ne repose pas sur une interdiction générale des données arbitraires. Une telle interdiction serait pratiquement impossible à formuler, car le protocole Bitcoin ne peut pas déterminer si une suite d’octets représente une signature, une clé, une image, un texte ou un autre type de contenu.

La proposition agit donc sur des structures techniques précises. Pendant la période temporaire d’application du soft fork, certaines sorties, certains éléments de script et plusieurs mécanismes liés à SegWit et à Taproot seraient soumis à de nouvelles règles de consensus.

La spécification officielle énumère sept règles supplémentaires de validation. Elle leur ajoute une protection particulière pour les sorties non dépensées créées avant l’activation. Présentées ensemble, ces dispositions forment les huit principales mesures techniques du BIP-110.

Première mesure : limiter les nouveaux scriptPubKey à 34 octets

La première règle concerne les nouveaux scriptPubKey. Un scriptPubKey représente les conditions qui devront être satisfaites pour dépenser une sortie Bitcoin. Il peut notamment contenir un programme Witness, une clé publique ou l’empreinte cryptographique d’un script.

Pendant l’application du BIP-110, tout nouveau scriptPubKey dépassant 34 octets serait invalide, sauf lorsqu’il commence par l’opcode OP_RETURN.

Cette limite de 34 octets couvre les formats de paiement couramment utilisés. Une sortie P2WPKH utilise par exemple un programme Witness de 22 octets, une sortie P2WSH en utilise 34 et une sortie P2TR associée à Taproot en utilise également 34. Les paiements ordinaires utilisant ces formats resteraient donc possibles.

L’objectif est d’empêcher la création de scripts de sortie anormalement volumineux dont la taille serait principalement consacrée au transport de données plutôt qu’à la définition d’une condition de dépense.

L’exception accordée aux sorties OP_RETURN

Une exception est prévue lorsque le premier opcode du scriptPubKey est OP_RETURN. Dans ce cas, la taille maximale autorisée serait de 83 octets.

OP_RETURN permet de créer une sortie explicitement non dépensable. Aucun utilisateur ne pourra ensuite présenter une signature ou un script permettant de récupérer les bitcoins associés. Cette sortie n’a donc pas vocation à rester dans l’ensemble des UTXO que les nœuds doivent conserver pour vérifier les dépenses futures.

Les données contenues dans une sortie OP_RETURN demeurent inscrites dans l’historique de la blockchain, mais elles n’augmentent pas durablement la taille de l’état monétaire actif. Le BIP-110 réintroduit ainsi, au niveau du consensus et pendant une période limitée, la limite de 83 octets historiquement appliquée par la politique standard de relais.

Cette exception ne signifie donc pas que les auteurs approuvent un stockage illimité au moyen d’OP_RETURN. Elle réserve simplement un espace réduit et explicitement non dépensable pour certains engagements cryptographiques, identifiants ou usages techniques de petite taille.

Deuxième mesure : limiter à 256 octets les charges utiles OP_PUSHDATA et certains éléments du Witness

La deuxième règle constitue l’un des éléments centraux du BIP-110. Elle rend invalides les charges utiles de plus de 256 octets introduites par les différentes opérations de la famille OP_PUSHDATA. Elle applique également cette limite aux éléments du Witness utilisés comme arguments d’un script.

Les instructions OP_PUSHDATA servent à placer une suite d’octets sur la pile de Bitcoin Script. Ces octets peuvent représenter une signature, une clé publique, une empreinte, un nombre ou toute autre donnée interprétée par le script.

La limite ne porte pas sur la taille totale d’une transaction. Elle ne signifie pas non plus que l’ensemble du Witness ou du script serait limité à 256 octets. Elle s’applique séparément à chaque charge utile concernée.

Une transaction pourrait donc toujours contenir plusieurs éléments de 256 octets ou moins. En revanche, elle ne pourrait plus inclure un élément individuel de plusieurs milliers ou millions d’octets correspondant directement à une image, un document, une archive ou un autre fichier volumineux.

Pourquoi la limite est fixée à 256 octets

La valeur de 256 octets vise à préserver les usages monétaires et cryptographiques connus tout en empêchant l’insertion simple de longues séquences de données contiguës.

Les signatures ECDSA et Schnorr, les clés publiques, les préimages utilisées dans certains contrats et les paramètres habituels de Bitcoin Script restent très largement inférieurs à cette limite. Les transactions monétaires ordinaires ne reposent généralement pas sur des arguments individuels de plusieurs centaines de milliers d’octets.

Les inscriptions modernes utilisent au contraire des contenus qui peuvent atteindre plusieurs milliers, centaines de milliers ou millions d’octets. Une limite de 256 octets oblige alors leurs concepteurs à fragmenter fortement les données et à multiplier les éléments nécessaires à leur reconstitution.

Le BIP-110 ne prétend pas rendre toute fragmentation impossible. Un utilisateur déterminé pourrait tenter de répartir un contenu entre de nombreux éléments, scripts ou transactions. La proposition cherche plutôt à supprimer les méthodes qui permettent aujourd’hui d’insérer simplement de très grands blocs de données contigus.

L’exception du redeemScript de BIP-16

La règle prévoit une exception précise pour le redeemScript placé dans le scriptSig lors de la dépense d’une sortie P2SH conforme au BIP-16.

Dans une dépense P2SH, le script complet définissant les conditions de dépense doit être révélé au moment où les bitcoins sont utilisés. Certains scripts légitimes peuvent dépasser 256 octets, notamment des constructions multisignatures ou d’autres mécanismes historiques antérieurs à SegWit.

Sans cette exception, le soft fork risquerait de rendre certaines sorties P2SH nouvellement créées impossibles à dépenser. Le BIP-110 maintient donc le traitement particulier du redeemScript, tout en appliquant la limite de 256 octets aux autres charges utiles concernées.

Pourquoi le Witness est directement concerné

Le Witness, introduit par SegWit en 2017, contient les éléments nécessaires à la validation d’une dépense. Il transporte notamment des signatures, des clés publiques, des scripts et leurs arguments.

Depuis SegWit, les données du Witness bénéficient d’un traitement différent dans le calcul du poids d’une transaction. Un octet placé dans la partie non-Witness compte pour quatre unités de poids, tandis qu’un octet placé dans le Witness compte pour une seule unité.

Cette réduction avait notamment pour objectifs de corriger la malléabilité des transactions et d’encourager l’adoption de SegWit. Elle a cependant rendu le Witness économiquement attractif pour l’insertion de volumes importants de données.

Les inscriptions popularisées à partir de 2022 ont exploité les possibilités offertes par Taproot et le Witness pour placer des contenus dans des branches de script qui peuvent être révélées au moment de la dépense.

Le BIP-110 ne supprime ni SegWit, ni le Witness, ni Taproot. Il limite la taille de certains éléments individuels afin que cette zone reste principalement consacrée aux preuves cryptographiques et aux conditions de dépense.

Les critiques adressées à la limite de 256 octets

Les opposants au BIP-110 soulignent qu’une limite par élément n’interdit pas nécessairement le stockage de données. Un contenu peut être découpé en fragments de 256 octets ou moins, puis réassemblé par un indexeur externe.

Ils estiment également qu’il est difficile de distinguer objectivement une donnée monétaire d’une donnée arbitraire. Certains protocoles légitimes pourraient avoir besoin de transporter des éléments inhabituels ou plus volumineux que ceux utilisés par les paiements classiques.

Les défenseurs de la proposition répondent que l’objectif n’est pas d’obtenir une impossibilité mathématique absolue. Ils veulent augmenter le coût, la complexité et l’inefficacité du stockage massif afin que Bitcoin ne soit plus traité comme une plateforme générique de publication de fichiers.

Troisième mesure : interdire la dépense des versions Witness ou Tapleaf non définies

La troisième règle concerne les versions de programme Witness et les versions de Tapleaf qui ne possèdent pas encore de règles officiellement définies.

SegWit a été conçu avec un système de versions. La version 0 correspond notamment aux programmes définis par le BIP-141. La version 1 est utilisée par Taproot conformément au BIP-341. D’autres numéros sont réservés à de possibles évolutions futures du protocole.

Taproot prévoit également différentes versions possibles pour les feuilles de script, appelées Tapleaf versions. La version actuellement définie pour Tapscript est encadrée par les règles du BIP-342. Les autres valeurs restent disponibles pour de futures extensions.

Le BIP-110 rendrait invalide la dépense d’une sortie utilisant une version Witness ou Tapleaf non définie. Les exceptions reconnues par la proposition sont les programmes Witness version 0, Taproot et les sorties P2A, c’est-à-dire Pay-to-Anchor.

Cette restriction porte sur la dépense des sorties concernées. La création d’une nouvelle sortie utilisant une version Witness encore inconnue resterait possible. Toutefois, cette sortie ne pourrait pas être dépensée pendant la période d’application du soft fork, sauf si elle bénéficie de la protection accordée aux UTXO antérieurs à l’activation.

Préserver les espaces réservés aux évolutions futures

Les versions inconnues constituent une réserve d’évolution. Elles permettent d’ajouter ultérieurement de nouvelles règles sans devoir remplacer complètement les formats déjà utilisés.

Les auteurs du BIP-110 craignent que ces espaces ne soient détournés avant leur définition officielle. Une application pourrait créer une sortie utilisant une version inconnue, y associer des données, puis profiter des règles de compatibilité prévues pour les futures extensions.

Selon les défenseurs du BIP, une utilisation massive de ces versions pourrait devenir difficile à remettre en cause si des services, des marchés ou des utilisateurs commençaient à en dépendre. La restriction temporaire cherche donc à empêcher qu’un usage non prévu devienne progressivement incontournable.

Les opposants répondent qu’un futur soft fork peut précisément attribuer de nouvelles règles à ces versions et rendre incompatibles les anciennes utilisations. Ils considèrent donc qu’il n’est pas nécessaire de les neutraliser préventivement.

Le cas particulier des sorties P2A

La spécification mentionne explicitement les sorties P2A parmi les formes reconnues. P2A signifie Pay-to-Anchor. Ce type de sortie a été conçu pour faciliter certaines opérations liées aux frais, aux transactions pré-signées et au relais de paquets.

Une sortie P2A utilise une construction Witness particulière, mais elle n’est pas traitée comme une version inconnue par le BIP-110. Elle reste donc dépensable conformément aux règles qui lui sont applicables.

Il ne faut pas présenter le Witness vide d’une dépense P2A comme une huitième règle autonome du BIP-110. Il découle du fonctionnement de P2A et de son traitement dans l’implémentation, tandis que la spécification officielle l’intègre à la règle consacrée aux versions Witness reconnues.

Quatrième mesure : interdire l’Annex Taproot

La quatrième règle concerne l’Annex de Taproot. Cette structure optionnelle se trouve dans le Witness d’une dépense Taproot. Lorsqu’elle est présente, son premier octet possède une valeur particulière permettant de l’identifier.

L’Annex a été réservée par le BIP-341 afin de permettre de futures extensions. Elle est prise en compte dans l’engagement signé par la transaction, mais les règles actuelles de Taproot ne lui attribuent pas encore de fonction opérationnelle générale.

Le BIP-110 rendrait invalide toute pile Witness contenant une Annex Taproot pendant la durée du soft fork, sous réserve de la protection accordée aux UTXO créés avant l’activation.

Contrairement à une simple limitation de taille, la proposition ne permettrait donc aucune Annex pour les nouvelles sorties soumises aux règles du BIP-110.

Pourquoi interdire complètement l’Annex

Comme l’Annex ne possède pas encore d’usage largement déployé, les auteurs considèrent que son interdiction temporaire ne devrait pas perturber les paiements Bitcoin ordinaires.

Ils veulent également éviter que cette structure réservée soit adoptée comme nouveau support de données après la fermeture d’autres méthodes d’inscription. Sans cette règle, les utilisateurs pourraient simplement déplacer certaines données vers l’Annex afin de contourner les limites imposées ailleurs.

Les critiques de cette mesure soulignent toutefois que l’Annex a précisément été prévue pour rendre Taproot extensible. Son interdiction, même temporaire, réduirait donc l’espace disponible pour l’expérimentation et pourrait compliquer le déploiement de futurs protocoles.

Cinquième mesure : limiter les Control Blocks Taproot à 257 octets

La cinquième règle s’applique aux Control Blocks de Taproot. Un Control Block est révélé lorsqu’une sortie Taproot est dépensée par le chemin de script, appelé script path.

Il contient notamment la clé interne Taproot, la version de la feuille révélée et les empreintes nécessaires pour reconstruire le chemin de Merkle reliant le script utilisé à la racine engagée dans la sortie.

Le BIP-110 rendrait invalide tout Control Block dépassant 257 octets. D’après la spécification, cette taille correspond à un arbre de Merkle comportant jusqu’à 128 feuilles de script.

Cette règle limite donc la profondeur du chemin de Merkle pouvant être révélé lors d’une dépense Taproot. Elle ne supprime pas l’utilisation du chemin de script et permet encore la construction d’arbres contenant un nombre important de conditions différentes.

Pourquoi les Control Blocks sont concernés

Les Control Blocks sont principalement constitués de données cryptographiques nécessaires pour prouver l’appartenance d’une feuille à l’arbre Taproot. Leur taille augmente avec la profondeur de cette feuille dans l’arbre.

Sans limite supplémentaire, des constructions particulièrement profondes pourraient produire des Control Blocks volumineux. Les auteurs du BIP-110 veulent empêcher que cette structure technique serve de vecteur alternatif pour placer de grandes quantités de données dans le Witness.

Les opposants peuvent toutefois considérer qu’une profondeur plus importante possède des applications légitimes. Certains protocoles pourraient vouloir engager un grand nombre de branches tout en révélant uniquement celle qui est utilisée au moment de la dépense.

Le débat porte donc sur la valeur de la limite choisie et sur la nécessité d’inscrire cette contrainte dans le consensus plutôt que de laisser les utilisateurs arbitrer selon leurs besoins et les frais qu’ils sont disposés à payer.

Sixième mesure : interdire les opcodes OP_SUCCESS* dans les Tapscripts

La sixième règle vise les opcodes désignés collectivement sous le nom d’OP_SUCCESS*. Ces opcodes sont réservés dans Tapscript afin de permettre de futures évolutions du langage Bitcoin Script.

Avec les règles actuelles du BIP-342, la présence d’un opcode OP_SUCCESS* rencontré pendant l’analyse d’un Tapscript entraîne immédiatement la réussite de son exécution. Ce comportement a été conçu pour qu’un futur soft fork puisse attribuer de nouvelles conditions à ces opcodes sans rendre valides des dépenses auparavant invalides.

Le BIP-110 rendrait invalide tout Tapscript contenant un opcode OP_SUCCESS*, même lorsque celui-ci se trouve dans une branche qui ne serait jamais exécutée.

Cette précision est importante. La règle ne se contente pas d’interdire l’exécution de l’opcode. Elle recherche sa présence dans l’ensemble du Tapscript révélé. Un OP_SUCCESS* dissimulé derrière une condition fausse resterait donc interdit.

Pourquoi examiner également les branches non exécutées

Les inscriptions peuvent placer des données ou des instructions dans une branche conditionnelle qui n’est pas exécutée lors de la validation. Le script reste révélé dans le Witness et enregistré dans la blockchain, mais une partie de son contenu n’influence pas directement le résultat de la dépense.

Si le BIP-110 interdisait uniquement les OP_SUCCESS* réellement exécutés, il serait possible de les placer dans une branche inactive. La proposition choisit donc une règle syntaxique : leur simple présence dans le Tapscript suffit à rendre la dépense invalide.

Les défenseurs du BIP veulent ainsi protéger les opcodes réservés et empêcher leur utilisation comme marqueurs ou éléments de constructions destinées au stockage.

Les opposants estiment au contraire que ces opcodes constituent un mécanisme d’extensibilité volontairement intégré à Taproot. Leur neutralisation temporaire pourrait réduire les possibilités d’expérimentation ou compliquer certaines propositions d’évolution du langage Script.

Septième mesure : interdire l’exécution de OP_IF et OP_NOTIF dans les Tapscripts

La septième règle concerne les instructions conditionnelles OP_IF et OP_NOTIF dans Tapscript.

OP_IF permet d’exécuter une partie du script lorsqu’une condition est vraie. OP_NOTIF applique le principe inverse et exécute la branche concernée lorsque la condition est fausse.

Ces instructions rendent possible la présence de portions de script qui ne sont pas exécutées lors d’une dépense donnée. Les protocoles d’inscription peuvent exploiter ces enveloppes conditionnelles pour inclure des données dans le Tapscript sans que leur contenu ne soit traité comme une suite d’instructions devant produire un résultat utile.

Le BIP-110 rendrait invalide un Tapscript qui exécute une instruction OP_IF ou OP_NOTIF, quel que soit le résultat de la condition.

La distinction avec la règle sur les OP_SUCCESS* doit être conservée. Pour les OP_SUCCESS*, leur présence n’importe où dans le Tapscript suffit. Pour OP_IF et OP_NOTIF, la spécification vise leur exécution.

Une restriction importante pour les inscriptions par enveloppe

Les inscriptions Ordinals utilisent notamment une structure conditionnelle communément décrite comme une enveloppe. Des données sont placées dans une branche précédée par une condition qui évite leur exécution comme instructions ordinaires.

En interdisant l’exécution de OP_IF et OP_NOTIF dans les Tapscripts soumis aux nouvelles règles, le BIP-110 vise directement ce mécanisme de construction.

La mesure ne se limite toutefois pas aux inscriptions. Elle affecterait également tout nouveau Tapscript utilisant légitimement ces opérations conditionnelles pendant la période du soft fork.

C’est l’une des raisons pour lesquelles cette règle fait partie des dispositions les plus controversées. Les critiques estiment qu’elle ne se contente pas de limiter la taille des données, mais retire temporairement une capacité générale du langage Tapscript.

Les partisans répondent que les constructions conditionnelles peuvent souvent être remplacées par plusieurs feuilles dans un arbre Taproot. Chaque condition de dépense peut alors être placée dans une branche distincte, et seule la branche utilisée est révélée.

Huitième mesure : protéger les UTXO créés avant l’activation

La huitième mesure n’est pas une restriction supplémentaire appliquée aux transactions. Il s’agit d’une clause de protection appelée UTXO grandfathering, que l’on peut traduire par maintien des droits acquis pour les UTXO existants.

Les entrées dépensant des UTXO créés avant la hauteur d’activation seraient exemptées de l’ensemble des nouvelles règles du BIP-110.

Une sortie confirmée avant l’activation pourrait donc être dépensée exactement selon les conditions qui existaient au moment de sa création, même si son script, son Witness ou sa méthode de dépense ne respecte pas les nouvelles restrictions temporaires.

Cette protection évite qu’une sortie déjà existante devienne bloquée ou pratiquement impossible à dépenser après l’activation. Sans elle, certains utilisateurs pourraient découvrir que des bitcoins reçus avant le soft fork ne sont plus dépensables conformément aux règles prévues lors de leur création.

Les nouvelles règles s’appliqueraient uniquement aux UTXO créés à partir de la hauteur d’activation. Les utilisateurs seraient ainsi informés du nouveau cadre au moment où ils créent ou acceptent ces nouvelles sorties.

Une protection déterminée sortie par sortie

Le bénéfice de cette exemption dépend de la hauteur à laquelle l’UTXO dépensé a été créé. Ce n’est pas la date de création du portefeuille, de la clé ou de la transaction de dépense qui importe, mais la confirmation de la sortie utilisée comme entrée.

Lorsqu’un ancien UTXO est dépensé après l’activation, les nouvelles sorties produites par cette transaction sont créées après la hauteur d’activation. Elles sont donc soumises aux règles du BIP-110 lors de leur dépense ultérieure.

Le mécanisme ne permet donc pas de transmettre indéfiniment l’exemption d’une transaction à l’autre. Il garantit uniquement que les sorties déjà existantes au moment du changement peuvent être dépensées sans modification rétroactive de leurs conditions.

Ce qui se produit à l’expiration du soft fork

Le BIP-110 est conçu comme un soft fork temporaire d’environ une année. Lorsque son déploiement arrive à expiration, les UTXO de toutes les hauteurs redeviennent dépensables selon les règles générales du protocole, sans les restrictions temporaires introduites par la proposition.

Une sortie créée après l’activation et temporairement impossible à dépenser en raison du BIP-110 ne serait donc pas nécessairement détruite. Elle pourrait redevenir dépensable après l’expiration, à condition qu’aucune autre modification du consensus ne prolonge ou ne remplace les restrictions.

Cette distinction reste néanmoins importante pour les utilisateurs. Pendant toute la durée du déploiement, une sortie incompatible créée après l’activation pourrait rester immobilisée, même si elle devait redevenir utilisable ultérieurement.

Pourquoi ces huit mesures doivent être examinées ensemble

Les différentes mesures du BIP-110 ne poursuivent pas exactement la même fonction. Certaines limitent la taille des données. D’autres neutralisent temporairement des mécanismes d’extension ou des structures de Taproot. La protection des anciens UTXO vise pour sa part à éviter tout effet rétroactif sur des bitcoins déjà reçus.

Leur combinaison cherche à empêcher qu’une restriction isolée soit immédiatement contournée en déplaçant les données vers une autre partie de la transaction. Limiter les charges utiles OP_PUSHDATA sans traiter l’Annex, les versions inconnues ou les structures de Tapscript laisserait plusieurs voies alternatives disponibles.

La proposition ne garantit cependant pas la disparition de toute donnée arbitraire. Des utilisateurs pourraient encore encoder des informations dans des clés publiques, des signatures, des choix de sorties, des montants ou de nombreux fragments de petite taille.

Le véritable objectif du BIP-110 consiste à empêcher l’insertion simple et standardisée de grandes quantités de données contiguës. Ses auteurs espèrent ainsi augmenter suffisamment le coût et la complexité de ces pratiques pour réduire leur industrialisation.

Ses opposants considèrent au contraire que ces règles ajoutent de la complexité au consensus, réduisent certaines possibilités de programmation et interviennent dans le choix des usages admis sur Bitcoin. Pour eux, les frais et la capacité limitée des blocs doivent rester les principaux mécanismes d’arbitrage entre les transactions concurrentes.

Le débat ne porte donc pas seulement sur les inscriptions. Il concerne la neutralité de Bitcoin, la portée acceptable des règles de consensus et la responsabilité des utilisateurs dans l’utilisation d’un espace de blocs nécessairement limité.

Pourquoi le BIP-110 ne peut pas interdire totalement le stockage de données

Le document officiel reconnaît lui-même une réalité fondamentale : il est pratiquement impossible d’empêcher complètement le stockage arbitraire dans Bitcoin.

Une donnée peut être cachée de nombreuses façons. Elle peut être répartie dans plusieurs champs, encodée sous une autre forme ou intégrée dans des structures prévues initialement pour d’autres usages. Dès lors qu’une transaction transporte des octets, certains de ces octets peuvent toujours représenter une information extérieure au protocole.

Cette observation explique pourquoi le BIP-110 ne promet jamais une suppression totale des inscriptions ou du stockage de fichiers. Son ambition est beaucoup plus limitée.

Son auteur cherche avant tout à modifier les incitations économiques. Si le stockage devient plus complexe, plus coûteux et moins performant, une partie des utilisateurs abandonnera naturellement cette utilisation au profit de solutions mieux adaptées.

Le principe du coût plutôt que l’interdiction absolue

Cette philosophie revient régulièrement dans l’ensemble du document. Le BIP-110 ne cherche pas à créer une police du contenu. Il ne demande jamais aux nœuds d’identifier une image, un NFT, un document ou un jeton.

À la place, il augmente le coût technique de certaines méthodes. Les développeurs qui souhaitent continuer à stocker des données peuvent toujours le faire, mais leur solution devient moins simple à développer, moins efficace et souvent plus coûteuse à utiliser.

Les défenseurs de la proposition estiment que cette approche respecte davantage la neutralité du protocole qu’une analyse du contenu des transactions. Le logiciel ne juge jamais la nature des données. Il applique uniquement des règles de validation identiques pour tous.

Les critiques : une efficacité jugée insuffisante

Les opposants au BIP-110 ne contestent généralement pas le fonctionnement technique de ces restrictions. Leur principale critique porte sur leur efficacité réelle.

Selon eux, un développeur suffisamment motivé trouvera toujours une nouvelle méthode pour contourner les limitations. Si une structure devient inaccessible, une autre pourra être utilisée. Bitcoin n’a jamais été conçu pour empêcher totalement le transport de données arbitraires.

Ils soulignent également qu’un protocole populaire peut rapidement adapter ses logiciels. Les coûts supplémentaires finissent alors par être absorbés, sans faire disparaître l’usage concerné.

Pour cette raison, plusieurs développeurs estiment que le BIP-110 risque surtout de déplacer le problème plutôt que de le résoudre définitivement.

Les partisans répondent qu’il ne s’agit pas d’une course sans fin

Les auteurs favorables au BIP-110 répondent que cette critique repose sur un faux objectif. Leur proposition n’a jamais eu pour ambition de rendre impossible toute inscription dans Bitcoin.

Selon eux, la véritable question consiste à savoir quelles utilisations le protocole choisit de rendre simples, efficaces et officiellement compatibles avec son évolution. Une différence existe entre une utilisation possible et une utilisation encouragée.

Dans cette vision, le rôle du consensus consiste précisément à protéger les usages considérés comme fondamentaux pour Bitcoin. Les autres usages restent techniquement possibles, mais ils ne doivent pas bénéficier d’un traitement qui facilite leur développement au détriment de la fonction monétaire.

Cette divergence de philosophie explique pourquoi le débat autour du BIP-110 dépasse largement les aspects techniques. Les mêmes règles peuvent être interprétées comme une protection nécessaire ou comme une restriction inutile, selon la manière dont chacun conçoit la mission du protocole Bitcoin.

Le BIP-110 modifie-t-il réellement Bitcoin ?

À ce stade, une question revient souvent : le BIP-110 change-t-il profondément le fonctionnement de Bitcoin ? La réponse dépend du point de vue adopté.

Sur le plan monétaire, la réponse est clairement non. Le BIP-110 ne modifie ni la limite des 21 millions de bitcoins, ni le rythme d’émission, ni la preuve de travail, ni les règles de validation des signatures. Les mécanismes fondamentaux qui assurent le fonctionnement de Bitcoin restent identiques.

En revanche, la proposition modifie bien les règles qui déterminent quelles transactions peuvent être incluses dans un bloc pendant la durée du soft fork. Certaines transactions aujourd’hui considérées comme valides deviendraient temporairement invalides si elles ne respectaient plus les nouvelles limites.

C’est précisément cette modification des règles de consensus qui explique l’importance du débat. Même si les changements semblent limités, ils concernent directement la définition d’une transaction valide.

Pourquoi le BIP-110 est bien un soft fork

Le BIP-110 est présenté comme un soft fork. Cette notion désigne une évolution qui ajoute de nouvelles contraintes sans remettre en cause les anciennes règles fondamentales du protocole.

Avant l’activation, certaines transactions respectent les règles actuelles. Après l’activation, ces mêmes transactions pourraient être rejetées si elles dépassent les nouvelles limites prévues par le BIP-110.

Autrement dit, le nombre de transactions considérées comme valides diminue temporairement. Aucun nouveau type de transaction n’est créé. Ce sont uniquement certaines transactions existantes qui cesseraient d’être acceptées.

Cette caractéristique correspond exactement à la définition d’un soft fork : restreindre les règles de validation sans élargir les possibilités offertes par le protocole.

Pourquoi les portefeuilles Bitcoin sont concernés

Même si la majorité des utilisateurs ne manipule jamais directement les scripts Bitcoin, les développeurs de portefeuilles devraient tenir compte du BIP-110 si celui-ci était adopté.

Un portefeuille qui construirait une transaction dépassant les nouvelles limites verrait cette transaction refusée par les nœuds appliquant le soft fork. Les développeurs devraient donc vérifier que leurs logiciels continuent de produire uniquement des transactions conformes aux nouvelles règles.

Pour les portefeuilles classiques utilisés uniquement pour envoyer et recevoir des bitcoins, l’impact serait probablement très faible. En revanche, certaines applications spécialisées exploitant des scripts complexes ou des protocoles de stockage pourraient devoir adapter leur fonctionnement.

Les applications utilisant des inscriptions seraient les plus concernées

Les logiciels développés autour des inscriptions, des NFT sur Bitcoin ou de certains protocoles utilisant de grandes quantités de données seraient naturellement les premiers concernés par ces nouvelles restrictions.

Dans plusieurs cas, ils devraient modifier leur manière de construire les transactions. Certains devraient fragmenter davantage les données. D’autres devraient rechercher des méthodes totalement différentes pour continuer à fonctionner.

Les auteurs du BIP-110 considèrent que cette adaptation fait précisément partie de l’objectif recherché. Les opposants estiment au contraire qu’elle risque de pénaliser des innovations sans apporter de bénéfice suffisant au réseau.

Un changement limité dans le temps

L’une des particularités du BIP-110 est son caractère temporaire. Contrairement à la plupart des soft forks déployés sur Bitcoin, celui-ci ne vise pas à modifier définitivement les règles du protocole.

Le document prévoit une durée d’application de 52 416 blocs, soit environ une année dans des conditions normales de fonctionnement du réseau.

À l’issue de cette période, les restrictions cesseraient automatiquement de produire leurs effets. Les règles de consensus reviendraient alors à leur état précédent, sauf si une nouvelle proposition venait entre-temps remplacer ou prolonger le dispositif.

Cette approche est inhabituelle dans l’histoire de Bitcoin. Elle transforme le BIP-110 en une sorte de période d’expérimentation destinée à observer les conséquences réelles de ces limitations avant toute décision plus durable.

Le chapitre suivant abordera justement cette question. Nous verrons comment le BIP-110 prévoit son activation, pourquoi son mécanisme de déploiement suscite lui aussi des débats et quelles sont les conditions nécessaires pour qu’un tel soft fork puisse réellement entrer en vigueur sur le réseau Bitcoin.

Chapitre 4

Comment le BIP-110 pourrait être activé sur Bitcoin

Après avoir étudié les différentes restrictions techniques proposées par le BIP-110, une autre question devient essentielle. Même si cette proposition est techniquement solide, comment pourrait-elle réellement entrer en vigueur sur le réseau Bitcoin ?

Contrairement à une idée largement répandue, aucun développeur ne peut modifier seul les règles de Bitcoin. Publier un BIP sur Internet ne change absolument rien au fonctionnement du réseau. Pour qu’une proposition devienne une règle de consensus, elle doit être adoptée progressivement par l’ensemble des acteurs de l’écosystème.

Cette gouvernance décentralisée constitue l’une des principales forces de Bitcoin. Aucun gouvernement, aucune entreprise et aucun développeur ne possède le pouvoir d’imposer un changement à l’ensemble du réseau.

Un BIP n’est pas une mise à jour automatique

Le terme Bitcoin Improvement Proposal, ou BIP, peut parfois prêter à confusion. Il ne désigne pas une nouvelle règle appliquée automatiquement. Il s’agit simplement d’un document technique qui décrit une idée, explique son fonctionnement et justifie son intérêt.

La publication d’un BIP ne modifie donc jamais Bitcoin. De nombreuses propositions restent à l’état de discussion pendant plusieurs années. Certaines sont finalement abandonnées, tandis que d’autres évoluent profondément avant d’être éventuellement intégrées au logiciel.

Le BIP-110 suit exactement ce processus. Tant qu’il n’est pas adopté par les différents participants du réseau, il demeure une proposition parmi d’autres.

Le rôle des développeurs

Les développeurs rédigent les propositions, écrivent le code et analysent leurs conséquences techniques. Leur travail consiste également à répondre aux critiques, corriger les éventuelles erreurs et améliorer progressivement le projet.

En revanche, ils ne disposent d’aucun pouvoir pour imposer leurs décisions au reste du réseau. Même si le code du BIP-110 était entièrement terminé, chaque opérateur de nœud resterait libre de l’installer ou non.

Cette distinction est fondamentale. Les développeurs proposent, mais ce sont les utilisateurs du réseau qui choisissent quelles règles ils souhaitent appliquer.

Le rôle des opérateurs de nœuds

Les nœuds complets jouent un rôle central dans Bitcoin. Ce sont eux qui vérifient chaque bloc, chaque transaction et chaque règle de consensus.

Si un opérateur décide d’installer une version de Bitcoin intégrant le BIP-110, son logiciel commencera à appliquer les nouvelles restrictions au moment prévu par la proposition.

À l’inverse, un opérateur qui conserve une ancienne version du logiciel continuera d’appliquer les règles actuelles. Cette liberté explique pourquoi toute modification du consensus demande une très large coordination entre les participants.

Pourquoi les mineurs sont également concernés

Les mineurs produisent les nouveaux blocs. Si une majorité d’entre eux adopte un nouveau soft fork, ils commenceront à construire uniquement des blocs respectant les nouvelles règles.

En revanche, si une partie importante des mineurs continue de produire des blocs incompatibles avec le nouveau consensus, une divergence peut apparaître entre différentes parties du réseau.

C’est précisément pour éviter ce type de situation que les procédures d’activation des soft forks font l’objet d’une attention particulière depuis plusieurs années.

Une activation ne dépend jamais d’un seul acteur

Bitcoin fonctionne grâce à un équilibre entre plusieurs catégories d’acteurs. Les développeurs écrivent le code. Les mineurs sécurisent la blockchain. Les opérateurs de nœuds appliquent les règles de consensus. Enfin, les entreprises, les plateformes d’échange, les portefeuilles et les utilisateurs choisissent les versions du logiciel qu’ils souhaitent utiliser.

Cette répartition des responsabilités explique pourquoi les évolutions importantes prennent souvent plusieurs mois, voire plusieurs années. Avant toute activation, la communauté cherche généralement à atteindre un niveau de consensus suffisamment élevé afin de limiter les risques de division.

Le BIP-110 ne fait pas exception. Au-delà de ses aspects techniques, son éventuelle adoption dépendra avant tout de la capacité de ses partisans à convaincre les différents acteurs du réseau que les bénéfices attendus sont supérieurs aux risques d’une modification du consensus.

Le calendrier prévu par le BIP-110

Le BIP-110 définit un calendrier précis reposant sur des hauteurs de blocs plutôt que sur des dates fixes. Cette approche garantit que toutes les étapes suivent le rythme naturel de production de la blockchain Bitcoin.

Une première phase de signalement volontaire a débuté le 1er décembre 2025. Pendant cette période, les mineurs pouvaient indiquer leur soutien en activant le bit 4 du champ de version des blocs. Aucun bloc n’était rejeté et cette phase avait uniquement pour objectif de mesurer le soutien réel du réseau.

Si le seuil requis n’est pas atteint durant la phase volontaire, le BIP-110 prévoit ensuite une phase plus contraignante à partir du bloc 961 632, estimé autour du 7 ou 8 août 2026.Selon le mécanisme proposé, les nœuds exécutant le BIP-110 commenceraient alors à refuser les blocs produits par des mineurs qui ne signalent pas le bit 4.

Le mécanisme fonctionne sur une fenêtre de 2 016 blocs, soit environ deux semaines, correspondant à un cycle complet d’ajustement de la difficulté de minage. Si les conditions prévues sont remplies, le BIP passe ensuite à l’état LOCKED_IN au bloc 963 648, avant une activation effective au bloc 965 664, prévue au début du mois de septembre 2026.

Le BIP-110 présente également une particularité rare : il ne s’agit pas d’un changement permanent. Les nouvelles règles expirent automatiquement au bloc 1 018 080, soit environ un an après leur activation. Cette durée limitée doit permettre à la communauté d’évaluer les effets de la proposition avant d’envisager une éventuelle solution permanente.

Pourquoi la période de signalisation est importante

La phase de signalisation ne sert pas uniquement à compter les votes des mineurs. Elle donne également du temps aux opérateurs de nœuds, aux développeurs de portefeuilles, aux plateformes d’échange et aux autres entreprises de l’écosystème pour préparer leurs logiciels.

Une modification des règles de consensus ne concerne pas seulement les mineurs. Tous les logiciels qui créent, relaient ou vérifient des transactions doivent s’assurer qu’ils appliquent exactement les mêmes règles au même moment.

Cette période permet aussi d’identifier d’éventuels problèmes techniques avant l’activation définitive. Si une erreur importante est découverte, le déploiement peut être reporté ou la proposition peut être modifiée.

Que se passe-t-il si le seuil n’est pas atteint ?

Si le niveau de soutien prévu par le BIP-110 n’est pas atteint pendant la période de signalisation, aucune nouvelle règle n’est appliquée. Bitcoin continue alors de fonctionner exactement comme auparavant.

Ce scénario n’a rien d’exceptionnel. Dans l’histoire de Bitcoin, plusieurs propositions n’ont jamais été activées faute d’un consensus suffisant. Certaines ont ensuite été abandonnées. D’autres ont été profondément réécrites avant d’être soumises à nouveau.

Le BIP-110 suit la même logique. Son avenir dépend avant tout de l’adhésion qu’il suscitera au sein de la communauté Bitcoin.

Pourquoi certains refusent le principe même de la signalisation des mineurs

La méthode d’activation constitue elle aussi un sujet de débat. Certains membres de la communauté estiment que les mineurs ne devraient pas disposer d’un rôle déterminant dans l’adoption des règles de consensus.

Selon cette vision, les véritables arbitres du consensus sont les opérateurs de nœuds. Ce sont eux qui décident finalement quels blocs ils acceptent ou rejettent. Les mineurs ne feraient alors que produire des blocs conformes aux règles choisies par les utilisateurs.

D’autres considèrent au contraire qu’une forte adhésion des mineurs reste indispensable pour limiter les risques de perturbation du réseau lors de l’activation d’un soft fork.

Cette opposition n’est pas propre au BIP-110. Elle accompagne depuis de nombreuses années les discussions autour de la gouvernance de Bitcoin et de la manière la plus sûre de faire évoluer le protocole.

Le précédent de SegWit influence encore les débats

Les discussions autour du BIP-110 rappellent inévitablement celles qui ont précédé l’activation de SegWit en 2017. À cette époque, les désaccords portaient déjà sur les règles de consensus, le rôle des mineurs et la meilleure méthode d’activation.

L’histoire de SegWit a laissé une empreinte durable dans la communauté Bitcoin. Depuis lors, chaque nouveau soft fork est analysé avec beaucoup d’attention, non seulement pour son contenu technique, mais aussi pour sa procédure d’activation et les conséquences qu’elle pourrait avoir sur la stabilité du réseau.

Le BIP-110 s’inscrit pleinement dans cette continuité. Au-delà des restrictions qu’il propose, il relance une question fondamentale : comment faire évoluer Bitcoin sans fragiliser le consensus qui garantit sa sécurité depuis plus de quinze ans ?

L’activation suffit-elle pour que le BIP-110 soit adopté ?

Une erreur fréquente consiste à croire qu’un soft fork devient automatiquement accepté dès que les conditions d’activation sont réunies. En réalité, l’activation technique ne marque que le début de son application. Son adoption réelle dépend ensuite du comportement de l’ensemble de l’écosystème Bitcoin.

Les opérateurs de nœuds doivent installer une version du logiciel intégrant les nouvelles règles. Les mineurs doivent produire des blocs compatibles avec ces règles. Les portefeuilles, les plateformes d’échange et les autres services doivent également vérifier que leurs logiciels continuent de fonctionner correctement.

Si une partie importante de l’écosystème refuse volontairement le changement, des tensions peuvent apparaître. Même lorsqu’un soft fork est techniquement prêt, son succès dépend toujours de l’adhésion de la communauté.

Le risque d’une chaîne minoritaire

Lorsqu’un désaccord important apparaît sur les règles de consensus, un risque théorique existe : celui de voir deux groupes appliquer des règles différentes. Les nœuds exécutant le BIP-110 rejetteraient certaines transactions considérées comme valides par les nœuds restés sur les anciennes règles.

Si une part suffisante de la puissance de calcul soutient chacune de ces visions, deux chaînes distinctes pourraient temporairement coexister. Chaque groupe considérerait alors que sa propre chaîne représente le véritable Bitcoin.

Un tel scénario reste peu souhaitable. Il peut provoquer de la confusion chez les utilisateurs, compliquer le travail des plateformes d’échange et fragiliser temporairement la sécurité économique du réseau.

C’est précisément pour éviter ce type de situation que les développeurs recherchent généralement un consensus aussi large que possible avant toute modification importante des règles de consensus.

Pourquoi le BIP-110 prévoit une durée limitée

L’une des particularités du BIP-110 réside dans son caractère temporaire. Contrairement aux précédents soft forks majeurs de Bitcoin, cette proposition ne cherche pas à modifier définitivement le protocole.

Le document prévoit une période d’application d’environ douze mois, soit 52 416 blocs. Une fois cette période terminée, les restrictions cesseraient automatiquement de s’appliquer.

Selon l’auteur du BIP, cette approche permettrait d’observer les conséquences réelles de ces limitations sans engager immédiatement Bitcoin dans un changement permanent. Les développeurs pourraient ensuite analyser les résultats avant de proposer, si nécessaire, une nouvelle évolution.

Les opposants considèrent toutefois que cette solution crée une période d’incertitude. Les développeurs d’applications devraient adapter leurs logiciels pendant un an, puis éventuellement revenir aux anciennes règles si aucune nouvelle proposition n’était adoptée.

Le mécanisme d’expiration automatique

À l’expiration du délai prévu par le BIP-110, les règles supplémentaires disparaîtraient automatiquement. Les transactions redeviendraient soumises aux règles normales de consensus, sans intervention particulière des opérateurs de nœuds.

Cette expiration automatique distingue le BIP-110 de la plupart des évolutions précédentes de Bitcoin. Habituellement, un soft fork ajoute de nouvelles règles destinées à rester en vigueur de manière permanente. Ici, l’objectif est de créer une période d’expérimentation limitée dans le temps.

Cette approche reste inhabituelle dans l’histoire du protocole. Elle explique pourquoi le BIP-110 suscite autant de discussions, non seulement sur son contenu technique, mais aussi sur sa philosophie générale.

Le chapitre suivant

Nous avons désormais étudié le fonctionnement technique du BIP-110 ainsi que son mécanisme d’activation. Il reste cependant une question essentielle : quels seraient concrètement les effets de cette proposition sur les différents acteurs de l’écosystème Bitcoin ?

Le chapitre suivant analysera les conséquences potentielles du BIP-110 pour les utilisateurs, les mineurs, les opérateurs de nœuds, les développeurs, les plateformes d’échange et les protocoles utilisant aujourd’hui les inscriptions. Nous verrons également quels arguments avancent les partisans et les opposants concernant l’impact économique de cette proposition.

Chapitre 5

Les conséquences possibles du BIP-110 sur l’écosystème Bitcoin

Les aspects techniques du BIP-110 ne représentent qu’une partie du débat. Une fois les nouvelles règles comprises, une autre question apparaît naturellement : quelles seraient leurs conséquences concrètes sur les différents acteurs de l’écosystème Bitcoin ?

Les réponses diffèrent fortement selon les personnes interrogées. Les partisans du BIP-110 estiment que la proposition renforcerait la vocation monétaire de Bitcoin et limiterait les usages qui augmentent inutilement la pression sur l’espace des blocs. Les opposants considèrent au contraire que cette évolution pourrait freiner certaines innovations sans résoudre durablement le problème du stockage de données arbitraires.

Pour comprendre ces divergences, il faut examiner séparément les conséquences potentielles pour chaque catégorie d’acteurs.

Les utilisateurs qui effectuent simplement des paiements

Pour un utilisateur qui achète, vend ou transfère simplement des bitcoins, le BIP-110 aurait probablement un impact très limité. Les formats de transactions utilisés quotidiennement par les portefeuilles modernes respectent déjà les limites prévues par la proposition.

Autrement dit, envoyer des bitcoins entre deux adresses SegWit ou Taproot continuerait à fonctionner normalement. Les signatures, les clés publiques et les scripts utilisés par les paiements classiques restent largement en dessous des seuils fixés par le BIP.

Pour cette catégorie d’utilisateurs, le changement serait donc presque invisible. Beaucoup pourraient même ne jamais remarquer que les règles de consensus ont évolué.

Les opérateurs de nœuds complets

Les opérateurs de nœuds figurent parmi les principaux bénéficiaires mis en avant par les auteurs du BIP-110. Selon eux, limiter certaines structures de données permettrait de ralentir la croissance de l’ensemble UTXO et de réduire certains coûts liés à la validation des transactions.

Un nœud complet télécharge, vérifie et conserve l’intégralité des blocs de Bitcoin. Toute augmentation de la taille des données ou de la complexité des scripts se répercute directement sur les ressources nécessaires pour faire fonctionner ce nœud.

Les défenseurs du BIP-110 considèrent donc que ces limitations contribueraient à préserver la décentralisation du réseau en évitant que le coût d’exploitation d’un nœud augmente plus rapidement que nécessaire.

Les opposants répondent que la croissance maximale des blocs reste déjà limitée par le consensus actuel. Selon eux, la quantité totale de données ne changerait pas fondamentalement, quelle que soit leur nature.

Les mineurs

La situation des mineurs est plus complexe. Aujourd’hui, les inscriptions et les autres formes de stockage arbitraire génèrent parfois des frais de transaction très élevés. Ces frais constituent une source de revenus supplémentaire pour les mineurs.

Si le BIP-110 réduisait effectivement ce type d’activité, une partie de ces revenus pourrait disparaître. Les opposants rappellent que, sur le long terme, les frais de transaction devront progressivement remplacer la subvention versée à chaque nouveau bloc.

Les défenseurs du BIP-110 répondent que les revenus des mineurs ne devraient pas dépendre principalement d’activités sans lien avec les paiements. Selon eux, un marché des frais fondé sur les usages monétaires représente un modèle plus sain et plus cohérent avec les objectifs initiaux de Bitcoin.

Les développeurs d’applications

Les développeurs utilisant uniquement les fonctionnalités classiques de Bitcoin ne seraient probablement que très peu affectés. En revanche, les projets exploitant les inscriptions, les NFT ou d’autres protocoles reposant sur de grandes quantités de données devraient adapter leurs logiciels.

Dans certains cas, une simple modification du format des transactions pourrait suffire. Dans d’autres, une refonte beaucoup plus importante serait nécessaire afin de contourner les nouvelles restrictions ou d’adopter une approche totalement différente.

C’est précisément sur ce point que les deux camps s’opposent. Les partisans du BIP considèrent cette adaptation comme normale. Les opposants y voient un frein inutile à l’innovation.

Les plateformes d’échange et les entreprises Bitcoin

Les plateformes d’échange, les services de conservation et les entreprises qui utilisent Bitcoin pour les paiements seraient probablement peu affectés par le BIP-110. La très grande majorité de leurs transactions correspondent déjà aux formats standards prévus par le protocole.

Leurs logiciels devraient néanmoins être mis à jour afin de vérifier que toutes les transactions créées respectent les nouvelles règles de consensus pendant la durée du soft fork. Cette adaptation représenterait principalement un travail de développement et de tests.

Pour les entreprises spécialisées dans les inscriptions ou les protocoles reposant sur le stockage de données arbitraires, la situation serait différente. Certaines devraient modifier profondément leur infrastructure, tandis que d’autres pourraient remettre en question leur modèle économique.

Les protocoles d’inscriptions seraient les premiers concernés

Les protocoles utilisant les inscriptions constituent naturellement les principaux acteurs visés par le BIP-110. Depuis l’apparition d’Ordinals en 2022, plusieurs projets permettent d’enregistrer des images, des textes, des applications ou différents types de jetons directement dans la blockchain Bitcoin.

Ces protocoles exploitent les possibilités offertes par les règles actuelles de consensus. Ils ne violent donc pas les règles de Bitcoin. Les transactions qu’ils produisent sont aujourd’hui parfaitement valides.

Le BIP-110 ne remet pas en cause leur existence passée. En revanche, il modifierait les règles applicables aux nouvelles transactions pendant la durée du soft fork. Les développeurs de ces protocoles devraient donc adapter leurs méthodes de stockage ou rechercher d’autres solutions techniques.

Le marché des frais pourrait-il évoluer ?

L’un des arguments les plus discutés concerne le marché des frais de transaction. Depuis plusieurs années, les inscriptions ont parfois provoqué une forte augmentation de la demande d’espace dans les blocs. Cette demande s’est traduite par une hausse temporaire des frais payés aux mineurs.

Les opposants au BIP-110 estiment qu’une diminution de cette activité pourrait réduire les revenus des mineurs. Selon eux, un marché des frais dynamique devient de plus en plus important à mesure que la récompense de bloc diminue avec les halvings successifs.

Les défenseurs du BIP répondent que cette analyse ne tient pas compte de la qualité de la demande. À leurs yeux, Bitcoin ne doit pas dépendre durablement d’une activité de stockage de fichiers pour financer sa sécurité. Ils considèrent qu’un marché des frais alimenté principalement par les paiements constitue un modèle plus robuste sur le long terme.

Une influence sur la croissance de la blockchain

Le BIP-110 pourrait également influencer la nature des données enregistrées dans la blockchain. Si les restrictions proposées réduisent effectivement le nombre d’inscriptions volumineuses, une plus grande partie de l’espace disponible serait utilisée par des transactions financières classiques.

Il est toutefois important de distinguer deux notions. Le BIP-110 ne réduit pas la taille maximale des blocs. Il modifie uniquement les types de structures que ces blocs peuvent contenir. La croissance globale de la blockchain resterait donc encadrée par les limites actuelles du protocole.

Le véritable débat porte davantage sur la nature des données stockées que sur leur volume total.

Une question de philosophie plus que de technique

À ce stade, un constat s’impose. Les conséquences du BIP-110 ne peuvent pas être évaluées uniquement à travers des critères techniques. Elles dépendent également de la manière dont chacun définit la mission de Bitcoin.

Pour certains, Bitcoin doit rester avant tout un système monétaire décentralisé. Toute évolution qui renforce cette fonction mérite donc d’être étudiée. Pour d’autres, la neutralité du protocole implique de ne pas privilégier un usage plutôt qu’un autre dès lors que les utilisateurs respectent les règles de consensus et paient les frais correspondants.

Cette opposition explique pourquoi les discussions autour du BIP-110 dépassent largement le cadre technique. Elles touchent directement à la vision que chacun se fait de l’avenir de Bitcoin.

📢 Le Fil des Infos Essentielles sur Bitcoin⚡

Chapitre 6

Les arguments des partisans et des opposants au BIP-110

Depuis sa publication, le BIP-110 a suscité de nombreuses réactions au sein de la communauté Bitcoin. Contrairement à d’autres propositions plus techniques, il touche directement à la manière dont chacun perçoit la mission du protocole. Les discussions dépassent donc largement les questions de programmation.

Les deux camps s’accordent sur un point : Bitcoin doit rester un réseau robuste, décentralisé et sécurisé. En revanche, ils divergent profondément sur les moyens d’atteindre cet objectif.

Pourquoi certains soutiennent le BIP-110

Les défenseurs du BIP-110 estiment que Bitcoin a été conçu avant tout comme un système monétaire pair à pair. Selon eux, les règles de consensus doivent continuer à protéger cette fonction essentielle.

Ils rappellent que l’espace disponible dans chaque bloc constitue une ressource limitée. Toute utilisation de cet espace pour enregistrer des données sans fonction monétaire réduit mécaniquement la place disponible pour les transactions financières.

À leurs yeux, le problème ne réside pas dans l’existence de quelques inscriptions isolées. Leur inquiétude concerne plutôt la possibilité qu’un usage massif du stockage de fichiers devienne une activité durable et dominante sur Bitcoin.

Ils considèrent également que les règles actuelles facilitent involontairement cette évolution. Le BIP-110 chercherait donc à corriger certaines incitations sans modifier les fondements du protocole.

Préserver la décentralisation des nœuds

Un autre argument fréquemment avancé concerne le coût d’exploitation des nœuds complets. Chaque bloc doit être téléchargé, vérifié puis conservé par des milliers d’ordinateurs répartis dans le monde.

Selon les partisans du BIP-110, limiter certaines formes de stockage contribue à ralentir la croissance des ressources nécessaires pour exploiter un nœud. Si le coût d’exploitation reste raisonnable, davantage de particuliers pourront continuer à participer directement à la validation du réseau.

Ils considèrent que cette décentralisation représente l’une des principales garanties de sécurité de Bitcoin. Toute évolution susceptible d’augmenter inutilement les exigences matérielles doit donc être examinée avec prudence.

Pourquoi d’autres s’opposent au BIP-110

Les opposants ne contestent pas nécessairement les objectifs poursuivis par le BIP-110. Beaucoup partagent l’idée que Bitcoin est avant tout une monnaie. En revanche, ils estiment que la méthode proposée pose davantage de problèmes qu’elle n’en résout.

Selon eux, Bitcoin ne doit pas distinguer les usages de l’espace des blocs. Une transaction qui respecte les règles de consensus et paie les frais demandés doit être traitée comme n’importe quelle autre transaction, quelle que soit la nature des données qu’elle transporte.

Ils rappellent également que le protocole ne connaît pas la signification des données. Pour Bitcoin, une image, une signature ou un document restent simplement des suites d’octets. Introduire des restrictions visant indirectement certains usages reviendrait, selon eux, à affaiblir la neutralité du réseau.

Le marché des frais doit-il décider seul ?

L’un des principaux arguments des opposants repose sur le fonctionnement du marché des frais. Bitcoin dispose déjà d’un mécanisme permettant de sélectionner les transactions : celui qui souhaite être confirmé rapidement paie davantage.

Dans cette logique, le protocole n’a pas à choisir quels usages méritent l’espace disponible. Les utilisateurs décident eux-mêmes en fonction des frais qu’ils acceptent de payer, tandis que les mineurs sélectionnent naturellement les transactions les plus rémunératrices.

Les défenseurs du BIP-110 répondent que ce raisonnement ne prend pas suffisamment en compte les coûts supportés par les opérateurs de nœuds. Selon eux, les frais rémunèrent essentiellement les mineurs, alors que tous les nœuds doivent conserver et vérifier les données enregistrées dans la blockchain.

Le risque d’un précédent

Enfin, plusieurs développeurs expriment une inquiétude plus générale. Si Bitcoin commence à interdire certaines utilisations de l’espace des blocs, où placer la limite ?

Aujourd’hui, le débat concerne principalement les inscriptions. Demain, une majorité pourrait vouloir restreindre d’autres catégories de transactions jugées indésirables. Pour ces opposants, la neutralité du protocole constitue une protection contre ce type d’évolution.

Les partisans du BIP-110 répondent que Bitcoin applique déjà de nombreuses restrictions techniques. À leurs yeux, ajouter quelques limites supplémentaires pour préserver la fonction monétaire ne crée pas un précédent fondamentalement différent des règles déjà présentes dans le protocole.

Cette divergence explique pourquoi le débat autour du BIP-110 reste aussi intense. Il ne porte pas uniquement sur des limites de taille ou sur quelques opcodes. Il interroge la manière dont Bitcoin devra évoluer au cours des prochaines décennies et la place que ses utilisateurs souhaitent lui donner.

Chapitre 7

Les critiques techniques adressées au BIP-110

Au-delà des débats philosophiques, le BIP-110 fait également l’objet de nombreuses critiques techniques. Plusieurs développeurs reconnaissent que la proposition est cohérente sur le plan de sa mise en œuvre, mais contestent son efficacité pratique ou ses conséquences à long terme.

Ces critiques ne proviennent pas uniquement de personnes favorables aux inscriptions. Elles sont également formulées par des développeurs qui considèrent que Bitcoin doit rester une monnaie, tout en estimant que le BIP-110 n’est pas la meilleure réponse au problème identifié.

Une solution qui pourrait être facilement contournée

L’une des objections les plus fréquentes concerne la capacité réelle du BIP-110 à empêcher le stockage de données arbitraires.

Depuis les premières discussions sur Bitcoin, les développeurs savent qu’il est pratiquement impossible d’interdire totalement l’enregistrement de données dans une blockchain publique. Toute transaction contient nécessairement des informations numériques, et il existe souvent plusieurs façons de représenter une même donnée.

Les opposants estiment donc que les développeurs de protocoles trouveraient rapidement d’autres méthodes pour contourner les nouvelles limites. Les données pourraient être fragmentées, réparties sur plusieurs transactions ou encodées différemment sans nécessairement violer les nouvelles règles de consensus.

Dans cette hypothèse, le BIP-110 compliquerait certaines pratiques sans réellement les faire disparaître.

Des restrictions qui pourraient pénaliser des usages légitimes

Une autre critique concerne les effets indirects de la proposition. Les limites introduites par le BIP-110 ne distinguent pas les usages jugés utiles de ceux considérés comme indésirables.

Une application parfaitement légitime utilisant des scripts inhabituels pourrait se retrouver limitée simplement parce qu’elle dépasse l’un des nouveaux seuils. Les développeurs devraient alors modifier leurs logiciels, non pas parce qu’ils abusent de Bitcoin, mais parce que les règles générales auraient changé.

Pour les opposants, cette approche risque donc d’introduire des contraintes supplémentaires sur des projets qui ne sont pas à l’origine du problème visé.

Le risque de figer l’innovation

Bitcoin évolue lentement, mais il continue d’évoluer. Au fil des années, plusieurs fonctionnalités aujourd’hui largement utilisées paraissaient inutiles ou marginales lors de leur introduction.

Les détracteurs du BIP-110 rappellent qu’il est difficile de prévoir les usages futurs d’un protocole mondial. Une restriction introduite aujourd’hui pourrait empêcher demain l’apparition d’une innovation encore inconnue.

Selon cette analyse, il vaut mieux conserver des règles générales et laisser les utilisateurs expérimenter de nouveaux usages, tant qu’ils respectent le consensus et assument le coût économique correspondant.

Le précédent créé par un soft fork temporaire

Le caractère temporaire du BIP-110 suscite également des interrogations. Dans l’histoire de Bitcoin, les modifications du consensus ont presque toujours été conçues comme des évolutions permanentes.

Certains développeurs s’interrogent donc sur les conséquences d’une règle qui disparaît automatiquement après une période déterminée. Ils craignent que cette approche rende les règles de consensus plus difficiles à anticiper pour les développeurs d’applications et les entreprises.

D’autres considèrent au contraire que cette durée limitée représente précisément l’intérêt du BIP-110, puisqu’elle permettrait d’observer les effets réels de la proposition avant toute décision définitive.

La neutralité du protocole reste au cœur des discussions

Derrière l’ensemble de ces critiques apparaît une question plus profonde : Bitcoin doit-il rester totalement neutre vis-à-vis des usages de son espace de blocs, ou peut-il introduire certaines limitations lorsqu’une majorité estime qu’elles servent l’intérêt général du réseau ?

Cette interrogation dépasse largement le cadre du BIP-110. Elle touche directement à la gouvernance informelle de Bitcoin, à la manière dont les règles évoluent et au rôle respectif des développeurs, des mineurs, des opérateurs de nœuds et des utilisateurs.

C’est pourquoi les discussions autour du BIP-110 sont souvent bien plus larges que le texte de la proposition lui-même. Elles interrogent la capacité de Bitcoin à évoluer tout en conservant les principes qui ont fait son succès depuis sa création.

Le chapitre suivant examinera précisément cette question de gouvernance. Nous verrons comment naissent les décisions sur Bitcoin, pourquoi aucun acteur ne peut imposer seul une évolution du protocole et en quoi le débat autour du BIP-110 illustre le fonctionnement particulier de cette gouvernance décentralisée.

Chapitre 8

Ce que le débat autour du BIP-110 révèle sur la gouvernance de Bitcoin

Le débat autour du BIP-110 dépasse largement la question des inscriptions ou des données arbitraires. Il constitue également un excellent exemple du fonctionnement de la gouvernance de Bitcoin, un système souvent mal compris par le grand public.

Contrairement à une entreprise ou à une administration, Bitcoin ne possède ni conseil d’administration, ni président, ni comité chargé de décider des évolutions du protocole. Aucun acteur ne dispose du pouvoir d’imposer une modification à l’ensemble du réseau.

Cette absence d’autorité centrale explique pourquoi certaines propositions mettent plusieurs années à être débattues, tandis que d’autres ne sont jamais adoptées.

Les BIP ne sont que des propositions

Le terme Bitcoin Improvement Proposal, ou BIP, peut parfois prêter à confusion. Il ne désigne pas une décision officielle, mais simplement un document décrivant une idée d’amélioration du protocole.

N’importe quel développeur peut rédiger une proposition, à condition qu’elle respecte les règles de présentation définies pour les BIP. Le simple fait qu’un texte reçoive un numéro ne signifie donc pas qu’il sera un jour intégré à Bitcoin.

Avant toute éventuelle adoption, une proposition fait généralement l’objet de nombreuses discussions publiques. Son auteur doit répondre aux critiques, corriger certains points techniques et parfois revoir entièrement son approche.

Le consensus ne se décrète pas

Le mot « consensus » est souvent utilisé à tort comme s’il désignait un vote officiel. En réalité, le consensus de Bitcoin correspond à une convergence progressive entre les différents acteurs du réseau.

Développeurs, opérateurs de nœuds, mineurs, entreprises, chercheurs, plateformes d’échange et utilisateurs peuvent tous exprimer leur opinion. Aucun groupe ne possède cependant le pouvoir de décider seul.

Une proposition qui rencontre une forte opposition a donc très peu de chances d’être activée, même si elle paraît techniquement solide.

Le rôle particulier des développeurs de Bitcoin Core

Les développeurs qui contribuent à Bitcoin Core jouent un rôle essentiel, mais souvent mal interprété. Ils écrivent du code, corrigent des erreurs, améliorent les performances et examinent les propositions soumises par d’autres développeurs.

En revanche, ils ne disposent d’aucun pouvoir pour obliger les utilisateurs à installer leurs modifications. Même lorsqu’une nouvelle version de Bitcoin Core est publiée, chacun reste libre de continuer à utiliser une version antérieure ou un autre logiciel compatible avec le protocole.

Cette liberté constitue l’un des fondements de la décentralisation de Bitcoin.

Les opérateurs de nœuds détiennent le dernier mot

Lorsqu’un opérateur installe un logiciel Bitcoin, il choisit en réalité les règles qu’il souhaite appliquer. Son nœud vérifiera ensuite chaque bloc et chaque transaction selon ces règles, sans tenir compte de l’avis des autres participants.

Si un mineur produit un bloc qui ne respecte pas ces règles, le nœud le rejettera automatiquement, même si ce bloc représente une quantité importante de puissance de calcul.

Cette caractéristique distingue Bitcoin de nombreux autres systèmes. Le consensus ne repose pas uniquement sur le hashrate, mais également sur les milliers de nœuds indépendants qui appliquent les règles du protocole.

Pourquoi les débats sont parfois aussi longs

Vu de l’extérieur, les discussions techniques de Bitcoin peuvent sembler interminables. Certaines propositions restent ouvertes pendant plusieurs années avant qu’une décision ne soit prise. D’autres sont finalement abandonnées malgré un travail considérable.

Cette lenteur est souvent critiquée. Pourtant, elle constitue aussi une protection. Bitcoin sécurise aujourd’hui plusieurs centaines de milliards de dollars de valeur. Une modification précipitée pourrait avoir des conséquences irréversibles sur l’ensemble du réseau.

Les développeurs privilégient donc généralement une approche prudente : analyser les conséquences, écouter les critiques, tester les modifications et rechercher un accord aussi large que possible avant toute évolution du consensus.

Le BIP-110 illustre parfaitement cette gouvernance

Le parcours du BIP-110 montre concrètement comment fonctionne Bitcoin. Une idée est proposée publiquement, discutée, critiquée, améliorée puis éventuellement adoptée si un consensus suffisant émerge. Rien n’est automatique et rien n’est garanti.

Que le BIP-110 soit finalement activé ou non importe finalement moins que le processus lui-même. Les discussions qu’il a suscitées permettent à la communauté d’examiner les limites actuelles du protocole, de confronter différentes visions et d’approfondir la compréhension des enjeux liés à l’évolution de Bitcoin.

Le chapitre suivant quittera le terrain de la gouvernance pour revenir à une question plus pratique : que changerait réellement le BIP-110 dans l’utilisation quotidienne de Bitcoin, tant pour les particuliers que pour les professionnels ?

Chapitre 9

Que changerait réellement le BIP-110 dans l’utilisation quotidienne de Bitcoin ?

Après plusieurs chapitres consacrés aux aspects techniques, à la gouvernance et aux débats qu’il suscite, une question demeure : qu’est-ce que le BIP-110 changerait réellement pour les utilisateurs de Bitcoin au quotidien ?

Pour répondre à cette question, il faut distinguer les différents profils d’utilisateurs. En effet, un particulier qui utilise Bitcoin comme moyen d’épargne n’a pas les mêmes besoins qu’un développeur, un mineur ou une entreprise exploitant des applications construites sur la blockchain.

Pour la majorité des utilisateurs, pratiquement aucun changement

Pour une personne qui achète régulièrement des bitcoins, les conserve dans un portefeuille personnel ou réalise quelques paiements, le BIP-110 passerait probablement totalement inaperçu.

Les transactions classiques utilisant des sorties SegWit ou Taproot respectent déjà largement les limites prévues par la proposition. Les portefeuilles modernes n’auraient donc, dans la majorité des cas, aucune modification visible à apporter à l’expérience utilisateur.

Envoyer des bitcoins, recevoir un paiement, sauvegarder sa phrase de récupération ou utiliser un portefeuille matériel fonctionneraient exactement comme aujourd’hui.

Les paiements Lightning ne seraient pas directement concernés

Le Lightning Network repose sur des transactions Bitcoin classiques pour ouvrir et fermer les canaux de paiement. Les échanges effectués à l’intérieur de ces canaux se déroulent ensuite hors chaîne.

Le BIP-110 ne modifie pas le fonctionnement du Lightning Network lui-même. Les utilisateurs continueraient donc à effectuer des paiements instantanés de la même manière.

Seules les transactions d’ouverture ou de fermeture des canaux resteraient soumises aux règles normales du consensus, comme c’est déjà le cas aujourd’hui.

Les portefeuilles devraient-ils être mis à jour ?

La plupart des portefeuilles Bitcoin utilisent déjà des scripts compatibles avec les limites prévues par le BIP-110. Les développeurs devraient néanmoins vérifier que toutes les transactions générées respectent les nouvelles règles pendant la durée d’application du soft fork.

Dans la majorité des cas, ces adaptations resteraient invisibles pour l’utilisateur final. Les mises à jour seraient intégrées progressivement dans les nouvelles versions des logiciels, comme lors des précédentes évolutions importantes de Bitcoin.

Les services utilisant les inscriptions devraient s’adapter

Les principaux changements concerneraient les plateformes et les applications qui enregistrent directement des fichiers ou des données importantes dans la blockchain Bitcoin.

Si les nouvelles limites entraient en vigueur, certaines transactions actuellement valides seraient désormais refusées par les nœuds appliquant le BIP-110. Les développeurs devraient alors modifier leurs logiciels, réduire la taille des données enregistrées ou concevoir de nouvelles méthodes de fonctionnement.

Selon les partisans du BIP-110, cette adaptation constituerait précisément l’objectif recherché. Les opposants y voient au contraire une contrainte artificielle imposée à des usages qui respectent aujourd’hui les règles du protocole.

Les frais de transaction pourraient-ils diminuer ?

Cette question revient régulièrement dans les discussions. Les défenseurs du BIP-110 estiment que limiter certaines formes de stockage de données pourrait libérer davantage d’espace pour les transactions financières classiques. Dans certaines situations, cela pourrait réduire la concurrence pour l’inclusion dans les blocs et contribuer à une baisse des frais.

Les opposants restent beaucoup plus prudents. Ils rappellent que les frais dépendent avant tout de l’offre et de la demande d’espace disponible. Si d’autres usages apparaissent ou si la demande de paiements augmente fortement, les frais pourraient rester élevés malgré les nouvelles restrictions.

Autrement dit, le BIP-110 ne garantit pas une baisse durable des frais. Son influence dépendrait du comportement futur des utilisateurs et de l’évolution globale de la demande sur Bitcoin.

Un changement surtout invisible, mais potentiellement structurant

Si le BIP-110 était activé, la majorité des détenteurs de bitcoins ne constateraient probablement aucune différence dans leur utilisation quotidienne. Les paiements, les transferts et la conservation des fonds continueraient de fonctionner comme aujourd’hui.

En revanche, les conséquences pourraient être importantes pour certains secteurs spécialisés de l’écosystème. Les développeurs d’applications reposant sur les inscriptions devraient revoir leur fonctionnement, tandis que les débats sur la mission fondamentale de Bitcoin continueraient probablement bien au-delà de la période d’application du soft fork.

Cette distinction entre les effets visibles pour le grand public et les conséquences structurelles pour le protocole explique pourquoi le BIP-110 suscite autant d’intérêt. Derrière des modifications techniques relativement limitées se cache une réflexion beaucoup plus large sur l’avenir de Bitcoin.

Chapitre 10

Les scénarios possibles pour l’avenir du BIP-110

Au moment de la rédaction de ce dossier, le BIP-110 demeure une proposition d’amélioration. Comme tous les BIP, son avenir dépendra des discussions techniques, des retours de la communauté et de l’émergence – ou non – d’un consensus suffisant pour envisager son activation.

Plusieurs scénarios sont donc possibles. Aucun ne peut être considéré comme acquis, car Bitcoin évolue selon un processus décentralisé dans lequel aucun acteur ne peut imposer seul une décision.

Premier scénario : le BIP-110 est adopté sans modification majeure

Dans cette première hypothèse, les développeurs, les opérateurs de nœuds, les mineurs et les autres acteurs de l’écosystème convergeraient progressivement vers un accord. La proposition serait alors activée conformément au mécanisme prévu.

Les nouvelles limites s’appliqueraient pendant la période définie par le BIP. Les développeurs pourraient ensuite analyser les résultats concrets : évolution des frais de transaction, impact sur les inscriptions, comportement des utilisateurs, conséquences pour les nœuds et réactions du marché.

À l’issue de cette période, la communauté disposerait de données réelles pour décider de la suite à donner : revenir aux règles précédentes, prolonger l’expérience ou proposer une nouvelle évolution du protocole.

Deuxième scénario : la proposition est profondément modifiée

Il s’agit d’un scénario fréquent dans l’histoire des BIP. Les discussions publiques permettent souvent d’identifier des points perfectibles, qu’il s’agisse de détails techniques, de paramètres ou de la méthode d’activation.

Dans ce cas, l’auteur peut décider de publier une nouvelle version de sa proposition afin de répondre aux critiques formulées par la communauté. Certaines limitations pourraient être ajustées, d’autres supprimées ou remplacées par des mécanismes différents.

Une telle évolution ne signifierait pas nécessairement que l’objectif initial est abandonné. Elle illustrerait simplement le fonctionnement normal du processus d’amélioration de Bitcoin.

Troisième scénario : le BIP-110 n’est jamais activé

Comme de nombreuses autres propositions avant lui, le BIP-110 pourrait également ne jamais être adopté. Si un consensus suffisant ne se dégage pas, le texte resterait une proposition sans effet sur les règles du protocole.

Ce résultat ne constituerait pas un échec du fonctionnement de Bitcoin. Au contraire, il démontrerait que le réseau préfère conserver les règles existantes plutôt que d’adopter une modification qui divise encore fortement ses participants.

La stabilité fait partie des caractéristiques essentielles de Bitcoin. L’absence de changement peut donc être une décision aussi importante qu’une évolution du protocole.

Quatrième scénario : une autre solution apparaît

Les discussions techniques débouchent parfois sur des solutions totalement différentes de celles proposées initialement. Les critiques adressées à une proposition peuvent conduire à l’émergence d’une approche nouvelle, jugée plus simple ou plus efficace.

Dans le cas du BIP-110, certains développeurs estiment que d’autres mécanismes pourraient répondre aux préoccupations liées au stockage de données arbitraires sans modifier les règles de consensus de la même manière.

Il est donc possible que le débat actuel aboutisse, à terme, à une solution différente de celle décrite dans le BIP-110, tout en poursuivant des objectifs similaires.

Pourquoi il est impossible de prédire l’issue du débat

Contrairement à un logiciel développé par une seule entreprise, Bitcoin évolue grâce à un équilibre complexe entre développeurs, chercheurs, entreprises, mineurs, opérateurs de nœuds et utilisateurs répartis dans le monde entier.

Les discussions techniques peuvent évoluer rapidement à mesure que de nouveaux arguments apparaissent, que des expérimentations sont réalisées ou que le contexte général du réseau change. Une proposition très critiquée peut finalement convaincre une majorité, tandis qu’une idée initialement populaire peut perdre progressivement son soutien.

C’est précisément cette absence de décision centralisée qui rend les évolutions de Bitcoin parfois longues, mais également particulièrement robustes.

Le débat dépasse désormais le seul BIP-110

Quelle que soit son issue, le BIP-110 aura déjà eu un effet important : remettre au centre des discussions plusieurs questions fondamentales concernant Bitcoin. Quelle place accorder aux usages non monétaires ? Jusqu’où doit aller la neutralité du protocole ? Les règles de consensus doivent-elles évoluer pour orienter certains comportements ?

Ces interrogations continueront probablement d’alimenter les débats bien après le sort réservé au BIP-110. Elles concernent l’évolution de Bitcoin dans son ensemble et la manière dont le protocole préservera, au fil des années, l’équilibre entre innovation, stabilité, sécurité et décentralisation.

Le chapitre suivant reviendra sur les idées reçues les plus répandues à propos du BIP-110. Plusieurs affirmations circulent régulièrement sur les réseaux sociaux ou dans les médias spécialisés, alors qu’elles ne correspondent pas au contenu réel de la proposition. Les examiner permettra de distinguer les faits des interprétations.

Chapitre 11

Les idées reçues sur le BIP-110

Comme beaucoup de propositions techniques concernant Bitcoin, le BIP-110 a rapidement fait l’objet de nombreuses interprétations. Certaines critiques reposent sur des éléments bien réels, d’autres proviennent de malentendus ou de simplifications excessives. Pour comprendre le débat, il est indispensable de distinguer le contenu réel du BIP de ce qui lui est parfois attribué.

Idée reçue n°1 : le BIP-110 interdit totalement les inscriptions

C’est probablement l’affirmation la plus répandue. Pourtant, elle ne correspond pas exactement au contenu de la proposition.

Le BIP-110 ne contient aucune règle interdisant explicitement les inscriptions, les NFT ou un protocole particulier. Il introduit des limites de taille sur certains éléments des transactions, notamment dans le witness, les scriptPubKey et les versions inconnues de Witness.

L’objectif affiché est de rendre beaucoup plus difficile l’enregistrement de grandes quantités de données arbitraires. En revanche, le document ne prétend pas rendre cette pratique totalement impossible.

Plusieurs développeurs ont d’ailleurs rappelé que des méthodes alternatives pourraient continuer à exister, même si elles deviennent plus coûteuses ou plus complexes à mettre en œuvre.

Idée reçue n°2 : le BIP-110 modifie la limite de taille des blocs

Cette affirmation est également incorrecte.

Le BIP-110 ne change ni la limite de poids des blocs ni leur mécanisme de validation général. Les blocs conserveraient les mêmes contraintes qu’aujourd’hui.

La proposition agit uniquement sur certains formats de données considérés comme valides. Elle modifie donc les règles d’acceptation de certaines transactions, mais ne réduit pas la capacité maximale d’un bloc.

Idée reçue n°3 : le BIP-110 supprimerait les frais élevés

Le BIP-110 ne promet nulle part une baisse automatique des frais de transaction.

Ses partisans estiment qu’en limitant certains usages intensifs de l’espace des blocs, davantage de capacité pourrait être disponible pour les paiements classiques. Cela pourrait, dans certaines circonstances, réduire la concurrence entre les transactions.

Cependant, les frais dépendent avant tout de la demande globale d’espace dans les blocs. Si cette demande reste forte pour d’autres raisons, les frais pourraient demeurer élevés, indépendamment du BIP-110.

Idée reçue n°4 : les utilisateurs devront changer leur manière d’utiliser Bitcoin

Pour la très grande majorité des utilisateurs, cette affirmation est exagérée.

Acheter des bitcoins, les conserver dans un portefeuille personnel, recevoir des paiements ou effectuer des transactions classiques continuerait de fonctionner de la même manière. Les formats utilisés quotidiennement respectent déjà les limites prévues par le BIP-110.

Les changements concerneraient principalement les applications exploitant volontairement certaines possibilités techniques pour enregistrer des données importantes dans la blockchain.

Idée reçue n°5 : les développeurs de Bitcoin Core peuvent imposer le BIP-110

Cette idée revient régulièrement lors des débats, alors qu’elle ne reflète pas le fonctionnement réel de Bitcoin.

Les développeurs de Bitcoin Core peuvent proposer du code, publier de nouvelles versions du logiciel et participer aux discussions techniques. En revanche, ils ne peuvent contraindre personne à installer ces versions.

Chaque opérateur de nœud reste libre de choisir le logiciel qu’il exécute. Sans adoption volontaire par les participants du réseau, aucune modification du consensus ne peut devenir effective.

Idée reçue n°6 : le débat concerne uniquement un problème technique

Cette affirmation est sans doute la plus trompeuse.

Les aspects techniques du BIP-110 sont relativement bien identifiés. En réalité, les désaccords portent surtout sur des questions de philosophie et de gouvernance.

Bitcoin doit-il rester totalement neutre face aux différents usages de son espace de blocs ? Le protocole peut-il introduire des limitations afin de privilégier sa fonction monétaire ? À partir de quel moment une évolution devient-elle une forme d’intervention sur les usages ?

Ces interrogations expliquent pourquoi les discussions autour du BIP-110 sont particulièrement vives. Les réponses apportées pourraient influencer la manière dont seront examinées de futures propositions d’amélioration du protocole.

Le chapitre suivant analysera les précédents historiques. Plusieurs évolutions majeures de Bitcoin ont déjà suscité des débats comparables. Comprendre ces épisodes permet de replacer le BIP-110 dans l’histoire plus large des changements de consensus du réseau.

Chapitre 12

Les précédents historiques : comment Bitcoin a déjà traversé des débats similaires

Le débat autour du BIP-110 peut donner l’impression d’être inédit. Pourtant, depuis la création de Bitcoin, plusieurs propositions d’amélioration ont suscité des discussions tout aussi intenses. Certaines ont été adoptées après plusieurs années de réflexion. D’autres ont été abandonnées ou profondément modifiées avant d’être acceptées.

Ces précédents permettent de mieux comprendre pourquoi les échanges autour du BIP-110 sont aussi longs et parfois aussi passionnés. Ils montrent également que les désaccords font partie du fonctionnement normal de Bitcoin.

P2SH : l’une des premières grandes évolutions du consensus

En 2012, Bitcoin adopte Pay-to-Script-Hash (P2SH), défini par le BIP-16. Cette évolution permet de simplifier l’utilisation de scripts complexes, notamment pour les portefeuilles multisignatures.

À l’époque, plusieurs développeurs craignent que cette modification ajoute une complexité inutile au protocole. D’autres estiment au contraire qu’elle constitue une amélioration indispensable pour favoriser l’adoption de Bitcoin.

Avec le recul, P2SH est aujourd’hui considéré comme une évolution majeure qui a permis le développement de nombreuses applications tout en restant compatible avec les principes fondamentaux de Bitcoin.

SegWit : l’un des débats les plus importants de l’histoire de Bitcoin

L’exemple le plus souvent cité reste celui de Segregated Witness (SegWit), introduit par le BIP-141 en 2017. Cette évolution modifie la manière dont les signatures sont enregistrées dans les transactions afin de résoudre plusieurs limitations techniques, notamment la malléabilité des transactions.

Au-delà de ses aspects techniques, SegWit provoque un profond désaccord sur la gouvernance de Bitcoin. Les discussions portent autant sur le contenu de la proposition que sur sa méthode d’activation et sur le rôle respectif des mineurs et des opérateurs de nœuds.

Pendant plusieurs mois, le réseau connaît une période de fortes tensions. Des scénarios de division de la blockchain sont même envisagés avant qu’un consensus suffisant ne permette finalement l’activation de SegWit.

Le débat autour du BIP-110 rappelle, à une échelle différente, cette période où plusieurs visions de l’évolution de Bitcoin s’opposaient ouvertement.

Taproot : un consensus obtenu plus sereinement

En 2021, Bitcoin active Taproot, principalement défini par les BIP-340, BIP-341 et BIP-342. Cette évolution améliore la confidentialité de certaines transactions, optimise les scripts et ouvre la voie à de nouvelles possibilités de programmation.

Contrairement à SegWit, Taproot bénéficie d’un climat beaucoup plus apaisé. Les discussions techniques restent nombreuses, mais un consensus se dégage progressivement avant l’ouverture de la période de signalisation.

Cette différence montre que toutes les évolutions de Bitcoin ne provoquent pas nécessairement des affrontements majeurs. Tout dépend de la nature des changements proposés et de leur impact perçu sur le protocole.

Pourquoi le BIP-110 suscite davantage de controverses

Le BIP-110 ne cherche pas uniquement à améliorer un mécanisme technique existant. Il touche directement à la manière dont l’espace des blocs peut être utilisé. C’est précisément ce point qui alimente les débats.

Pour certains, cette proposition protège la vocation monétaire de Bitcoin. Pour d’autres, elle introduit une distinction entre différents usages pourtant conformes aux règles actuelles du protocole.

Cette différence explique pourquoi les discussions dépassent largement les questions de programmation. Elles portent sur la philosophie générale de Bitcoin et sur les principes qui guideront ses futures évolutions.

Les débats font partie du fonctionnement normal de Bitcoin

Lorsqu’on observe l’histoire de Bitcoin dans son ensemble, une constante apparaît : les propositions les plus importantes sont presque toujours accompagnées de débats longs et parfois très vifs.

Cette situation peut surprendre les nouveaux utilisateurs, mais elle constitue l’une des conséquences directes de la décentralisation du protocole. Puisqu’aucune autorité centrale ne peut imposer une évolution, chaque changement majeur doit convaincre une large partie de la communauté.

Le BIP-110 s’inscrit donc dans une longue tradition de discussions publiques, d’analyses contradictoires et d’améliorations progressives. Quelle que soit son issue, il participe au processus par lequel Bitcoin continue d’évoluer sans renoncer à son principe fondamental : aucune modification importante ne peut être imposée sans un consensus suffisamment large.

Le chapitre suivant examinera les conséquences possibles à long terme. Au-delà de son éventuelle activation, le BIP-110 soulève des questions qui pourraient influencer les futures propositions d’amélioration et la manière dont Bitcoin évoluera dans les prochaines décennies.

Chapitre 13

Les conséquences possibles du BIP-110 à long terme

Quelle que soit l’issue du BIP-110, cette proposition laissera probablement une trace dans l’histoire de Bitcoin. Même si elle n’était jamais activée, les questions qu’elle soulève continueront d’influencer les réflexions sur l’évolution du protocole.

Les discussions ne concernent plus uniquement les inscriptions ou le stockage de données arbitraires. Elles portent désormais sur la manière dont Bitcoin devra évoluer au cours des prochaines décennies, alors que son adoption mondiale continue de progresser.

La place des usages non monétaires restera un sujet récurrent

Depuis sa création, Bitcoin est utilisé principalement comme système monétaire. Toutefois, au fil des années, de nouveaux usages sont apparus grâce aux évolutions du protocole et à l’ingéniosité des développeurs.

Les inscriptions, les NFT natifs de Bitcoin, certains protocoles de jetons et d’autres expérimentations démontrent que la blockchain peut être utilisée pour des fonctions qui dépassent le simple transfert de valeur.

Le BIP-110 pose une question fondamentale : Bitcoin doit-il encourager cette diversification des usages ou, au contraire, préserver autant que possible son rôle de réseau de paiement et de réserve de valeur ?

Cette interrogation continuera probablement d’accompagner les futures propositions d’amélioration, même si le BIP-110 n’est jamais adopté.

La gestion de l’espace des blocs deviendra un enjeu croissant

Le nombre maximal de transactions pouvant être incluses dans un bloc reste limité. Cette contrainte fait partie intégrante du modèle économique de Bitcoin.

À mesure que l’adoption progresse, la concurrence pour accéder à cet espace devrait continuer d’augmenter. Les utilisateurs devront alors arbitrer entre le coût des frais, l’urgence de leurs transactions et les différentes solutions de seconde couche comme le Lightning Network.

Dans ce contexte, les débats sur la meilleure utilisation de l’espace disponible resteront probablement d’actualité, indépendamment du devenir du BIP-110.

Le rôle économique des frais de transaction continuera d’évoluer

À chaque halving, la récompense versée aux mineurs diminue de moitié. À long terme, une part croissante de leurs revenus devra provenir des frais de transaction plutôt que de la création monétaire.

Cette évolution rend les débats autour du marché des frais particulièrement importants. Certains estiment que toute demande d’espace dans les blocs constitue une source légitime de revenus pour les mineurs. D’autres considèrent que la qualité de cette demande est tout aussi importante que son volume.

Le BIP-110 illustre parfaitement cette opposition entre deux conceptions du futur financement de la sécurité de Bitcoin.

La neutralité de Bitcoin restera régulièrement discutée

Le principe de neutralité constitue l’un des fondements de Bitcoin. Le protocole ne connaît ni l’identité des utilisateurs, ni la valeur économique des transactions, ni leur objectif.

Le BIP-110 relance néanmoins une question délicate : jusqu’où cette neutralité doit-elle s’étendre ? Peut-elle coexister avec certaines limites techniques destinées à préserver la fonction monétaire du réseau ?

Il est peu probable que ce débat disparaisse. Au contraire, chaque nouvelle proposition importante pourrait conduire la communauté à réexaminer cet équilibre entre neutralité, efficacité et préservation des ressources du protocole.

Une communauté capable de débattre est une force

Les discussions parfois vives autour du BIP-110 peuvent donner l’impression d’un profond désaccord au sein de la communauté Bitcoin. Pourtant, elles témoignent également d’un fonctionnement ouvert dans lequel chaque proposition est examinée publiquement.

Les arguments favorables comme les critiques sont discutés sur des listes de diffusion, des dépôts de code, des forums techniques et des espaces de recherche accessibles à tous. Cette transparence permet à chacun de vérifier les affirmations avancées et de se forger sa propre opinion.

Si ce processus demande du temps, il contribue également à la robustesse de Bitcoin. Les modifications importantes ne sont généralement envisagées qu’après un examen approfondi de leurs conséquences techniques, économiques et sociales.

Le véritable héritage du BIP-110

Au-delà de son contenu technique, le BIP-110 aura rappelé qu’aucune évolution de Bitcoin ne peut être analysée uniquement sous l’angle du code. Chaque modification du consensus soulève des questions de gouvernance, d’économie, de philosophie et parfois même de définition de ce qu’est Bitcoin.

C’est probablement là son principal apport. Qu’il soit activé, modifié ou abandonné, le BIP-110 aura obligé l’ensemble de l’écosystème à réexaminer plusieurs principes fondamentaux du protocole et à préciser les raisons qui motivent leur défense.

Le chapitre suivant conclura ce dossier en dressant un bilan complet de la proposition, de ses objectifs, de ses limites et des enseignements que tout utilisateur de Bitcoin peut en retenir.

Chapitre 14

Conclusion : ce qu’il faut réellement retenir du BIP-110

Au terme de cette étude, une conclusion s’impose : le BIP-110 est bien plus qu’une simple proposition technique visant à limiter certaines formes de stockage de données dans Bitcoin. Il constitue un débat de fond sur la manière dont le protocole doit évoluer tout en préservant les principes qui ont assuré son succès depuis 2009.

À première vue, le document semble relativement simple. Il propose principalement d’introduire des limites de taille sur plusieurs éléments des transactions afin de rendre plus difficile l’enregistrement de données arbitraires directement dans la blockchain. Pourtant, derrière ces quelques règles se cachent des questions beaucoup plus profondes concernant la neutralité du protocole, la gestion de l’espace des blocs, le financement futur des mineurs, la décentralisation des nœuds et la gouvernance de Bitcoin.

Une proposition née d’un contexte précis

Le BIP-110 n’est pas apparu par hasard. Il est le résultat de plusieurs années de débats provoqués par l’arrivée de nouveaux usages de Bitcoin, notamment les inscriptions, les NFT natifs, certains protocoles de jetons et d’autres formes de stockage de données directement dans les blocs.

Pour une partie de la communauté, ces usages représentent une évolution naturelle d’un protocole ouvert, dans lequel chacun reste libre d’utiliser l’espace disponible à condition d’en payer le coût. Pour une autre partie, ils détournent progressivement Bitcoin de sa vocation première de système monétaire pair à pair et de réserve de valeur.

Le BIP-110 constitue donc une tentative de répondre à cette évolution en modifiant certaines règles de consensus, tout en limitant volontairement la durée d’application de ces nouvelles restrictions.

Deux visions légitimes de Bitcoin

L’analyse du BIP-110 montre qu’il ne s’agit pas d’une opposition entre des défenseurs et des adversaires de Bitcoin. Les deux camps partagent généralement les mêmes objectifs fondamentaux : préserver la sécurité, la décentralisation et la pérennité du réseau.

Le désaccord porte principalement sur les moyens d’atteindre ces objectifs.

Les partisans du BIP-110 considèrent que certaines limites supplémentaires sont nécessaires pour protéger durablement la fonction monétaire de Bitcoin et éviter que l’espace des blocs soit principalement utilisé pour d’autres activités.

Les opposants estiment au contraire que le protocole doit rester neutre. Selon eux, tant qu’une transaction respecte les règles de consensus et paie les frais correspondants, Bitcoin ne doit pas privilégier un usage plutôt qu’un autre.

Le fonctionnement de Bitcoin ressort renforcé

Le principal enseignement du BIP-110 ne réside peut-être pas dans son contenu technique, mais dans la manière dont il est débattu. Les échanges publics, les critiques détaillées, les analyses contradictoires et les nombreuses révisions illustrent le fonctionnement particulier de Bitcoin.

Aucune entreprise, aucun gouvernement, aucun développeur et aucun mineur ne peut décider seul de modifier les règles du protocole. Toute évolution importante doit convaincre une part suffisamment large de l’écosystème pour espérer être adoptée.

Ce processus peut sembler lent. Il constitue pourtant l’une des principales raisons pour lesquelles Bitcoin est devenu l’un des réseaux informatiques les plus résilients au monde.

Le BIP-110 n’est qu’une étape dans une réflexion plus large

Que cette proposition soit finalement adoptée, modifiée ou abandonnée, les questions qu’elle soulève continueront d’accompagner l’évolution de Bitcoin. L’utilisation de l’espace des blocs, le financement de la sécurité après les futurs halvings, la place des usages non monétaires ou encore les limites de la neutralité du protocole resteront probablement des sujets majeurs dans les années à venir.

Le BIP-110 n’apporte donc pas une réponse définitive à ces interrogations. Il participe à un débat permanent qui accompagne chaque évolution importante de Bitcoin depuis sa création.

Bref

Comprendre le BIP-110 ne consiste pas à choisir immédiatement un camp. Il s’agit d’abord de comprendre les faits, les motivations des différents acteurs, les mécanismes techniques proposés et les conséquences potentielles de cette évolution.

Bitcoin repose sur des règles transparentes, un code open source et des débats publics. Le BIP-110 illustre parfaitement cette philosophie. Chacun peut lire la proposition, examiner son code, étudier les arguments favorables comme les critiques et se forger sa propre opinion à partir des sources primaires.

C’est précisément cette transparence qui distingue Bitcoin de la plupart des systèmes monétaires contemporains. Les évolutions ne sont pas décidées à huis clos : elles sont discutées publiquement, analysées collectivement et, lorsqu’un consensus suffisamment large émerge, intégrées progressivement au protocole.

Le BIP-110 représente ainsi bien davantage qu’un simple projet de soft fork. Il constitue une nouvelle démonstration du fonctionnement de Bitcoin : un réseau capable d’évoluer, mais uniquement lorsque ses utilisateurs jugent que cette évolution respecte les principes fondamentaux qui en font la force.

Annexe 1 — Chronologie complète du BIP-110

Pour comprendre pleinement le BIP-110, il est utile de replacer cette proposition dans son contexte historique. Contrairement à ce que l’on pourrait croire, le débat n’est pas apparu du jour au lendemain. Il résulte d’une succession d’événements techniques, économiques et communautaires qui ont progressivement conduit une partie des développeurs à proposer une modification temporaire des règles de consensus.

2009 : naissance de Bitcoin

Le 3 janvier 2009, Satoshi Nakamoto crée le bloc Genesis. Bitcoin est conçu comme un système de paiement électronique pair à pair permettant d’échanger de la valeur sans intermédiaire de confiance.

Le protocole contient déjà un langage de script volontairement limité afin de garantir la sécurité du réseau. Les transactions peuvent néanmoins transporter certaines données supplémentaires dans différentes parties de leur structure.

2014 : apparition d’OP_RETURN

Les développeurs introduisent progressivement l’utilisation d’OP_RETURN afin d’offrir un emplacement dédié au stockage de petites quantités de données. Cette solution vise notamment à éviter que certains utilisateurs détournent les sorties UTXO pour y enregistrer des informations permanentes.

À cette époque déjà, la communauté s’interroge sur la place des données non financières dans la blockchain Bitcoin.

2017 : SegWit modifie la structure des transactions

L’activation de Segregated Witness transforme la manière dont certaines données sont enregistrées dans les transactions. Les signatures sont déplacées dans une nouvelle structure appelée witness, dont le poids est comptabilisé différemment.

L’objectif est alors de résoudre la malléabilité des transactions et d’améliorer l’efficacité du protocole. Plusieurs années plus tard, cette évolution permettra également l’apparition d’usages qui n’étaient pas envisagés lors de son déploiement.

2021 : Taproot ouvre de nouvelles possibilités

L’activation de Taproot améliore la confidentialité, la flexibilité des scripts et l’efficacité de certaines transactions. Elle introduit également le mécanisme des versions de Witness ainsi que le champ Annex, prévus pour permettre de futures évolutions du protocole.

Ces nouvelles possibilités seront ensuite utilisées par différents protocoles pour enregistrer des données arbitraires dans la blockchain.

2022 : naissance d’Ordinals

Le protocole Ordinals démontre qu’il est possible d’associer des données directement à des satoshis en utilisant les possibilités offertes par Taproot et le Witness. Très rapidement apparaissent des images, des textes, des œuvres numériques, puis différents protocoles de jetons.

Cette évolution provoque un débat immédiat. Certains y voient une innovation majeure démontrant la polyvalence de Bitcoin. D’autres considèrent qu’il s’agit d’un détournement de ressources destinées avant tout aux paiements.

2023–2025 : multiplication des discussions

Les échanges se multiplient sur les listes de diffusion, GitHub, Delving Bitcoin et d’autres espaces techniques. Plusieurs développeurs proposent des solutions très différentes : modifications des politiques de relais, changements du consensus, ou absence totale d’intervention afin de laisser agir le marché des frais.

Aucun consensus clair ne se dégage immédiatement. Les discussions portent autant sur les aspects techniques que sur la philosophie générale de Bitcoin.

Publication du BIP-110

C’est dans ce contexte qu’est publié le BIP-110. Son auteur propose un soft fork temporaire introduisant plusieurs limites de taille afin de rendre plus difficile l’utilisation de certaines parties des transactions pour le stockage de données arbitraires.

La proposition relance immédiatement les débats. Les discussions ne portent plus uniquement sur les inscriptions, mais également sur la gouvernance de Bitcoin, la neutralité du protocole, le marché des frais et le rôle des règles de consensus.

Un débat toujours en cours

Au moment de la rédaction de ce dossier, le BIP-110 demeure une proposition. Son avenir dépendra des discussions techniques, des éventuelles modifications apportées au texte et du niveau de consensus qu’il parviendra ou non à obtenir auprès de la communauté Bitcoin.

Quelle que soit son issue, le BIP-110 occupe déjà une place importante dans l’histoire récente de Bitcoin. Il illustre les difficultés rencontrées lorsqu’il s’agit de faire évoluer un protocole décentralisé tout en préservant ses principes fondamentaux.

Annexe 2 — Glossaire des principaux termes techniques

Le BIP-110 fait intervenir de nombreux concepts propres au fonctionnement interne de Bitcoin. Cette annexe rassemble les principaux termes rencontrés dans ce dossier afin de faciliter leur compréhension. Les définitions sont volontairement accessibles tout en restant fidèles au fonctionnement réel du protocole.

Annex

L’Annex est une partie optionnelle des transactions Taproot. Prévue dès l’origine pour permettre de futures évolutions du protocole, elle est aujourd’hui très rarement utilisée. Le BIP-110 propose de limiter fortement sa taille afin d’éviter qu’elle serve au stockage de grandes quantités de données arbitraires.

BIP (Bitcoin Improvement Proposal)

Un BIP est un document décrivant une proposition d’amélioration de Bitcoin. Il peut concerner le protocole, les portefeuilles, les procédures ou les standards utilisés par l’écosystème. La publication d’un BIP ne signifie pas qu’il sera adopté.

Bloc

Un bloc regroupe un ensemble de transactions validées par les mineurs. Chaque bloc est relié cryptographiquement au précédent, formant ainsi la blockchain Bitcoin.

Blockchain

La blockchain est le registre public distribué de Bitcoin. Elle contient l’historique de toutes les transactions validées depuis le bloc Genesis.

Consensus

Le consensus désigne l’ensemble des règles que tous les nœuds appliquent pour déterminer quelles transactions et quels blocs sont valides. Modifier ces règles nécessite un accord suffisamment large de l’écosystème.

Hashrate

Le hashrate représente la puissance totale de calcul consacrée au minage de Bitcoin. Plus il est élevé, plus le réseau est difficile à attaquer.

Mineur

Un mineur est un acteur qui rassemble les transactions, construit un bloc et tente de résoudre la preuve de travail afin d’ajouter ce bloc à la blockchain. En échange, il reçoit la récompense de bloc et les frais de transaction.

Nœud complet (Full Node)

Un nœud complet télécharge l’intégralité de la blockchain, vérifie indépendamment chaque bloc et chaque transaction, puis applique les règles de consensus sans faire confiance à un tiers.

OP_RETURN

OP_RETURN est un opcode permettant d’insérer une petite quantité de données dans une transaction tout en rendant la sortie définitivement inutilisable. Son objectif est d’offrir un emplacement explicite pour certaines métadonnées sans créer de nouveaux UTXO.

scriptPubKey

Le scriptPubKey est le script de verrouillage d’une sortie de transaction. Il définit les conditions qui devront être remplies pour dépenser les bitcoins associés à cette sortie.

SegWit (Segregated Witness)

SegWit est une évolution majeure activée en 2017. Elle sépare les signatures des autres données de transaction afin de résoudre la malléabilité des transactions et d’améliorer l’efficacité du protocole.

Soft fork

Un soft fork est une modification des règles de consensus qui rend certaines transactions auparavant valides désormais invalides, tout en restant compatible avec les anciennes versions du logiciel sous certaines conditions.

Taproot

Taproot est une évolution activée en 2021 qui améliore la confidentialité, la flexibilité des scripts et l’efficacité des transactions Bitcoin. Elle introduit notamment les signatures Schnorr ainsi que de nouvelles possibilités d’évolution du protocole.

UTXO (Unspent Transaction Output)

Un UTXO est une sortie de transaction qui n’a pas encore été dépensée. L’ensemble des UTXO représente les bitcoins actuellement disponibles sur le réseau. Tous les nœuds conservent cette base de données afin de vérifier les nouvelles transactions.

Witness

Le Witness est la partie d’une transaction SegWit qui contient principalement les signatures et les données nécessaires à la validation. Le BIP-110 propose de limiter la taille de certains éléments présents dans cette zone afin de réduire les possibilités de stockage de données arbitraires.

Witness Version

Les versions de Witness permettent d’introduire progressivement de nouveaux types de sorties dans Bitcoin. Les versions encore non attribuées sont volontairement réservées pour de futures évolutions. Le BIP-110 prévoit de limiter les données qui peuvent y être enregistrées afin de préserver ces espaces pour leur usage initial.

Annexe 3 — Questions fréquentes (FAQ)

Cette foire aux questions reprend les interrogations les plus courantes concernant le BIP-110. Les réponses s’appuient sur le contenu de la proposition et sur les discussions techniques qui l’accompagnent.

Le BIP-110 est-il déjà actif sur Bitcoin ?

Non. Le BIP-110 est une proposition d’amélioration. Tant qu’elle n’a pas obtenu le niveau de consensus nécessaire et qu’elle n’a pas été activée selon la procédure prévue, les règles actuelles de Bitcoin continuent de s’appliquer.

Le BIP-110 modifie-t-il la limite de 21 millions de bitcoins ?

Absolument pas. Le BIP-110 ne modifie ni l’offre monétaire de Bitcoin, ni le calendrier des halvings, ni la récompense des mineurs. Il concerne uniquement certaines règles de validation des transactions.

Mes bitcoins seraient-ils en danger si le BIP-110 était adopté ?

Non. Les bitcoins déjà détenus par les utilisateurs ne sont pas affectés par cette proposition. Les clés privées, les adresses et les soldes restent inchangés. Le BIP-110 ne concerne que les conditions de validation de certaines nouvelles transactions.

Faudra-t-il changer de portefeuille ?

Dans la très grande majorité des cas, non. Les développeurs de portefeuilles intégreraient les éventuelles adaptations nécessaires directement dans leurs mises à jour. Pour un utilisateur effectuant des transactions classiques, l’expérience resterait pratiquement identique.

Le Lightning Network serait-il affecté ?

Le fonctionnement général du Lightning Network ne serait pas modifié. Les ouvertures et fermetures de canaux continueraient simplement à respecter les règles de consensus applicables à Bitcoin, comme c’est déjà le cas aujourd’hui.

Le BIP-110 interdit-il les NFT sur Bitcoin ?

Non. Le texte ne mentionne ni les NFT, ni Ordinals, ni un protocole particulier. Il introduit des limitations techniques sur certaines structures de transaction. Ces limitations pourraient rendre certains mécanismes plus difficiles à utiliser, mais elles ne constituent pas une interdiction explicite d’un protocole précis.

Les frais de transaction vont-ils forcément diminuer ?

Rien ne permet de l’affirmer. Les frais dépendent essentiellement de la concurrence pour l’espace disponible dans les blocs. Si la demande reste importante, les frais pourront demeurer élevés, même avec de nouvelles restrictions.

Le BIP-110 est-il une forme de censure ?

C’est précisément l’un des principaux points de désaccord entre ses partisans et ses opposants. Les premiers considèrent qu’il s’agit d’une évolution technique destinée à préserver la vocation monétaire de Bitcoin. Les seconds estiment qu’il introduit une sélection implicite entre différents usages pourtant conformes aux règles actuelles.

Qui décidera finalement de son adoption ?

Aucune personne ni aucune organisation ne peut décider seule. L’adoption éventuelle dépendra d’un consensus entre les développeurs, les opérateurs de nœuds, les mineurs, les entreprises de l’écosystème et les utilisateurs. C’est l’un des principes fondamentaux de la gouvernance de Bitcoin.

Pourquoi ce BIP provoque-t-il autant de débats ?

Parce qu’il touche à des sujets essentiels : la neutralité du protocole, la gestion de l’espace des blocs, les revenus futurs des mineurs, les usages autorisés de Bitcoin et la manière dont le réseau doit évoluer. Le débat dépasse donc largement le cadre d’une simple modification technique.

Annexe 4 — Les principaux enseignements en dix points

• Le BIP-110 est une proposition de soft fork temporaire, pas une mise à jour déjà activée.
• Il ne modifie ni les 21 millions de bitcoins, ni les règles du minage, ni le calendrier des halvings.
• Il introduit des limitations de taille sur certaines parties des transactions afin de limiter le stockage de données arbitraires.
• Les paiements Bitcoin classiques resteraient pratiquement inchangés.
• Les principaux impacts concerneraient les protocoles utilisant les inscriptions et certaines applications reposant sur le stockage de données dans la blockchain.
• Le BIP-110 ne garantit pas une baisse des frais de transaction ; leur évolution dépendra toujours de l’offre et de la demande d’espace dans les blocs.
• Le débat oppose principalement deux visions : préserver explicitement la fonction monétaire de Bitcoin ou maintenir une neutralité totale du protocole.
• Comme toute évolution importante de Bitcoin, son adoption dépend d’un consensus suffisamment large de l’écosystème.
• Même s’il n’est jamais activé, le BIP-110 aura profondément alimenté la réflexion sur l’avenir de Bitcoin.
• Comprendre le BIP-110, c’est aussi comprendre le fonctionnement de la gouvernance décentralisée de Bitcoin.

Annexe 5 — Tableau récapitulatif des limitations proposées par le BIP-110

Le tableau ci-dessous résume les principales limitations introduites par le BIP-110 ainsi que leur objectif. Il ne remplace pas la lecture du texte officiel, mais permet d’obtenir une vue d’ensemble des modifications proposées.

Élément concerné	Modification proposée	Objectif affiché
scriptPubKey	Limitation de taille	Empêcher l’utilisation de scripts de verrouillage très volumineux pour stocker des données.
Witness	Limitation de certains éléments à 256 octets	Réduire la possibilité d’insérer de gros volumes de données arbitraires.
Versions inconnues du Witness	Restriction de taille	Préserver les versions futures du protocole pour leurs usages prévus.
Annex Taproot	Limitation de taille	Éviter que cette zone soit utilisée comme espace de stockage.
Structures de données contiguës	Limitation des séquences volumineuses	Rendre plus difficile le stockage direct de fichiers dans une transaction.
Durée d’application	Soft fork temporaire (52 416 blocs)	Observer les effets de la proposition avant toute décision définitive.

Annexe 6 — Ce que le BIP-110 ne fait pas

Le débat public autour du BIP-110 conduit parfois à lui attribuer des effets qui ne figurent pourtant pas dans la proposition. Cette annexe résume clairement ce que le BIP-110 ne modifie pas.

• Il ne modifie pas la limite des 21 millions de bitcoins.
• Il ne change pas le calendrier des halvings.
• Il ne modifie pas l’algorithme de preuve de travail (Proof of Work).
• Il ne change pas le temps moyen de production d’un bloc.
• Il ne modifie pas la difficulté du minage.
• Il ne supprime pas Lightning Network.
• Il ne modifie pas les signatures Schnorr.
• Il ne remet pas en cause Taproot.
• Il ne crée aucune nouvelle cryptomonnaie.
• Il ne change pas les clés privées ni les adresses Bitcoin.
• Il ne bloque pas les paiements Bitcoin classiques.
• Il ne donne aucun pouvoir particulier aux développeurs de Bitcoin Core.
• Il ne garantit pas une baisse des frais de transaction.
• Il ne supprime pas définitivement toute possibilité de stocker des données arbitraires.
• Il n’est pas une mise à jour déjà active au moment de la rédaction de ce dossier.

BREF

Le BIP-110 restera probablement comme l’une des propositions les plus débattues de l’histoire récente de Bitcoin. Plus qu’un simple ensemble de limitations techniques, il aura mis en lumière des questions fondamentales auxquelles la communauté est régulièrement confrontée : comment préserver la décentralisation, comment gérer une ressource limitée comme l’espace des blocs, comment financer durablement la sécurité du réseau et jusqu’où doit aller la neutralité du protocole.

Comme l’ont montré les précédents historiques, Bitcoin n’évolue jamais rapidement. Chaque modification importante est examinée publiquement, critiquée, corrigée puis éventuellement adoptée uniquement lorsqu’un consensus suffisamment large se dégage. Ce processus peut sembler lent, mais il constitue l’une des principales garanties de stabilité du protocole.

Le BIP-110 illustre parfaitement cette philosophie. Son avenir dépendra des arguments techniques, des expérimentations, des discussions entre les différents acteurs de l’écosystème et, finalement, de la volonté collective des utilisateurs de Bitcoin.

Qu’il soit adopté, profondément modifié ou finalement abandonné, cette proposition aura déjà rempli une fonction essentielle : pousser la communauté à réexaminer les principes fondamentaux de Bitcoin et à préciser la vision qu’elle souhaite défendre pour les décennies à venir.

Comme toujours avec Bitcoin, la meilleure approche consiste à consulter les sources primaires, à lire les propositions dans leur intégralité, à comparer les arguments des différents intervenants et à construire sa propre analyse à partir de faits vérifiables plutôt que d’opinions ou de résumés partiels.

Comprendre Bitcoin, c’est comprendre pourquoi chaque règle est débattue avant d’être acceptée. Le BIP-110 en est une illustration particulièrement représentative.

Vous êtes pour ou contre?

✍️ DUC

Bibliographie et sources primaires

Documents officiels

• BIP-110 — Texte officiel de la proposition.
• Dépôt officiel des Bitcoin Improvement Proposals (BIPs).
• Documentation officielle de Bitcoin Core.
• Code source de Bitcoin Core.

• BIP-110 — Texte officiel de la proposition.
  https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki
• Dépôt officiel des Bitcoin Improvement Proposals (BIPs).
  https://github.com/bitcoin/bips
• Documentation officielle de Bitcoin Core.
  https://bitcoincore.org/
  https://casey.github.io/bitcoin/ (Documentation du développeur)
• Code source de Bitcoin Core.
  https://github.com/bitcoin/bitcoin

Discussions techniques

• Delving Bitcoin.
  https://delvingbitcoin.org/
• Bitcoin-Dev Mailing List.
  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
• Discussions GitHub liées au BIP-110.
  https://github.com/bitcoin/bips/pulls?q=BIP-110
  https://github.com/bitcoin/bips/issues?q=BIP-110
• Pull Requests et commentaires des développeurs Bitcoin Core.
  https://github.com/bitcoin/bitcoin/pulls
  https://github.com/bitcoin/bitcoin/issues

BIPs historiques cités dans ce dossier

• BIP-16 — Pay-to-Script-Hash (P2SH).
  https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
• BIP-34 — Block v2, Height in Coinbase.
  https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
• BIP-65 — CHECKLOCKTIMEVERIFY (CLTV).
  https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
• BIP-66 — Strict DER Signatures.
  https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
• BIP-68 — Relative Lock-Time Using Consensus-Enforced Sequence Numbers.
  https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
• BIP-112 — CHECKSEQUENCEVERIFY (CSV).
  https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
• BIP-113 — Median Time Past.
  https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
• BIP-141 — Segregated Witness (SegWit).
  https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
• BIP-143 — Transaction Signature Verification for Version 0 Witness Program.
  https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki
• BIP-144 — Segregated Witness Peer Services.
  https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki
• BIP-340 — Schnorr Signatures for secp256k1.
  https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
• BIP-341 — Taproot: SegWit Version 1 Spending Rules.
  https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
• BIP-342 — Validation of Taproot Scripts (Tapscript).
  https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

Lectures complémentaires

• Le livre blanc Bitcoin: A Peer-to-Peer Electronic Cash System, publié par Satoshi Nakamoto le 31 octobre 2008.
  https://bitcoin.org/en/bitcoin-paper
  (PDF officiel en plusieurs langues, dont le français.) :contentReference[oaicite:0]{index=0}
• Les archives de la mailing list Cryptography (où Satoshi a annoncé le white paper).
  https://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html
• Les archives Bitcoin-Dev (mailing list officielle des développeurs Bitcoin).
  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
• Le dépôt GitHub officiel de Bitcoin Core.
  https://github.com/bitcoin/bitcoin
• Les discussions techniques consacrées à Ordinals, Taproot et à l’évolution du marché des frais (Delving Bitcoin).
  https://delvingbitcoin.org/
• Et bien d’autres😉

Remarque finale

Le BIP-110 est une proposition particulièrement représentative du fonctionnement de Bitcoin. Son intérêt dépasse largement les limitations techniques qu’il introduit. Il montre qu’un protocole décentralisé ne repose pas sur l’autorité d’un individu ou d’une entreprise, mais sur un processus de discussion publique, de vérification technique et de recherche progressive d’un consensus.

Quelles que soient les conclusions auxquelles chaque lecteur parviendra après avoir étudié cette proposition, une chose demeure certaine : comprendre le BIP-110 permet de mieux comprendre Bitcoin lui-même.

En ce qui me concerne, c’est non au BIP-110 😉

✍️ DUC

---

🚀 Rejoignez-moi pour plus de contenu exclusif !

• 👉 YouTube : Bitcoin sans détour
• 👉 X : @bitcoinduc

📢Prendre des décisions informées dans cet univers passionnant ! Comprendre, Apprendre, Réussir…

• Sur YouTube : toute l’actualité de Bitcoin et un regard averti sur l’ensemble de l’univers des cryptomonnaies.

🔔 Abonnez-vous au site pour ne manquer aucun contenu :

À bientôt, DUC

AVERTISSEMENT :
Les contenus publiés sur ce site ont une vocation strictement informative et analysent les tendances du marché. Ils ne doivent en aucun cas être interprétés comme des conseils financiers ou des recommandations d’investissement. Avant toute décision, prenez le temps d’effectuer vos propres recherches.