Un point sur OP_RETURN, Bitcoin Core v30 et la guerre Core-Knots

Contexte

Introduite en 2014, l’instruction OP_RETURN permet d’inscrire de petites métadonnées directement dans la blockchain Bitcoin en associant des données arbitraires à une transaction.

Bitcoin Core v30, publiée le 10 octobre 2025, marque un tournant majeur dans l’intégration de données sur Bitcoin en portant la limite d’OP_RETURN de 83 à 100 000 octets, supprimant toute contrainte pratique sur la quantité d’informations intégrables dans une transaction.

Ce changement n’altère pas le protocole Bitcoin lui-même. Il ne touche pas aux règles de consensus, les règles fondamentales qui définissent ce qu’est un bloc valide, mais uniquement aux politiques de relais (policy rules) que chaque logiciel applique localement pour accepter ou non une transaction dans sa mempool.

L’ajustement traduit une approche plus permissive de la gestion du blockspace. Il vise à canaliser les usages non monétaires dans un espace dédié, plutôt qu’à les voir proliférer via des moyens détournés.

Cette inflexion, purement logicielle, ravive une fracture historique et idéologique autour de Bitcoin. Elle se cristallise dans l’opposition entre les deux clients principaux du réseau, Bitcoin Core, implémentation historique désormais plus permissive, et Bitcoin Knots, fork conservateur attaché à une interprétation strictement monétaire du protocole.

---

Rappels sur le consensus de Bitcoin

Bitcoin Script, le langage natif du protocole, définit via des opcodes les conditions de dépense d’une transaction. Contrairement à Ethereum, il n’est pas conçu pour exécuter des smart contracts complexes, mais seulement des conditions logiques simples comme la vérification de signature, la validation de hash ou le verrouillage temporel.

Parmi ces instructions, OP_RETURN occupe une place particulière. Lorsqu’elle est exécutée, elle met fin au script et rend la sortie associée définitivement non dépensable. Les bitcoins ainsi verrouillés sont irrécupérables, mais la sortie peut intégrer des données arbitraires (texte, hash, empreinte numérique etc.) jusqu’à la limite fixée par la politique du client, désormais 100 000 octets depuis Bitcoin Core v30.

Pour rappel, le protocole Bitcoin repose sur deux niveaux de règles distincts :

• Les règles de consensus, qui déterminent ce qui rend un bloc valide (par exemple la taille maximale d’un bloc). S’en écarter conduit à une scission de la blockchain.
• Les règles de policy (ou standardness), qui régissent uniquement le relais et la propagation des transactions sur le réseau.

OP_RETURN relève de la seconde catégorie. Une transaction peut être valide au sens du consensus tout en étant jugée non standard par la politique d’un nœud, et donc non relayée par défaut. Elle reste néanmoins minable et intégrable dans un bloc. Cette distinction entre validité et relais explique comment Bitcoin Core et Bitcoin Knots peuvent diverger sur leurs politiques sans jamais rompre leur compatibilité avec la blockchain.

Chaque nœud exécute un client, un logiciel chargé d’appliquer les règles de la blockchain. Tant que ces clients respectent les mêmes règles de consensus, ils restent interopérables. Cette diversité renforce la résilience du réseau, à l’image d’Ethereum où coexistent plusieurs implémentations (Geth, Nethermind, Besu) appliquant un même protocole sous différentes formes logicielles.

Toutefois, à la différence d’Ethereum qui distingue clients de consensus et d’exécution, Bitcoin ne repose que sur un type unique de client assurant simultanément validation et exécution du protocole.

---

OP_RETURN : genèse, limites et évolution

Avant 2014, OP_RETURN était considéré comme une instruction non standard. Une transaction pouvait contenir cette sortie et rester valide au niveau du consensus, mais elle n’était pas relayée par les nœuds exécutant la politique par défaut de Bitcoin Core.

L’introduction de la version 0.9, en mars 2014, marque un tournant. Les développeurs décident d’autoriser une sortie OP_RETURN standardisée, initialement limitée à 40 octets, puis portée à 80 et 83 octets dans la version 0.11.

