BIP 110, intitulé Reduced Data Temporary Softfork, est une proposition close visant à durcir temporairement les règles utilisées par les nœuds pour accepter les blocs. Un nœud est un ordinateur qui vérifie lui-même l’historique et les paiements. Le projet voulait compliquer certains usages de stockage et, selon ses défenseurs, renforcer la fonction monétaire du réseau. Cela n’en faisait pas automatiquement une règle de tout Bitcoin.
Imaginons deux opérateurs recevant le même bloc. L’un l’accepte selon les règles existantes, l’autre le refuse au nom d’une nouvelle restriction. BIP 110 intervenait à ce niveau : il modifierait la validité des blocs, pas seulement la décision de relayer une transaction ou de la garder dans le mempool, la salle d’attente locale des paiements non confirmés. Lors de la vérification du 2026-10-23, la spécification en version 1.0.1 affichait Closed, soit « clos ». Un numéro BIP ou un logiciel publié ne certifie pas l’adoption par le réseau. Le registre conserve le document et son histoire ; il ne modifie pas à distance les règles des nœuds. [1] [2]
Chaque nouvelle sortie possède un scriptPubKey, le script qui fixe les conditions de sa dépense future. Le projet autorisait au maximum 34 octets, ou 83 octets si le script commence par OP_RETURN, une instruction rendant la sortie manifestement impossible à dépenser. Le script entier est compté. Une autre limite, de 256 octets, concernait les données individuelles des instructions OP_PUSHDATA* et les arguments du witness, les informations jointes pour vérifier une dépense. L’insertion du redeemScript, le script révélé des conditions de dépense, dans un scriptSig BIP16 fait exception. Les witness scripts et Tapleaf scripts ne sont pas eux-mêmes ces arguments, mais leurs instructions d’insertion de données restent limitées. On mesure donc des parties précises, pas la longueur totale d’une transaction ni de tout son witness. [1]
Le projet touchait aussi Taproot, une façon d’exprimer les conditions de dépense. Il interdisait de dépenser des versions non définies de witness ou de Tapleaf, sans interdire de créer ces sorties. Il excluait l’annex, un champ supplémentaire, et les control blocks de plus de 257 octets, des preuves trop longues de l’appartenance du script à la structure engagée. Tapscript ne pouvait contenir OP_SUCCESS* même dans du code non exécuté, ni exécuter OP_IF ou OP_NOTIF, quel que soit le résultat de la condition. Pour la comparaison technique, les formats définis comprennent P2WPKH, P2WSH, P2TR avec une version Tapleaf 0xc0 et P2A avec le programme 0x4e73, ce dernier uniquement avec une pile witness vide. Ce sont des noms précis de formats, pas des champs que l’utilisateur doit renseigner dans son portefeuille. [1]
Un UTXO est une sortie encore non dépensée : un montant précis assorti de conditions d’utilisation. Le projet exempte les entrées dépensant des UTXO confirmés avant l’activation. Il ne donne pas pour autant carte blanche aux nouvelles sorties de la même transaction. Une signature préparée à l’avance ne protège pas une sortie créée seulement pendant la période active. Pour certaines constructions Taproot présignées, la spécification admet le risque de fonds bloqués ou perdus si les restrictions invalident les voies prévues et qu’aucune autre voie utilisable ne subsiste. Cela soulève aussi la question des effets sur Miniscript, un outil de construction des conditions de dépense, et BitVM, des constructions permettant de vérifier des calculs. On ne peut donc pas promettre que seul le contenu non monétaire serait touché. [1] [3]
Un mineur peut signaler son soutien dans un bloc : ici, par le bit 4, avec un seuil de 1109 blocs sur 2016, soit environ 55 pour cent. Mais le projet allait au-delà d’un signal volontaire. Si le seuil n’était pas atteint auparavant, il imposait le signal aux hauteurs 961632–963647, puis LOCKED_IN à partir de 963648 et ACTIVE à partir de 965664, à condition que la chaîne concernée y parvienne. La hauteur indique la position d’un bloc. LOCKED_IN acte la transition ; ACTIVE applique réellement les restrictions de données. Le client rejetterait déjà les blocs sans signal pendant la période obligatoire : les nœuds pourraient donc se séparer avant les limites de données. Celles-ci devaient durer 52416 blocs après l’activation effective, puis passer à EXPIRED et cesser de s’appliquer, sans correspondre exactement à une année civile. [1] [4]
Les défenseurs voulaient réduire les coûts des nœuds, la pression sur l’ensemble UTXO et les contenus indésirables, en donnant priorité aux paiements. Ces objectifs expliquent l’intention, mais ne démontrent pas le résultat. Les critiques évoquaient les effets sur des scripts utiles, les évolutions futures et le risque de scission. Les données peuvent aussi être réparties en petits morceaux : dans la discussion initiale, Peter Todd a montré une transaction contenant ainsi toute la proposition de l’époque. Même la spécification ne promet pas d’éliminer la stéganographie, qui consiste à dissimuler une information dans d’autres données. Rendre le stockage plus coûteux et l’empêcher complètement sont deux résultats différents. De même, craindre une responsabilité juridique pour le contenu ne suffit pas à établir une obligation légale précise. [1] [3]
Le dossier du PR 2247 décrit une séparation le 2026-08-08 à la hauteur 961632. La chaîne principale contenait un bloc sans le signal exigé, tandis qu’OCEAN minait une autre version avec le signal. Le 2026-08-09, Murch indiquait que la branche minoritaire n’avait produit que 2 blocs puis s’était arrêtée, alors que la principale avait progressé de plus de 100 blocs. Ce témoignage doit conserver sa date et son auteur : il ne s’agit ni d’une reconstitution indépendante du blockchain réalisée ici, ni d’un constat de l’état actuel de la branche minoritaire. Il montre aussi pourquoi une scission provoquée par la signalisation ne prouve pas le passage à ACTIVE ni l’application des restrictions de données. [5] [6]
Le document est passé par Complete, une spécification achevée, puis a fini en Closed. Le PR 2245 de clôture a été intégré le 2026-08-10 ; le journal de la spécification porte la date du 2026-08-09. Ces dates concernent des enregistrements différents, pas une nouvelle activation. Le client v0.4.1 documente EXPIRED et vbrequired, le champ du modèle de bloc indiquant le bit de signalisation obligatoire. Son existence ne signifie pas une adoption dans Bitcoin Core. Il existe aussi des test vectors, des transactions d’exemple avec leurs résultats attendus, et des tests fonctionnels. Cet article ne les exécute pas et ne vérifie pas la branche minoritaire actuelle. Il explique la proposition et son parcours documenté sans présenter un document historique comme les règles communes actuelles du réseau. [7] [1] [4]
Un octet de plus peut changer le résultat
Imaginons la vérification d’une nouvelle sortie sous ces règles hypothétiquement actives. Un scriptPubKey ordinaire de 34 octets passe ce test de longueur ; à 35 octets, il échoue. Un script commençant par OP_RETURN peut avoir 83 octets ; 84 octets dépassent la limite. On mesure toujours le script de sortie entier, pas seulement le texte inséré. Réussir ce test ne prouve pas la validité de toute la transaction, et dépenser un ancien UTXO n’exempte pas une nouvelle sortie.
Pour une vision complète, lisez aussi Soft Fork, Full Node, Taproot, Bitcoin Script, Transaction Fees, UTXO. Cette entrée est également citée par OP_RETURN.
01Closed veut-il dire que personne ne peut plus exécuter le client ?+
Closed est un statut de document, pas une interdiction d’utiliser un logiciel. Les nœuds suivent les règles de leur programme. Choisir d’autres règles peut néanmoins mener à une autre branche de la chaîne ; clore une fiche du registre n’efface pas cette différence.
02Les limites de données s’appliquaient-elles déjà pendant la signalisation obligatoire ?+
Non. La signalisation obligatoire précède LOCKED_IN et ACTIVE. Un client peut rejeter un bloc sans le signal requis avant le début des règles de données. La date seule ne suffit donc pas : l’état et la hauteur de la chaîne concernée comptent.