À ce stade, l’objectif n’était pas d’offrir une capacité de stockage sur Bitcoin, mais de résoudre un problème de pollution de l’UTXO set, la base des sorties non dépensées stockée en RAM par chaque nœud. Avant cette évolution, certains utilisateurs inséraient déjà des données sur la blockchain via des moyens détournés, gonflant ainsi la base que chaque nœud doit conserver en mémoire.

OP_RETURN offrait une solution propre avec un espace dédié aux métadonnées sans alourdir l’UTXO set. Mastercoin (devenu Omni Layer) fut le premier à l’exploiter pour émettre des tokens sur Bitcoin, notamment l’USDT de Tether en 2014.

L’équilibre s’est toutefois déplacé, successivement avec SegWit (2017) puis Taproot (2021). SegWit a introduit le champ witness, distinct du reste de la transaction et bénéficiant d’un witness discount, un facteur qui réduit le poids comptabilisé des données dans le calcul des frais de transaction.

Des développeurs ont rapidement exploité cette capacité pour y inscrire des blocs de données beaucoup plus volumineux, à moindre coût, tout en restant pleinement conformes aux règles de consensus. Le problème fondamental ici, c’est que ces données intégrées dans le champ witness augmentent la taille de la blockchain, dans la mesure où chaque nœud doit les télécharger et les stocker pour rester à jour.

Taproot a amplifié ce potentiel en combinant signatures Schnorr et les arbres de Merkle, permettant d’intégrer des scripts complexes ou des données arbitraires dans le witness, favorisant l’émergence de solution comme les Ordinals et les BRC-20.

En 2023, le protocole Ordinals a popularisé ce mécanisme, déclenchant un débat majeur sur les politiques de relais. Les limitations historiques d’OP_RETURN n’étaient plus efficaces, les usages qu’elles cherchaient à encadrer s’étaient déplacés vers le champ witness. La question de fond reste ouverte : faut-il maintenir des plafonds stricts, au risque d’encourager des contournements néfastes, ou élargir OP_RETURN pour canaliser ces pratiques dans un espace propre et dédié ?

---

Bitcoin Core v30 : nouvelles règles pour OP_RETURN

La version 30 de Bitcoin Core, publiée le 10 octobre 2025, modifie la politique de relais appliquée aux sorties OP_RETURN. Le paramètre -datacarriersize, qui définit la taille maximale des métadonnées pouvant être inscrites dans OP_RETURN, passe de 83 à 100 000 octets par défaut. En pratique, ce relèvement supprime toute contrainte effective sur OP_RETURN, puisque la limite de taille totale de transaction, 100 000 vbytes, sera atteinte bien avant ce plafond.

Sur Bitcoin, les frais sont calculés en fonction du poids d’une transaction, exprimé en vbytes, unité qui pondère la taille des données selon leur coût de validation. À titre de comparaison, sur Ethereum, le coût s’exprime en gas, dont le montant est mesuré selon le type et le nombre d’opérations exécutées, et non du seul volume de données.

La v30 introduit également la possibilité d’inclure plusieurs sorties OP_RETURN  dans une même transaction. Auparavant, une seule pouvait être relayée par défaut, les transactions comportant plusieurs sorties de ce type étant considérées comme non standard, bien que valides au sens du consensus.

Ces paramètres demeurent toutefois configurables. Un opérateur de nœud peut restreindre ou désactiver le relais des data carriers, autrement dit choisir de ne pas relayer les transactions contenant des OP_RETURN volumineux. Une proposition visant à retirer ces options avait été discutée dans les phases de développement, avant d’être abandonnée dans la version finale.

---

Impacts et cas d’usage

Les changements introduits par Bitcoin Core v30, bien qu’ils relèvent uniquement de la politique de relais, ouvrent des perspectives concrètes pour plusieurs projets existants et émergents. L’élargissement d’OP_RETURN favorise un ancrage de données plus explicite sur Bitcoin, sans alourdir l’ensemble des sorties non dépensées (UTXO set).

Les protocoles construits sur Bitcoin tels qu’Ordinals ou les BRC-20 reposent exclusivement sur les évolutions apportées par SegWit et Taproot. En revanche, d’autres solutions comme Runes, lancée en avril 2024 par Casey Rodarmor, le développeur à l’origine des Ordinals en 2023, s’appuient exclusivement sur OP_RETURN.

Dans ce modèle, chaque Runestone inscrit dans la sortie OP_RETURN d’une transaction agit comme un message d’état contenant les instructions nécessaires pour créer, transférer ou détruire un Rune, le jeton fongible natif du protocole. Ces instructions, encodées sous forme de données brutes, sont ensuite interprétées par des indexeurs externes qui reconstruisent la logique du protocole.

Avec la levée de la limite sur OP_RETURN, Runes bénéficie désormais d’une marge de manœuvre plus importante pour des structures de métadonnées plus riches, sans recourir à des constructions complexes.

L’explosion de l’usage d’OP_RETURN coïncide directement avec le lancement de Runes en avril 2024. Le protocole a transformé cette fonction longtemps marginale en un vecteur central d’activité on-chain. En quelques semaines, le volume d’outputs OP_RETURN a été multiplié par plus de dix, atteignant des niveaux jamais observés depuis la création de Bitcoin.

Au-delà des inscriptions, Bitcoin Core v30 ouvre également de nouveaux cas d’usage pour les solutions de Layer 2, où OP_RETURN peut servir de point d’ancrage pour des états ou des preuves, leur permettant de prouver périodiquement leur état, à l’image de ce que font les layer 2 sur Ethereum.

Par exemple, Ark Protocol, conçu par Burak Keceli (ex-Lightning Labs), développe actuellement Arkade Assets, un framework annoncé en octobre 2025 pour créer et transférer des tokens nativement sur Bitcoin. Ce système utilise OP_RETURN pour encoder les données d’actifs onchain (stablecoins, security tokens, etc..), tout en permettant des opérations majoritairement offchain dans l’environnement VTXO d’Arkade.

En résumé, la v30 n’introduit pas de nouvelles fonctionnalités de smart contracts, mais le relâchement des contraintes rend OP_RETURN plus utile comme interface universelle d’ancrage de données, principalement pour les layer 2.

Dans les faits, peu de projets construisent directement autour d’OP_RETURN, dont la fonction reste limitée à l’ancrage de données. Les avancées applicatives sur Bitcoin ont davantage de chances d’émerger à travers les opcodes en discussion tels qu’OP_CAT, OP_CTV et OP_CSFS, qui étendent la programmabilité du langage et ouvrent la voie à des constructions applicatives sur Bitcoin.

---

Bitcoin Core vs Bitcoin Knots : deux visions d’un même protocole

Le débat autour d’OP_RETURN a mis en lumière deux approches distinctes de la maintenance du protocole. D’un côté, Bitcoin Core, client historique majoritaire, privilégie une interprétation pragmatique et adaptable du code. De l’autre, Bitcoin Knots, maintenu par Luke Dashjr, incarne une lecture conservatrice axée sur la pureté monétaire du réseau.

Le rôle d’un client

Un client Bitcoin est un logiciel qui implémente les règles du protocole, c’est-à-dire la validation des blocs, le relais des transactions et la gestion du mempool.

Chaque nœud du réseau exécute un client et va décider localement de sa politique de relais, autrement dit quelles transactions relayer, stocker, ou rejeter. Tant qu’il respecte les règles de consensus qui définissent ce qu’est un bloc ou une transaction valide, il reste compatible avec les autres.

Les divergences entre ces clients tiennent uniquement à leur politique de relais, sans impact sur le consensus et sans risque de fork.

Sur le schéma ci-dessous, toutes les transactions incluses dans le cercle vert sont valides au sens du consensus, elles respectent les règles fondamentales de Bitcoin et peuvent être intégrées dans un bloc.

Un nœud exécutant Bitcoin Core ne relaie cependant que celles figurant dans le cercle violet, dites transactions standard. À l’inverse, un client appliquant une policy différente peut choisir de relayer toutes les transactions valides, y compris celles jugées non standard, sans rompre sa compatibilité avec le réseau.

Bitcoin Core : la référence historique

Descendant direct du logiciel publié par Satoshi Nakamoto en 2009, Bitcoin Core s’est imposé comme la référence technique et sociale du réseau. Grâce à sa stabilité, sa rigueur et son adoption historique, environ 76 % des nœuds l’exécutent encore en 2025.

L’équipe de Core privilégie une approche pragmatique en tolérant les usages non monétaires tant qu’ils restent circonscrits, encadrés et contrôlés. Selon eux, élargir OP_RETURN est une mesure de réduction de dommage :

• Les métadonnées restent isolées de l’UTXO set.
• Les nœuds conservent un contrôle local sur leur politique de relais.

Cette position s’inscrit dans une logique économique. À long terme, la rareté de l’espace bloc agit comme filtre naturel. Par conséquent, l’ancrage de données volumineuses devient coûteux et se marginalise sans intervention coercitive.

Bitcoin Knots : le contre-modèle conservateur

Bitcoin Knots, fork direct de Core maintenu par Luke Dashjr, un développeur historique connu pour ses positions maximalistes, conserve les mêmes règles de consensus mais impose une politique  plus stricte.

Par défaut, il limite OP_RETURN à 42 octets, active des filtres anti-spam et applique une politique de relais plus sélective. Sa philosophie repose sur une lecture monétaire stricte du protocole ; Bitcoin doit rester un réseau de règlement, non une plateforme de stockage de données.

Pour les partisans de Knots, la décision de Core 30.0 d’autoriser jusqu’à 100 000 octets par OP_RETURN constitue un abandon symbolique de cette idée fondatrice.

Ces derniers y voient trois risques :

• Congestion du blocspace, où les transactions liées à de la données chassent le paiement.
• Hausse structurelle des frais, pénalisant les usages de base.
• Risque réglementaire, lié à la facilité d’intégrer du contenu illicite (comme des données à caractère illégal), directement sur Bitcoin.

Knots entend envoyer le signal inverse, refuser par principe les usages considérés comme du “spam” et maintenir une discipline monétaire stricte.

Montée en puissance de Knots

Jusqu’au début de l’année  2025, Bitcoin Knots ne représentait qu’une fraction marginale du réseau. Environ 400 nœuds reposaient sur Knots, contre plus de 20 000 sur Core. Depuis le débat autour d’OP_RETURN et les critiques de figures comme Samson Mow, sa part a fortement progressé, dépassant les 20% aujourd’hui.

Cette progression s’explique aussi par l’adoption de Knots par plusieurs acteurs de taille. La pool de mining OCEAN, cofondée par Luke Dashjr et financée lors d’un tour seed de 6,2 M $ mené par Jack Dorsey, s’appuie sur Bitcoin Knots pour ses nœuds. Sa dominance a été multipliée par trois depuis le début de l’année, la plaçant désormais parmi les dix plus grandes pools de minage au monde, ce qui renforce la visibilité et la légitimité du client.

Ce regain reflète un désaccord idéologique plus que technique. Les deux clients appliquent le même consensus et valident les mêmes blocs, garantissant une compatibilité totale.

En pratique, même une minorité de nœuds exécutant Core suffit à assurer la propagation des transactions OP_RETURN volumineuses. À moins qu’une majorité écrasante du réseau n’adopte Knots, cette forme de résistance reste symbolique.

Comparatif technique : Bitcoin Core vs Bitcoin Knots (v30, 2025)

---

Risques et compromis

Les changements introduits par Bitcoin Core v30 autour d’OP_RETURN n’affectent pas le consensus mais modifient plusieurs équilibres techniques et opérationnels du réseau. Les principaux risques concernent la charge du réseau, la surface d’attaque au niveau du mempool, la gouvernance logicielle et la croissance structurelle de la blockchain.

Aucun risque de hard fork

Core et Knots appliquent le même consensus, leurs divergences n’affectent que la propagation des transactions. Un bloc accepté par Knots l’est aussi par Core, et inversement. Tant que cette distinction est respectée, aucun hard fork n’est possible, les deux clients opèrent sur la même blockchain Bitcoin.

Risques techniques : charge et attaques DoS

Le relèvement du plafond OP_RETURN accroît la surface d’attaque potentielle de type DoS au niveau du mempool.

Une politique de relais plus permissive peut faciliter la diffusion massive de transactions valides mais jugées peu utiles, saturant temporairement la mémoire ou la bande passante de certains nœuds.

Les opérateurs disposent néanmoins de contre-mesures : désactivation du relais des data carriers, filtrage local ou configuration de politiques personnalisées.

La mesure augmente aussi la charge réseau. Relayer et valider des transactions contenant plusieurs centaines de kilo-octets de données exige davantage de bande passante et de puissance CPU. À grande échelle, ce type d’usage alourdirait la synchronisation et le stockage des nœuds complets

Incitations économiques

Le relèvement d’OP_RETURN n’est pas économiquement neutre. Une transaction de 100 kB coûte environ 0,002 BTC à 2 sat/vB, soit environ 230$ au cours actuel.

Si une part non négligeable du trafic réseau adoptait ce format « data-heavy », cela représenterait plusieurs centaines de BTC de frais supplémentaires par an.

Ce changement crée un arbitrage économique. Les mineurs et pools (Foundry, MARA, AntPool) bénéficient d’une nouvelle source de revenus, notamment via des services directs comme Slipstream, qui permettent de soumettre des transactions volumineuses hors du mempool public.

Mais en contrepartie, les utilisateurs à vocation monétaire subissent des frais plus élevés en période de congestion. Le compromis est explicite, avec plus de revenus pour le minage, donc plus de sécurité à long terme, mais avec une accessibilité réduite pour les paiements de faible valeur.

Historiquement, les pics de revenus issus des frais sur Bitcoin coïncident presque toujours avec des vagues d’inscriptions Ordinals ou de protocoles dérivés (Runes, BRC-20). On observe notamment trois sommets correspondant à des périodes d’activité “data-heavy”, mai 2023, décembre 2023 et avril 2024, où les inscriptions ont saturé le blockspace et fait grimper les frais au-delà de 100 M $ par semaine.

Dynamiques de gouvernance et modèles de maintenance

Bitcoin Core demeure le client le plus audité du réseau, avec plusieurs centaines de contributeurs historiques, cinq mainteneurs principaux et un cycle de publication semestriel.

Bitcoin Knots, à l’inverse, repose presque exclusivement sur Luke Dashjr, assisté de quelques relecteurs ponctuels. Ce modèle plus restreint ralentit l’intégration de correctifs et crée une dépendance forte à un seul mainteneur.

Les versions de Knots sont généralement publiées avec un léger décalage par rapport à Core, ce qui peut retarder l’application de correctifs mineurs de sécurité. De plus, la plupart des programmes d’audit communautaires concentrent leurs efforts sur Core, laissant Knots bénéficier d’un examen externe limité. Cela ne remet pas en cause la sécurité du consensus, identique entre les deux clients, mais augmente légèrement le risque opérationnel pour les nœuds tournant sur Knots.

---

Conclusion

Les changements introduits par Bitcoin Core v30 autour d’OP_RETURN n’altèrent pas les fondations du consensus, mais déplacent les lignes de la gouvernance logicielle. En assouplissant sa politique de relais, Core assume une approche pragmatique, préférant autoriser les usages non monétaires dans un cadre maîtrisé, plutôt que de les voir contourner les règles existantes.

Knots incarne la position inverse, un maximalisme monétaire strict où toute tolérance vis-à-vis de la donnée est perçue comme une dilution du rôle de Bitcoin. Deux visions traduisent une différenciation progressive des politiques de relais plutôt qu’une scission du protocole.

Dans les faits, Bitcoin reste un système unifié : une seule blockchain, mais plusieurs interprétations possibles des règles qui régissent son espace-bloc.