Bitcoin Core & Knots

En 2025, le débat entre Bitcoin Core et Bitcoin Knots s’est intensifié autour de la version Core v30. Le point de friction principal porte sur l’assouplissement des règles de policy, notamment : la suppression de la limite de données dans OP_RETURN, l’autorisation de multiples sorties OP_RETURN, et la redéfinition du paramètre datacarriersize. Core avance que ces changements permettent de réduire le recours à des contournements, d’harmoniser relay policy et consensus, et de déléguer le filtrage au marché des frais.

De l’autre côté, les partisans de Knots, menés par Luke Dashjr, estiment que ces assouplissements ouvrent la voie à un afflux de transactions non monétaires, augmentant la charge pour les nœuds (stockage, bande passante, responsabilité légale) et nuisant à la vocation principale de Bitcoin : un support pour les transactions financières efficaces. Knots propose des filtres et des politiques plus restrictives (comme rejecttokens).

Deux visions nécessaires, une référence nécessaire, un garde fou nécessaire.

Dans le débat, on retrouve plusieurs figures influentes :

• Luke Dashjr : mainteneur principal de Knots, critique des usages d’inscriptions et d’afflux de données arbitraires.
• Jameson Lopp, Peter Todd : souvent cités parmi les commentateurs ou alliés du camp Core, plaidant la neutralité et l’ouverture des usages dans la mesure des frais payés.

Le débat dépasse la technique : c’est une lutte de visions sur la gouvernance de Bitcoin, la priorité entre la stabilité du réseau et l’ouverture aux usages innovants.

On ne sait pas et on ne sera pas tout sur la situation entre Bitcoin Core et Knots; mais voici ce que le code exprime et ce que je peux en penser, c’est un point de vue.

Historique

Le code originel de Satoshi (2009–2010)

En janvier 2009, Satoshi Nakamoto publie la version 0.1 de Bitcoin, écrite principalement en C++ avec une interface en wxWidgets.

• Le logiciel est monolithique : il intègre un nœud complet, un mineur CPU et un portefeuille rudimentaire.
• Il fonctionne en un seul processus, chaque utilisateur pouvant miner, valider et dépenser ses propres bitcoins.
• La gouvernance est directe : Satoshi publie les versions, la communauté les adopte.Bitcoin-Qt (2011–2013)

Avec le départ progressif de Satoshi, Gavin Andresen, Jeff Garzik, Pieter Wuille et d’autres reprennent le code.

• L’interface est réécrite en Qt, donnant naissance à Bitcoin-Qt.
• On distingue désormais :
  • bitcoind, le démon de nœud complet,
  • bitcoin-qt, le client graphique.
• Le minage intégré devient obsolète avec la montée des pools et des ASICs, même s’il subsiste dans le code pour quelques versions.
• C’est la première étape de professionnalisation du logiciel : modularisation, internationalisation, meilleure gestion du code source.

Bitcoin Knots (dès 2011)

Dès cette époque, Luke Dashjr commence à publier ses propres patchs.

• Sa critique porte sur deux points :
  1. la dérive possible de Bitcoin vers des usages non monétaires (stockage de données arbitraires, registres divers),
  2. la perte de souveraineté des opérateurs, dont les nœuds relaient par défaut tout ce que le consensus permet.
• Il lance une variante baptisée Bitcoin Knots, qui reprend la base de Bitcoin-Qt puis de Core, mais y ajoute :
  • des policies plus restrictives (rejecttokens, permitbaredatacarrier=0),
  • des paramètres supplémentaires pour donner du contrôle fin aux opérateurs (datacarriersize strict, minrelaymaturity, acceptunknownwitness, etc.),
  • un rôle de laboratoire policy, où expérimenter des garde-fous que Core n’adopte pas.

Knots n’est pas un fork de consensus (comme Bitcoin Cash en 2017), mais une implémentation compatibles sur les règles fondamentales, se distinguant uniquement par ses politiques de relais et ses options de configuration.

Bitcoin Core (2013–aujourd’hui)

En 2013, le projet principal adopte le nom Bitcoin Core.

• Ce changement marque la volonté de clarifier que le logiciel n’est pas Bitcoin en lui-même, mais l’implémentation de référence du protocole.
• Core supprime définitivement le mineur intégré, se concentre sur la validation et la propagation, et sépare davantage le portefeuille des fonctions de nœud.
• Le processus de gouvernance s’institutionnalise :
  • revues publiques sur GitHub et la mailing list,
  • initiatives pédagogiques comme le Bitcoin Core PR Review Club et les BitDevs,
  • maintien des releases par une petite équipe de maintainers disposant des droits de fusion.

Bitcoin Core devient la colonne vertébrale du réseau, en définissant par défaut les règles de standardness et de relay policy. Mais il n’est pas la seule implémentation : Knots, maintenu par Luke Dashjr, rappelle qu’une autre interprétation des priorités est possible.

Synthèse historique

• Code de Satoshi (2009) : un binaire unique, incluant nœud, mineur et portefeuille.
• Bitcoin-Qt (2011) : refonte graphique avec Qt, séparation des composants, fin du minage intégré.
• Bitcoin Knots (dès 2011) : variante conservatrice initiée par Luke Dashjr, ajoutant des garde-fous et des options pour protéger la vocation monétaire de Bitcoin et la souveraineté des opérateurs.
• Bitcoin Core (2013) : projet principal, implémentation de référence, gouverné par un processus de revue publique, aujourd’hui moteur de l’évolution des policies permissives.

Bitcoin Core comme référence et organisateur de Bitcoin

Depuis 2013, Bitcoin Core s’est imposé comme l’implémentation de référence du protocole Bitcoin. Ce statut ne découle pas d’une autorité centralisée ou d’une règle de consensus imposée, mais d’une légitimité acquise par usage et reconnaissance collective. La majorité des nœuds du réseau, des pools de minage, des portefeuilles et des services s’appuient sur Core comme sur la colonne vertébrale logicielle du système.

La référence technique

Bitcoin Core définit les règles de standardness et la relay policy qui structurent la propagation des transactions dans le réseau. Même si les règles de consensus sont indépendantes (une transaction ou un bloc valide l’est pour tous les nœuds), ce sont les règles de Core qui, en pratique, déterminent quelles transactions circulent efficacement et se retrouvent dans les blocs.
De plus, Core publie régulièrement des releases stables, signées par des maintainers reconnus, ce qui garantit aux opérateurs un point d’ancrage de confiance pour exécuter le logiciel.

L’organisateur du développement

Core n’est pas seulement un code : c’est aussi un processus social d’organisation.

• Les changements passent par des pull requests publiques sur GitHub.
• Le Bitcoin Core PR Review Club et les réunions BitDevs constituent des espaces d’apprentissage et de discussion collective.
• Les maintainers assurent la fusion des changements, mais seulement après qu’un consensus social soit apparu dans les revues publiques.

Ainsi, Bitcoin Core joue un rôle de coordination : il organise les contributions, établit une mémoire collective des débats et assure la continuité du projet.

Un rôle central dans l’écosystème

• Pour les utilisateurs finaux : Core est le logiciel par défaut recommandé pour exécuter un nœud complet, garantissant une expérience cohérente.
• Pour les développeurs : il constitue la base de la plupart des bibliothèques et services Bitcoin, et fixe les standards implicites d’intégration.
• Pour les mineurs : suivre Core assure de produire des blocs compatibles avec la majorité du réseau.

Progression de Knots par rapport à Core — quelques repères

• Une source rapporte une croissance de 638 % pour Knots entre le début de 2025 et juin 2025 (passant de 394 à 2 909 nœuds). À ce moment, Knots représenterait environ 13,24 % du total des nœuds. AInvest
• D’autres médias avancent que Knots a doublé sa part réseau en l’espace de six semaines (mai–juin 2025), atteignant environ 17 % des nœuds Bitcoin — une proportion significative pour un client alternatif. CryptoSlate
• Certains articles suggèrent que cette progression est vue comme une forme de protestation — des opérateurs de nœuds choisissent Knots pour exprimer un désaccord avec la direction prise par Core. Bitcoin News

Il reste important de noter que Core conserve une domination écrasante en termes de part réseau et d’infrastructures associées (wallets, exchanges, services). Mais la montée de Knots signale une fracture potentielle — non pas de consensus, mais de politique de relais — dans l’écosystème Bitcoin.

Voici les principaux sites de référence pour suivre les statistiques sur les nœuds Bitcoin et comparer l’usage de Bitcoin Core, Knots et d’autres implémentations :

• bitnodes.io — https://bitnodes.io
  Plateforme historique de suivi des nœuds Bitcoin, montrant leur répartition géographique, les versions logicielles (Core, Knots, etc.) et l’évolution dans le temps.
• coin.dance — https://coin.dance/nodes
  Tableau de bord très détaillé qui indique la part des différentes implémentations (Bitcoin Core, Knots, btcd…), la répartition par version, et les tendances de progression.
• mempool.space (Network dashboard) — https://mempool.space/nodes
  Fournit une vue réseau intégrée (nœuds connectés, versions détectées, protocoles), en complément à la visualisation des transactions et blocs.
• bitcoinstats.com — https://bitcoinstats.com/nodes
  Offre une carte interactive et des statistiques en temps réel sur les nœuds, leurs versions et leurs localisations.
• Luke Dashjr’s Bitcoin Knots stats (souvent relayées via dashjr.org ou sur GitHub)
  Bien que moins centralisé qu’un site comme bitnodes, Luke publie régulièrement ses propres statistiques et visualisations sur la part de Knots.
• Nodecounter.com — https://nodecounter.com
  Initialement conçu pour suivre le débat SegWit/Bitcoin Cash, le site conserve des statistiques de versions et de clients sur le réseau Bitcoin.

Autres implémentations de Bitcoin

Bien que Bitcoin Core (et, par extension, Knots) soit l’implémentation dominante, d’autres équipes ont développé des versions alternatives, souvent dans des langages différents, avec des objectifs variés :

• btcd (Go) : implémentation en Go, axée sur la clarté du code et l’usage comme bibliothèque pour des applications Bitcoin.
• Libbitcoin (C++) : conçue par Amir Taaki, visant une approche plus modulaire et politique (utilisée par certains projets alternatifs).
• bcoin (JavaScript/Node.js) : implémentation orientée vers l’écosystème web, facilitant l’intégration dans des applications JavaScript.
• rust-bitcoin (Rust) : bibliothèque et implémentation partielle du protocole, privilégiant sécurité mémoire et robustesse.
• Scala/Bitcoin-S (Scala) : implémentation utilisée surtout pour la recherche, l’expérimentation et le support de Lightning Network.
• python-bitcoinlib (Python) : plutôt une librairie qu’un nœud complet, souvent utilisée pour des tests ou des outils.

Ces implémentations ne jouent pas le rôle central de Core/Knots dans le réseau de production (elles représentent une fraction infime des nœuds), mais elles contribuent :

• à la diversité logicielle (réduction du risque de monoculture),
• à l’expérimentation (tests de nouvelles idées, intégrations dans des environnements spécifiques),
• à l’éducation (code plus lisible pour apprentissage).

Rappel de la gouvernance du code

Historique des clés du dépôt, des accès critiques et des mécanismes de vérification

D’où vient le code de Bitcoin et qui a eu les premiers accès

Le code initial de Bitcoin a été publié par Satoshi Nakamoto début 2009, d’abord sous forme d’archives et via le dépôt SourceForge, avant la migration de l’écosystème vers Git/GitHub au fil des années 2010. Les copies des tout premiers artefacts (v0.1 et itérations proches) demeurent consultables via des archives externes reconnues par la communauté (Satoshi Nakamoto Institute) et des répliques historiques du code, ce qui permet d’établir la chaîne de publication originelle et d’étudier l’évolution des pratiques de versionnage. (satoshi.nakamotoinstitute.org)

Après le retrait progressif de Satoshi (fin 2010), Gavin Andresen a exercé le rôle de « lead developer » puis de mainteneur principal, avec des droits de commit et d’administration sur l’arborescence de référence. Son retrait opérationnel (2016) s’est accompagné de la révocation formelle de ses accès GitHub au dépôt bitcoin/bitcoin, événement abondamment documenté à l’époque. (Wikipédia)

Maintainers, permissions GitHub et réalité du « pouvoir » sur le dépôt

Le dépôt de référence (bitcoin/bitcoin) fonctionne aujourd’hui avec un petit nombre de maintainers disposant des permissions nécessaires pour fusionner des PR et publier des versions, mais sans « pouvoir » de changer unilatéralement les règles de consensus du réseau : la validité d’un bloc ne dépend pas d’une clé GitHub mais du code effectivement exécuté par les nœuds. Les documents de contribution officiels insistent sur ce point : le projet suit un modèle ouvert, centré sur la revue par les pairs, sans statut privilégié au sens d’un droit d’imposer des changements de protocole. Des discussions publiques décrivent par ailleurs, de façon pragmatique, comment de nouveaux maintainers peuvent être proposés (nomination, accumulation d’ACK, ajout des clés) — procédure coutumière plutôt que charte rigide. (GitHub)

Sur le plan purement opérationnel, l’organisation GitHub « bitcoin-core » héberge plusieurs dépôts liés (site web, outils, attestations de build, librairies — secp256k1, minisketch, etc.), ce qui explicite la répartition des responsabilités entre le dépôt d’intégration/staging (bitcoin/bitcoin) et les dépôts satellites utilisés pour la fabrication et la vérification des versions. (GitHub)

De Gitian à Guix : signatures, attestations et vérification des binaires

Historiquement, les binaires officiels étaient reconstruits de façon déterministe via Gitian ; la chaîne outillée a ensuite basculé sur Guix pour renforcer la reproductibilité et réduire les dépendances « opaques ». Le processus de publication s’appuie aujourd’hui sur des attestations de build déposées dans le dépôt guix.sigs et sur un jeu de clés publiques de constructeurs (« builder keys ») auquel l’utilisateur final choisit explicitement de faire confiance. Les documents « Release process » et « Verify binaries » décrivent ces étapes : téléchargement des sommes de contrôle (SHA256SUMS/asc), vérification par pluralité de signatures, comparaison des hachages locaux aux hachages signés. L’utilisateur n’accorde pas sa confiance à une clé « racine » mais à un ensemble de clés de constructeurs connus, dont les empreintes sont publiées et importables sous GPG. (GitHub)

Méthode et limites — origine des « chiffres » : les empreintes de clés et listes de signataires proviennent des dépôts guix.sigs et des répertoires contrib/verify-binaries et contrib/verify-commits ; les instructions de vérification et d’attestation sont issues de la documentation développeurs (miroirs GitHub Pages). Ces sources primaires décrivent la procédure mais ne constituent pas une « autorité centrale » au sens PKI ; la confiance est distribuée par pluralité de signatures indépendantes. (GitHub)

Signatures de commits, trusted-keys et scripts de maintenance

Côté dépôt source, un second maillon de sécurité est la signature PGP des commits de merge effectués par les maintainers et la vérification de ces signatures contre une liste de clés « approuvées » par le projet. Le répertoire contrib/verify-commits propose un script de contrôle et une liste de trusted-keys ; la documentation précise la gestion des cas limites (expiration/révocation d’un sous‐clé, ajout sélectif de hachages dans allow-revsig-commits pour ne pas rebrousser tout l’historique lorsqu’une clé ancienne est révoquée). Les maintainers disposent en outre d’outils spécifiques (bitcoin-maintainer-tools) pour fusionner les PR et signer proprement les merges. (GitHub)

Limites et contraintes opérationnelles : la robustesse de cette chaîne dépend d’une hygiène des clés (rotation, publication d’empreintes, révocation), de l’attention des relecteurs et de la redondance des signataires de build. Des incidents bénins (clés mal publiées ou métadonnées incomplètes sur les serveurs de clés) rappellent que la vérification automatisée peut échouer pour des raisons logistiques, sans impliquer un défaut de sécurité du code. (GitHub).

L’« alert key » : un ancien point de centralisation supprimé

Indépendamment des clés de publication du code et des signatures de build, Bitcoin possédait à l’origine un mécanisme réseau spécial : la « clé d’alerte » (alert key), permettant de diffuser des messages d’alerte à l’ensemble des nœuds. Perçue comme un point unique de confiance et un vecteur d’abus potentiels, elle a été retirée du logiciel en 2016 ; son historique et les vulnérabilités connexes ont été documentés publiquement, puis la clé a été rendue publique en 2018 afin d’éviter tout soupçon de contrôle résiduel. Cet épisode illustre une tendance durable : la suppression des mécanismes centralisés non indispensables et la réduction des privilèges implicites. (en.bitcoin.it)

Qui « tient » les clés aujourd’hui et qu’est-ce que cela signifie réellement

En pratique, « tenir les clés » du dépôt signifie pouvoir :

a) signer et fusionner des PR dans bitcoin/bitcoin, sous contrôle social de la revue par les pairs ;
b) signer/attester des builds via Guix ;
c) signer les tags/release candidates conformément à la procédure de publication.

Ces pouvoirs n’autorisent ni changement de règles de consensus sans adoption sociale, ni contrôle du réseau. Ils s’exercent dans un cadre où la résistance aux erreurs repose sur la duplication (plusieurs maintainers, pluralité de signataires de build), la transparence (historique Git public) et la reproductibilité (Guix). L’existence d’un petit groupe de maintainers est un compromis entre efficacité (qualité du code, sécurité) et minimisation du pouvoir discrétionnaire ; la construction de la confiance s’opère par la visibilité des contributions, la qualité des revues et l’adhésion implicite de l’écosystème (nœuds, distributions, mineurs) aux releases publiées. (GitHub)

Points d’attention, incertitudes et « zones grises »

• Stabilité des listes de maintaineurs : les noms et rôles évoluent avec le temps (départs, nominations). Les articles de presse spécialisés reprennent ces mouvements, mais la source la plus fiable reste l’activité sur le dépôt et les PR de gestion des clés. Toute énumération « figée » est fragile ; il convient de privilégier la procédure (comment on devient maintainer) plutôt que l’instantané des personnes. (GitHub)
• Centralisation d’hébergement : GitHub est un point d’agrégation utile mais non exclusif ; la sécurité effective provient de la dissémination du code, de l’outillage de build reproductible et du fait que les nœuds n’appliquent un changement qu’en compilant et exécutant eux-mêmes un binaire vérifié. L’hébergement n’est pas la gouvernance du consensus. (GitHub)
• Seed nodes des origines : Aux débuts de Bitcoin, quelques nœuds dits seed nodes jouaient un rôle crucial : ils étaient codés en dur dans le logiciel pour aider un nouveau nœud à découvrir ses pairs lors de la connexion initiale. Ces adresses, maintenues par Satoshi puis par Gavin Andresen et d’autres développeurs précoces, représentaient une forme de centralisation initiale : contrôler un seed node, c’était influer sur la première perception qu’un nouveau client avait du réseau. Au fil du temps, la liste s’est diversifiée, intégrant des seeds opérés par plusieurs développeurs et entités, afin de réduire le risque de capture.

Ces deux éléments — seed nodes et clés critiques — rappellent que la décentralisation effective de Bitcoin ne se limite pas au consensus des blocs, mais s’étend aussi à l’infrastructure de découverte et à la chaîne de confiance logicielle. Leur gestion reste un enjeu sensible :

• trop de centralisation expose à des abus ou à une capture,
• trop de fragmentation complique la maintenance et la coordination.

Conclusion

L’historique des « clés » et accès critiques de Bitcoin Core révèle une architecture de confiance distribuée : les permissions GitHub et les signatures PGP structurent la supply chain du code et des binaires, mais n’accordent aucun pouvoir unitaire sur les règles de consensus. Les protections (revue par les pairs, signatures des merges, builds reproductibles et attestations multiples) forment un ensemble cohérent visant la minimisation du risque humain et organisationnel. Les épisodes passés — retrait de la clé d’alerte, rotations de mainteneurs, passage à Guix — s’inscrivent dans une trajectoire d’élimination des dépendances centralisées et d’élévation des garanties de reproductibilité.

Le processus de revue publique et les espaces de débat

La revue du code dans Bitcoin Core ne se limite pas à GitHub : elle s’inscrit dans un écosystème de discussions techniques ouvertes et documentées, où la légitimité d’un changement repose sur la qualité des échanges et la transparence du consensus obtenu.

GitHub comme support principal de la revue

• Chaque proposition de changement prend la forme d’une pull request (PR) sur le dépôt officiel bitcoin/bitcoin.
• Les relecteurs utilisent des commentaires précis et codifiés (ACK, NACK, Concept ACK, tACK, utACK) pour exprimer leur position.
• Les discussions sont archivées de manière permanente dans GitHub, permettant de retracer la généalogie des décisions.
• Les tests sont souvent reproduits localement par les reviewers (tACK), et des outils d’intégration continue (CI) exécutent une batterie de validations automatisées.

Bitcoin Core PR Review Club

• Chaque semaine, une PR est sélectionnée pour être étudiée collectivement.
• La séance se déroule en temps réel (souvent via IRC, puis relayée sur des plateformes comme Libera Chat), avec un animateur chargé de guider les échanges.
• Les comptes rendus sont publiés sur le site bitcoincore.reviews, qui constitue une mémoire technique et pédagogique des discussions.
• L’objectif est double : former de nouveaux relecteurs et élargir la base de participants capables d’évaluer du code critique.

Mailing list « bitcoin-dev »

• Hébergée historiquement sur SourceForge puis sur une infrastructure indépendante, la liste bitcoin-dev reste l’espace privilégié pour les débats de fond.
• On y discute des propositions de changements de protocole (BIP – Bitcoin Improvement Proposals), des questions de politique de standardisation, et des controverses d’architecture.
• La mailing list permet d’éviter que GitHub ne devienne l’unique point central, en offrant une archive indépendante et un lieu de réflexion moins lié aux contraintes du code source.

Réunions techniques périodiques

• Des réunions IRC régulières, dites Bitcoin Core dev meetings, rassemblent les contributeurs pour discuter de l’avancement des PR critiques, de la préparation des releases, et des priorités techniques.
• Les comptes rendus de ces réunions sont publiés en ligne, assurant une transparence complète.
• Ces moments de synchronisation permettent d’aborder les décisions transverses qui ne se prêtent pas aux seuls commentaires asynchrones de GitHub.

BitDevs et les débats en présentiel

• Les BitDevs sont des rencontres locales organisées dans plusieurs grandes villes (New York, Londres, Paris, Berlin, Austin, etc.).
• Elles réunissent développeurs et chercheurs pour des Socratic Seminars : chaque participant peut présenter un sujet technique récent (PR, BIP, incident de sécurité, évolution de politique).
• Bien que non officielles, ces rencontres jouent un rôle important : elles élargissent la communauté de relecteurs, favorisent la transmission de savoir et influencent indirectement le débat en ligne.
• Les comptes rendus et présentations sont parfois publiés, mais l’essentiel est l’échange direct, qui nourrit ensuite les discussions sur GitHub et la mailing list.

Gouvernance implicite et articulation des espaces

• GitHub est le lieu d’examen concret du code.
• La mailing list bitcoin-dev porte les débats conceptuels et normatifs (par ex. l’introduction de SegWit ou Taproot).
• Les Review Clubs structurent la montée en compétence des contributeurs.
• Les BitDevs renforcent les réseaux sociaux et la capacité de critique collective.

Ces différents espaces s’articulent en un système de gouvernance distribué, où aucun canal ne domine totalement. La force du modèle repose sur la multiplicité des lieux de débats, leur transparence (archives publiques), et la discipline sociale consistant à ne fusionner une PR qu’après un consensus explicite et argumenté.

La gouvernance de Bitcoin Core à travers le PR Review Club

Origine et objectifs du PR Review Club

Le Bitcoin Core PR Review Club a été lancé en 2019 avec un double objectif :

• abaisser la barrière d’entrée à la revue de code pour de nouveaux contributeurs ;
• institutionnaliser un espace de discussion technique publique et régulière.

La logique était simple : beaucoup de développeurs intéressés par Bitcoin n’osaient pas commenter des PR complexes de peur d’être jugés sur leur compétence. Le Review Club fournit un cadre pédagogique, avec des sessions animées par des contributeurs expérimentés, où chacun peut poser des questions et exprimer des doutes. Cela a progressivement formé une nouvelle génération de relecteurs capables de participer au processus de gouvernance technique.

Déroulement d’une session

Une fois par semaine, une PR est choisie parmi celles en attente dans le dépôt bitcoin/bitcoin.

• L’animateur publie en avance un ensemble de ressources : lien vers la PR, résumé des enjeux, et une liste de questions préparatoires.
• La session se déroule en direct (principalement sur IRC/Libera Chat).
• Les participants échangent en répondant aux questions, en testant le code localement, et en discutant des implications possibles.
• L’animateur veille à ce que la discussion reste constructive, inclusive et centrée sur le code.

Un compte rendu est ensuite publié sur bitcoincore.reviews, avec l’historique des questions et une synthèse. Ce site constitue donc une archive des débats publics et un outil de formation durable.

Transparence et gouvernance distribuée

Ce mécanisme illustre la manière dont la gouvernance de Bitcoin Core s’exerce :

• Pas de comité fermé : la légitimité des décisions découle de discussions ouvertes, consultables par tous.
• Traçabilité : chaque PR débattue dispose d’un historique de commentaires sur GitHub et d’un résumé public sur le site du Review Club.
• Éducation continue : les participants, même novices, apprennent la méthodologie de revue et les standards de qualité exigés.

Ainsi, la gouvernance n’est pas seulement un processus de validation technique mais aussi une dynamique sociale de transmission des normes.

Impact sur le consensus social

Le Review Club renforce le consensus social autour des changements :

• Les discussions préparent le terrain pour que davantage de développeurs se sentent capables d’ACK ou de NACK une PR.
• Les objections ou préoccupations identifiées en club sont souvent reprises sur GitHub, donnant plus de poids à certains points techniques.
• Le fait que ces discussions soient publiques et archivées protège contre l’idée d’un pouvoir caché : chaque étape de maturation d’une proposition est visible.

Limites et critiques

• Le Review Club reste dépendant du volontariat : toutes les PR ne passent pas par ce processus.
• La participation, bien que large, reste biaisée vers les contributeurs capables d’assister à l’heure fixée (souvent orientée vers l’Amérique du Nord et l’Europe).
• Les discussions sont publiques mais techniques : la compréhension demande déjà un investissement important, ce qui limite l’audience réelle.

Lien avec la gouvernance globale

Le PR Review Club ne décide pas des merges, mais il influence les équilibres de pouvoir :

• Une PR ayant été largement débattue en Review Club bénéficie d’une légitimité supplémentaire.
• Les nouveaux contributeurs y gagnent un capital social qui peut leur permettre, à terme, de devenir eux-mêmes relecteurs reconnus, voire maintainers.
• Il contribue donc à la reproduction de la gouvernance distribuée en élargissant le cercle des développeurs compétents.

Conclusion

À travers le PR Review Club, la gouvernance de Bitcoin Core se manifeste comme une combinaison de rigueur technique et de socialisation progressive. Ce processus, institutionnalisé mais ouvert, garantit que la revue du code ne soit pas réservée à une élite restreinte, tout en maintenant un haut niveau d’exigence. Le site bitcoincore.reviews cristallise cette démarche en offrant une mémoire collective transparente.

OP_RETURN : genèse, évolutions, enjeux et gouvernance

Contexte et création du paramètre

Origine historique (2013–2014)
Lorsque l’opcode OP_RETURN fut introduit (2013), la question du plafond de taille des données arbitraires est immédiatement devenue centrale.

• Par défaut, les transactions OP_RETURN pouvaient transporter jusqu’à 80 octets de données.
• Toutefois, certains opérateurs souhaitaient personnaliser ce plafond, soit pour tolérer davantage de données (ex. projets d’assets ou notarisation), soit pour réduire à zéro l’espace accordé aux métadonnées.

C’est dans ce contexte que le paramètre de configuration -datacarriersize a été introduit dans Bitcoin Core :

• il définissait la taille maximale des données relayées via une sortie OP_RETURN ;
• il s’agissait d’un paramètre de policy (règle de standardness), non de consensus : chaque nœud pouvait choisir son propre seuil.

Principales dates

• 2009–2011 : champ coinbase utilisé de manière détournée pour inscrire des données (identifiants de pool, slogans, hash de fichiers) limité à 100 otets.
• 2011–2012 : critiques de Luke Dashjr, Gregory Maxwell et Peter Todd : ces usages brouillaient le rôle monétaire de la coinbase et alourdissaient le parsing.
• 2013 : création d’OP_RETURN, sortie « brûlée » pour données arbitraires :
  • taille limitée à 80 octets,
  • une seule sortie par transaction,
  • pas de pollution de l’UTXO.

A noter que Luke Dashjr était à l’origine de la proposition d’OP_RETURN, puis a validé la proposition considérée alors comme une « propre » pour le réseau.

Spécifications techniques

• Nom : -datacarriersize
• Type : entier (octets)
• Défaut historique : 80
• Intervalle : entre 0 (désactive le relai des données arbitraires) et plusieurs centaines d’octets (selon les builds, certains opérateurs ont utilisé 223 ou 256).
• Effet : toute transaction contenant une sortie OP_RETURN avec plus de datacarriersize octets était considérée comme non standard et non relayée par défaut.

Usages constatés (2013–2021)

• Timestamping : preuve d’existence de documents.
• Tokens et actifs numériques : Open Assets, Omni Layer (USDT au début).
• Messages symboliques : slogans, hommages.
• Ancrages cryptographiques : Merkle roots de systèmes externes.

Point crucial : la majorité de ces usages ne cherchent pas l’efficience économique (stockage optimal), mais la visibilité sur Bitcoin. Le coût relatif des frais est jugé faible comparé aux bénéfices symboliques, marketing ou techniques d’avoir une inscription sur la blockchain la plus reconnue et la plus sécurisée.
Ainsi, même si les transactions sont plus chères que sur des layers ou d’autres blockchains, l’incitation reste forte pour des acteurs qui veulent la « preuve visible » sur Bitcoin, et parfois les assets représentés (ou les enjeux) dépassent et échappent largement aux repères du consensus basés sur les volumes en vbytes et les satoshis des transactions.

Motivations initiales

• Donner du contrôle aux opérateurs de nœuds : chacun pouvait exprimer sa préférence (tolérance large vs politique stricte).
• Éviter l’accumulation de spam : en fixant une limite basse par défaut (80 octets), Core préservait l’usage léger.
• Permettre la diversité : certains protocoles tiers (Omni, Open Assets) demandaient plus d’espace, mais ils devaient convaincre les opérateurs d’ajuster manuellement la limite.
• Arguments pour datacarriersize :
  • Flexibilité : les opérateurs pouvaient calibrer leurs nœuds selon leurs préférences ou les besoins locaux.
  • Barrière implicite contre l’abus : le défaut (80) empêchait les usages trop lourds sans consentement explicite.
  • Gouvernance distribuée : chacun décidait individuellement.
• Arguments contre :
  • Complexité de configuration : les comportements de relais devenaient hétérogènes.
  • Effet de fragmentation du mempool : une transaction valide pouvait circuler dans un sous-ensemble de nœuds mais pas dans l’ensemble du réseau.
  • Coût de coordination : pour qu’un protocole basé sur OP_RETURN fonctionne à grande échelle, il fallait convaincre beaucoup d’opérateurs de relever leur seuil.

Débat récurrent :

• Cas particuliers : certains mineurs et pools ajustaient leurs propres limites pour favoriser des usages spécifiques (notamment Omni/Tether).
• Débats récurrents : fallait-il supprimer le paramètre, le rendre plus permissif, ou au contraire bloquer totalement OP_RETURN ?
• Consensus implicite : le paramètre était utile pour garder une flexibilité, mais le défaut devait rester restrictif pour protéger les petits opérateurs.

Évolutions dans Core v30

• Suppression de la limite de 80 octets.
• Suppression de l’unicité des sorties OP_RETURN.

Core v30 : changement majeur de sémantique

Dans Core v30 (2024), datacarriersize a perdu son rôle historique de plafond strict.

• Les limites globales sur OP_RETURN ayant été supprimées (levée de la limite de 80 octets et suppression de l’unicité), datacarriersize n’a plus l’effet concret attendu.
• Des tests RC ont montré que le paramètre ne permettait plus de rétablir un plafond comme auparavant.
• La valeur par défaut (80) devient davantage symbolique qu’effective.

Motivations avancées par Core :

• Cohérence : si Core v30 autorise désormais plusieurs OP_RETURN sans limite, conserver un paramètre de taille stricte apparaissait incohérent.
• Simplification : réduire la diversité des politiques de relais et donc les divergences de mempool.
• Philosophie : le marché des frais doit réguler les abus, pas les paramètres locaux.

Réactions et position de Knots

Dans Knots (v29.1 et suivants) :

• datacarriersize conserve sa sémantique historique : un plafond strict est toujours applicable.
• Les opérateurs qui utilisent Knots peuvent donc encore :
  • interdire totalement les OP_RETURN (valeur 0),
  • limiter à 80 octets ou toute valeur choisie.
• Knots complète cette logique par d’autres garde-fous (-rejecttokens, -permitbaredatacarrier).

Doctrine Knots :

• Laisser le contrôle maximum à l’opérateur.
• Protéger la souveraineté individuelle sur ce que relaie un nœud.
• Préserver la rareté de l’espace de bloc en rendant coûteux ou invisibles les usages « non monétaires ».

Impact sur la gouvernance des opérateurs

• Avec Core v30 :
  • L’opérateur perd une partie de sa capacité à imposer des limites strictes via configuration (datacarriersize devenu moins efficace).
  • Le nœud relaie par défaut plus de transactions « de données » que certains pourraient considérer comme indésirables.
  • La gouvernance sociale se déplace vers les mineurs et le marché des frais.
• Avec Knots :
  • L’opérateur conserve un pouvoir réel de filtrage.
  • La souveraineté de chaque nœud est préservée : accepter ou non de relayer les usages non monétaires.
  • La gouvernance sociale s’exerce par le bas, via le choix individuel de chaque opérateur.

Gouvernance sociale et comportements induits

• Core v30 encourage :
  • la diversification des usages (inscriptions, tokens, registres distribués),
  • une régulation par les mineurs et les frais,
  • la cohérence entre consensus et policy.
• Knots encourage :
  • un Bitcoin minimal, recentré sur les paiements,
  • le recours aux layers pour usages complexes,
  • la souveraineté des opérateurs comme filtre social.

Opportunités et risques pour les layers

Avec Core v30 (plus permissif) :

• Opportunités :
• Opportunités pour les layers

Avec plus d’espace disponible (Core v30) :

• Sidechains / cross-chain anchoring : possibilité d’ancrer des états plus complexes et multiples.
• Lightning Network : stockage de métadonnées plus riches pour canaux avancés.
• Interopérabilité : une seule transaction peut servir de point d’ancrage à plusieurs systèmes.
• Inscriptions/tokens : facilitation des protocoles utilisant directement L1 pour visibilité.
• plus de données transportables sans contrainte → facilité d’ancrage pour sidechains, systèmes cross-chain, protocoles de notarisation, ou inscriptions.
• pas besoin de convaincre les opérateurs de modifier datacarriersize, donc adoption plus simple pour des projets cherchant une visibilité directe sur L1.
• Risques :
  • Logique de visibilité au détriment de l’efficience : ce qui prime, c’est d’être inscrit sur Bitcoin, même si un layer ou une sidechain serait plus efficace pour l’usage en question. Ces options existent déjà pour les spamers, qui préfèrent le mainnet.
  • encouragement des comportements visant la visibilité plus que l’efficience (par ex. inscriptions massives de données marketing).
  • saturation potentielle des mempools des petits nœuds, augmentant les coûts indirects de maintenance.

Avec Knots (plus restrictif) :

• Opportunités :
  • protection pour les opérateurs modestes : ils ne relaient pas de données lourdes qu’ils jugent inutiles.
  • incitation à utiliser des layers spécialisés (Lightning, sidechains, rollups) pour des usages non monétaires.
• Risques :
  • fragmentation : certaines transactions visibles sous Core ne circulent pas sous Knots, ce qui peut compliquer l’interopérabilité.
  • coût de coordination accru pour les projets externes cherchant un ancrage sur Bitcoin.

Gouvernance sociale

• Core v30 :
  • réduit la capacité des opérateurs à exprimer leurs préférences.
  • déplace la gouvernance vers les mineurs (qui décident via les blocs) et vers les frais (qui filtrent économiquement).
• Knots :
  • maintient la capacité des opérateurs à exprimer un choix local.
  • incarne une gouvernance « par le bas », où l’acceptabilité sociale des usages se construit via agrégation de préférences individuelles.

Comportements encouragés ou découragés

• Core v30 :
  • Encouragés : projets cherchant visibilité directe sur Bitcoin (tokens, ordinals, registres).
  • Découragés : recours à des contournements complexes pour stocker des données (moins nécessaire).
• Knots :
  • Encouragés : usages monétaires purs, recours aux layers pour le reste.
  • Découragés : stockage direct de données arbitraires sur L1.

Conclusion

Le paramètre datacarriersize illustre une divergence de gouvernance fondamentale :

• Dans Core v30, il devient largement symbolique, l’usage étant régulé par le marché des frais et les mineurs.
• Dans Knots, il reste un outil central permettant aux opérateurs de définir localement leurs préférences, incarnant l’idée que chaque nœud est souverain.

L’évolution d’OP_RETURN illustre parfaitement l’opposition entre deux doctrines :

• Core v30 : assouplir et laisser faire le marché, quitte à ouvrir la porte à des usages principalement motivés par la visibilité.
• Knots : maintenir la contrainte, décourager les usages non monétaires, préserver l’espace de bloc pour la monnaie.

La bataille n’est pas seulement technique : elle touche à la gouvernance de Bitcoin, entre régulation par le haut (mineurs + marché des frais) et régulation par le bas (choix des nœuds). 

Cette différence reflète deux philosophies :

• une gouvernance par le marché et l’harmonisation (Core),
• une gouvernance par la pluralité et la souveraineté individuelle (Knots).

Le paramètre rejecttokens : origine, enjeux et gouvernance

Origine et contexte

2022–2023 : l’explosion des « inscriptions » et tokens non natifs
L’apparition des Ordinals et d’autres méthodes d’inscription a provoqué une vague d’utilisation de Bitcoin pour stocker des images, du texte, et même des exécutables, directement dans les blocs. Cette pratique a soulevé de nombreux débats :

• certains y voient une expérimentation créative et un enrichissement de l’écosystème,
• d’autres y voient du spam qui surcharge la bande passante et détourne Bitcoin de son rôle monétaire.

C’est dans ce contexte que Luke Dashjr, mainteneur de Bitcoin Knots, introduit le paramètre -rejecttokens.

Spécifications techniques

• Nom : -rejecttokens
• Type : booléen (0/1)
• Valeur par défaut : activé dans Knots (1)
• Effet : un nœud configuré avec -rejecttokens=1 refuse de relayer (et, selon la config, de miner) les transactions considérées comme « tokens/inscriptions » (identifiées par motifs de script ou d’encodage spécifiques).

Remarque : ce n’est pas une règle de consensus. Les transactions restent valides au sens du protocole Bitcoin. Il s’agit d’une policy locale, qui agit sur le relais et la propagation des transactions.

Motivations initiales

1. Protéger l’espace de bloc pour les transactions financières.
2. Décourager le spam : éviter que des données volumineuses (images, contenus multimédias) saturent les mempools.
3. Préserver la décentralisation : limiter la charge disque et réseau sur les petits opérateurs de nœuds.
4. Exercer un choix social : permettre aux nœuds de signifier qu’ils n’acceptent pas les usages transformant Bitcoin en « système de tokens génériques ».

Débats et arguments

Arguments pour rejecttokens :

• Maintien de Bitcoin comme monnaie électronique pair-à-pair.
• Préservation des ressources : bande passante, stockage, latence.
• Lutte contre la centralisation : sans filtres, seuls les opérateurs puissants pourraient supporter les charges induites.
• Gouvernance par le bas : les nœuds expriment leurs préférences et ne délèguent pas entièrement aux mineurs.

Arguments contre :

• Risque de fragmentation du réseau : certaines transactions circulent sous Core mais pas sous Knots.
• Censure implicite : un opérateur de nœud choisit ce qui est « légitime », ce qui va à l’encontre d’une neutralité stricte.
• Opportunités perdues : tokens, inscriptions et registres pourraient attirer de nouveaux usages et renforcer l’écosystème.
• Débat sur la légitimité : qui décide si une transaction est un « token » ou un « spam » ?

Différences Core vs Knots

• Bitcoin Core :
  • Ne propose pas de paramètre équivalent.
  • Adopte une politique permissive : les transactions respectant les règles de consensus sont relayées si elles respectent les standards.
  • Les « tokens » et inscriptions passent donc librement par défaut.
• Bitcoin Knots :
  • -rejecttokens=1 est activé par défaut.
  • Introduit un filtrage explicite contre les inscriptions/tokens.
  • Propose à l’opérateur un contrôle fin pour renforcer la politique restrictive.

Impacts pour les layers et interopérabilité

• Avec Core (pas de rejet) :
  • Opportunités : protocoles de tokens, inscriptions, ancrages cross-chain sont facilités, plus visibles.
  • Risque : surcharge du réseau par des usages non monétaires.
  • Avantage pour les projets cherchant la visibilité sur Bitcoin (NFT, registres publics).
• Avec Knots (rejecttokens) :
  • Opportunités : préservation d’un réseau léger pour les paiements et la monnaie.
  • Risque : fragmentation — certaines transactions cross-chain ou d’ancrage d’état ne sont pas relayées, compliquant l’interopérabilité.
  • Incitation forte à développer ces usages en layers (Lightning, sidechains, rollups) plutôt que sur L1.

Gouvernance sociale

• Core :
  • Gouvernance « par le haut » : les règles de standardness sont uniformes, peu de place au choix individuel.
  • Décision implicite : si une transaction paie les frais, elle est relayée et minée.
• Knots :
  • Gouvernance « par le bas » : chaque opérateur décide s’il rejette ou non les tokens.
  • Incarnation de la souveraineté individuelle : un nœud peut marquer socialement son opposition aux usages perçus comme abusifs.

Comportements encouragés ou découragés

• Avec Core :
  • Encouragés : usages cherchant visibilité directe sur Bitcoin (NFT, tokens, ordinals).
  • Découragés : recours à des contournements techniques (car mo
  • ins nécessaires).
• Avec Knots :
  • Encouragés : paiements purs, ancrages légers, développement de solutions en couches supérieures.
  • Découragés : stockage direct de données multimédias ou de tokens sur L1.

Conclusion

Le paramètre rejecttokens est emblématique de la divergence entre Bitcoin Core et Bitcoin Knots :

• Core assume une politique permissive et neutre, misant sur les frais et les mineurs pour réguler les usages.
• Knots offre un outil explicite pour bloquer certaines catégories de transactions, affirmant une vision monétaire stricte et une gouvernance distribuée par les nœuds.

Il reflète deux conceptions de la souveraineté dans Bitcoin :

• Souveraineté des mineurs et du marché des frais (Core),
• Souveraineté des opérateurs de nœuds (Knots).

rejecttokens et la responsabilité du stockage et du relais des données

Un point souvent sous-estimé dans le débat est la responsabilité juridique et sociale induite par l’utilisation de Bitcoin comme support de données arbitraires.

Responsabilité du stockage

• Nature de Bitcoin : chaque nœud complet conserve une copie intégrale de la blockchain.
• Conséquence : si des contenus arbitraires (images, textes, exécutables) sont insérés dans L1, tous les opérateurs de nœuds les stockent sans possibilité de filtrage sélectif a posteriori.
• Risque : contenus sensibles, illégaux ou dangereux peuvent se retrouver distribués mondialement, exposant les opérateurs à une responsabilité involontaire (juridique, réglementaire ou éthique).

Responsabilité du relais

• Relayer une transaction signifie participer activement à sa diffusion sur le réseau.
• En l’absence de filtres, un nœud Core relaie par défaut tout ce qui respecte les règles de consensus.
• Cela place l’opérateur dans une position délicate : il devient partie prenante dans la dissémination de données potentiellement problématiques.

Risques identifiés

1. Juridique : responsabilité pénale ou civile dans certaines juridictions si le nœud contient ou diffuse des contenus interdits (pédopornographie, données personnelles sensibles, matériel protégé par copyright).
2. Réglementaire : pression possible sur les opérateurs, voire criminalisation de l’hébergement de nœuds.
3. Social : perte de légitimité de Bitcoin si le réseau est perçu comme un vecteur de diffusion de contenus illégaux.

Rôle de rejecttokens

Le paramètre rejecttokens agit ici comme un pare-feu préventif :

• il réduit la surface de risque pour les opérateurs de nœuds,
• il limite la probabilité que Bitcoin devienne une cible réglementaire directe pour stockage/diffusion de contenus illégaux,
• il rappelle que le choix d’un opérateur n’est pas seulement technique (performance du nœud), mais aussi social et politique (quelles données est-il prêt à stocker et relayer ?).

Différence de philosophie

• Core v30 (pas de rejet par défaut) :
  • considère que le réseau doit rester neutre et que la responsabilité incombe aux mineurs et aux utilisateurs,
  • mais de facto, tout nœud complet porte une partie de la responsabilité en stockant et relayant des données qu’il n’a pas choisies.
• Knots (rejecttokens activé par défaut) :
  • privilégie une politique défensive : limiter dès le départ l’inclusion de données arbitraires,
  • réduit la charge morale et juridique des opérateurs,
  • défend l’idée que Bitcoin doit rester centré sur les paiements pour ne pas mettre ses utilisateurs en danger.

Conclusion renforcée

rejecttokens n’est pas seulement un paramètre technique :

• c’est une réponse à un risque existentiel pour Bitcoin, lié à la responsabilité involontaire de ses utilisateurs.
• il illustre une vision selon laquelle protéger le réseau, c’est aussi protéger ses opérateurs contre des usages qui pourraient transformer Bitcoin en réceptacle de données problématiques.

En ce sens, l’introduction de ce paramètre par Luke Dashjr dépasse le cadre technique : il s’agit d’une mesure de préservation sociopolitique du protocole.

Le paramètre permitbaredatacarrier : origine, enjeux et gouvernance

Origine et contexte

Problème initial :
Depuis l’introduction d’OP_RETURN en 2013, il est apparu que certains acteurs créaient des transactions ne contenant que des sorties OP_RETURN, sans aucun transfert monétaire associé.

• Ces transactions dites « bare datacarrier » (transport de données « nues ») n’avaient pour seul but que de stocker des métadonnées sur la blockchain.
• Bien que valides au niveau du consensus, elles posaient deux difficultés :
  1. surcharge de la bande passante et de l’espace de bloc pour des usages non monétaires purs,
  2. dilution de la vocation de Bitcoin en « chaîne de paiements » au profit de son usage comme registre arbitraire.

Contexte de création du paramètre :
Pour donner aux opérateurs un contrôle direct sur ce point, Luke Dashjr a introduit dans Bitcoin Knots le paramètre permitbaredatacarrier.

• Objectif : offrir un garde-fou explicite contre la propagation de transactions « data only ».
• Valeur par défaut dans Knots : 0 (interdiction des transactions bare datacarrier).

Spécifications techniques

• Nom : -permitbaredatacarrier
• Type : booléen (0/1)
• Valeur par défaut : 0 (interdiction)
• Effet :
  • Si 0 : les transactions contenant uniquement des sorties OP_RETURN (et aucune sortie monétaire) ne sont pas relayées par le nœud.
  • Si 1 : le nœud accepte et relaie aussi ces transactions de type data only.

Motivations initiales

1. Préserver la fonction monétaire de Bitcoin : rappeler que chaque transaction devrait impliquer un transfert de valeur, pas seulement du stockage de données.
2. Protéger les petits opérateurs : éviter qu’ils aient à stocker et relayer des blocs encombrés de données arbitraires sans contrepartie financière directe.
3. Réduire le spam : empêcher que Bitcoin soit utilisé comme alternative à un espace de stockage distribué.
4. Donner du choix : permettre aux opérateurs de décider eux-mêmes s’ils tolèrent ces usages, plutôt que d’imposer une politique unique.

Arguments en faveur de l’interdiction (valeur par défaut = 0)

• Cohérence fonctionnelle : Bitcoin est une monnaie, pas un registre généraliste.
• Efficience : chaque octet sur la chaîne doit être justifié par un usage économique direct.
• Résilience : limiter les usages qui augmentent artificiellement la taille des blocs.
• Responsabilité : réduire le risque de porter ou relayer des données illégales ou dangereuses.

Arguments contre l’interdiction (en faveur de la valeur = 1)

• Neutralité : une transaction valide au consensus devrait pouvoir être relayée sans discrimination.
• Innovation : certaines applications légitimes (timestamping, ancrages, registres légers) pourraient vouloir utiliser exclusivement OP_RETURN.
• Liberté des utilisateurs : bloquer ces transactions par défaut revient à censurer certains usages de Bitcoin.
• Visibilité : certains projets préfèrent l’ancrage direct en L1 pour des raisons de marketing ou de confiance perçue.

Différences Core vs Knots

• Bitcoin Core :
  • Ne propose pas de paramètre équivalent.
  • Les transactions bare datacarrier sont relayées par défaut si elles respectent les règles générales de standardness.
  • La philosophie de Core est de minimiser les restrictions policy et de laisser les mineurs/frais arbitrer.
• Bitcoin Knots :
  • -permitbaredatacarrier=0 par défaut (donc blocage).
  • L’opérateur doit explicitement activer 1 s’il souhaite autoriser ces transactions.
  • La logique est d’imposer la sobriété par défaut, avec possibilité de déverrouillage volontaire.

Impacts pour les layers et interopérabilité

• Avec Core (permissif) :
  • Opportunités : protocoles de registres, d’actifs numériques ou de cross-chain anchoring peuvent utiliser directement L1 avec des transactions data only.
  • Risques : renforcement de la logique de visibilité au détriment de l’efficience (utilisation de Bitcoin comme « panneau publicitaire » ou registre symbolique).
• Avec Knots (restrictif) :
  • Opportunités : incitation à développer ces usages sur des layers supérieurs (Lightning, sidechains, rollups) qui sont techniquement mieux adaptés.
  • Risques : fragmentation du réseau si certains opérateurs choisissent d’autoriser permitbaredatacarrier=1 et d’autres non, créant des divergences de propagation.

Gouvernance sociale

• Core :
  • Gouvernance « par défaut permissif » : chaque utilisateur hérite d’un comportement de relais large, sauf à modifier le code.
  • Les mineurs et le marché des frais deviennent l’arbitre de fait.
• Knots :
  • Gouvernance « par défaut restrictif » : l’opérateur doit explicitement consentir à relayer ces usages.
  • Le pouvoir de filtrage est redonné aux nœuds, incarnant une gouvernance distribuée et locale.

Comportements encouragés ou découragés

• Avec Core :
  • Encouragés : inscriptions directes en L1, protocoles cherchant la visibilité sans transfert monétaire.
  • Découragés : recours à des contournements complexes pour insérer des données.
• Avec Knots :
  • Encouragés : transactions monétaires pures, recours aux layers pour ancrages.
  • Découragés : transactions purement symboliques ou marketing stockées directement en L1.

Conclusion

Le paramètre permitbaredatacarrier traduit une divergence nette :

• Core privilégie une neutralité maximale et relaie les transactions data only, considérant que les frais suffisent à filtrer les abus.
• Knots impose par défaut une discipline stricte, où une transaction doit impliquer un transfert de valeur, sauf choix explicite de l’opérateur.

En arrière-plan, la question dépasse la technique : elle concerne la responsabilité sociale et juridique des utilisateurs de Bitcoin. Relayer et stocker des données arbitraires, c’est potentiellement devenir porteur involontaire de contenus illégaux ou dangereux. Knots répond à ce risque en adoptant une politique restrictive par défaut, là où Core fait confiance à la neutralité et au marché. Chacun choisira son expositions aux risques avec Knots, alors que Bitcoin présume d’une liberté totale des utilisateurs par défaut.

Autres spécificités de Bitcoin Knots

-acceptunknownwitness

Origine :

• Avec l’introduction de SegWit (2017) et la possibilité de versions futures de témoins (witness versions), est apparue la question du comportement des nœuds face à des formats non encore standardisés.
• Core adopte une approche relativement permissive : relayer et accepter par défaut certaines versions de témoins inconnues (dans les limites de la standardness).

Knots :

• Introduit le paramètre -acceptunknownwitness.
• Permet à l’opérateur de choisir s’il accepte de relayer/miner des témoins dont la version n’a pas encore été définie officiellement.
• Valeur par défaut : restrictive (n’accepte pas par défaut).

Enjeux :

• Pour l’acceptation (Core) : facilite l’expérimentation, réduit les blocages lors de l’introduction de nouvelles constructions (taproot, futurs soft forks).
• Pour le rejet (Knots) : évite d’ouvrir une surface d’abus avec des formats « inconnus », qui pourraient être utilisés pour insérer des données arbitraires ou saturer le réseau.

Implication sociale :

• Core privilégie l’innovation rapide, quitte à tolérer du trafic incertain.
• Knots privilégie la stabilité et la protection de l’espace de bloc.

-minrelaycoinblocks et -minrelaymaturity

Origine :

• Certaines transactions dépensent des UTXO très récents (parfois dès leur apparition).
• Bien que valides en consensus, ces transactions augmentent la charge des mempools et peuvent être associées à du spam ou à des attaques par saturation.

Knots :

• Ajoute deux paramètres de contrôle :
  • -minrelaycoinblocks : exige qu’un UTXO ait atteint un certain nombre de blocs de maturité avant d’être relayé.
  • -minrelaymaturity : seuil exprimé en unités de valeur/temps pour exiger une ancienneté minimale des fonds dépensés.

Effet :

• Transactions dépensant des outputs trop jeunes sont rejetées au relai.

Enjeux :

• Avantage : réduit les attaques de spam où des outputs sont créés/dépensés massivement et immédiatement.
• Inconvénient : réduit la liquidité immédiate de certains usages légitimes (micropaiements rapides, tests).

-maxtxlegacysigops

Origine :

• Les sigops (signature operations) dans les scripts sont un paramètre sensible pour le coût computationnel de validation.
• Core applique une limite au niveau des blocs, mais les transactions individuelles peuvent être coûteuses.

Knots :

• Introduit -maxtxlegacysigops, qui impose un plafond au nombre de sigops autorisés par transaction standard.

Effet :

• Prévention proactive contre des transactions individuelles anormalement complexes.
• Protection contre des attaques de type « DoS computationnel » sur certains nœuds.

Enjeux :

• Avantage : sécurité et prévisibilité de la charge de validation.
• Inconvénient : peut bloquer des constructions légitimes de scripts complexes, notamment dans des usages expérimentaux.

ignore_rejects dans sendrawtransaction

Origine :

• Lorsqu’un nœud rejette une transaction pour des raisons de policy (non standard), il arrive que l’utilisateur veuille tout de même la forcer.
• Core ne permet pas de contourner facilement ces rejets locaux.

Knots :

• Introduit l’option ignore_rejects dans la RPC sendrawtransaction.
• Permet d’envoyer une transaction même si elle a été rejetée par certaines règles locales de policy.

Enjeux :

• Avantage : flexibilité pour les développeurs, tests, ou cas limites (transactions valides au consensus mais non standard).
• Inconvénient : risque d’affaiblir la cohérence des règles de standardness, d’introduire du spam ou des comportements divergents.

Gestion spécifique des « ephemeral anchors »

Contexte :

• Les ephemeral anchors sont des sorties spéciales utilisées comme points d’ancrage pour améliorer le mécanisme RBF (Replace-by-Fee).
• Ils permettent d’attacher des frais supplémentaires pour remplacer des transactions bloquées dans le mempool.

Core :

• Core a introduit un support permissif pour les ephemeral anchors.

Knots :

• Accepte ces sorties mais avec des conditions strictes :
  • valeur nulle,
  • taille minimale,
  • options de contrôle (-permitephemeral, -permitbareanchor).

Enjeux :

• Knots : adopte une approche conservatrice, cherchant à éviter les abus et à limiter les vecteurs de spam.
• Core : mise sur l’efficacité du marché des frais pour réguler ces usages.

Synthèse des différences philosophiques

Core :
Politique permissive par défaut.
Objectif : neutralité et adoption plus simple de nouvelles constructions.
Risque accepté : davantage de données, de diversité, et de trafic potentiellement « non monétaire ».

Knots :
Politique restrictive par défaut.
Objectif : préserver l’efficacité monétaire, limiter les charges pour les petits nœuds, réduire les responsabilités légales des opérateurs.
Risque accepté : fragmentation du réseau, rejet d’usages émergents.

Conclusion

Ces spécificités (-acceptunknownwitness, -minrelaycoinblocks, -minrelaymaturity, -maxtxlegacysigops, ignore_rejects, gestion stricte des ephemeral anchors) montrent que Knots n’est pas seulement un fork conservateur :

• C’est une implémentation qui introduit des outils supplémentaires de contrôle, souvent absents de Core, pour renforcer la souveraineté de l’opérateur et protéger la fonction monétaire de Bitcoin.
• Mais cette approche accentue la divergence de policy entre Core et Knots, compliquant les merges et augmentant le risque de fragmentation des mempools.

L’équilibre de Nash et la posture de Bitcoin Core

Notion d’équilibre de Nash appliquée à Bitcoin

Un équilibre de Nash désigne une situation où aucun acteur n’a intérêt à dévier unilatéralement de sa stratégie, car tout changement individuel le placerait dans une position moins favorable.
Dans Bitcoin, cela se traduit par l’idée que :

• chaque participant (mineur, opérateur de nœud, utilisateur, développeur) poursuit ses propres incitations,
• mais que le système doit se stabiliser autour d’un état où aucun acteur n’a intérêt à briser le consensus.

L’équilibre recherché dans Bitcoin combine donc :

• stabilité technique (règles de consensus acceptées),
• incitations économiques (frais et récompenses ajustent les comportements),
• cohérence sociale (valeurs et attentes partagées).

Posture de Core alignée sur l’équilibre de Nash

La philosophie de Bitcoin Core, en particulier visible dans la v30, peut être interprétée comme une recherche active de cet équilibre.

Neutralité du relais

• En supprimant les limites artificielles (80 octets pour OP_RETURN, unicité des sorties), Core aligne la policy sur le consensus.
• Ainsi, il réduit les zones de friction où des transactions valides mais non standard se propagent mal.
• Cela évite que des acteurs aient intérêt à « tricher » par des contournements (scripts complexes, inscriptions dans witnesses).

Incitations économiques

• Core renvoie au marché des frais la régulation des usages.
• Celui qui veut inscrire des données paiera ; celui qui ne veut pas relayer n’aura pas de levier durable, car les mineurs privilégieront les transactions les plus rémunératrices.
• La règle devient auto-exécutoire : chaque acteur maximise son intérêt individuel, et l’équilibre collectif en résulte.

Cohérence sociale minimale

• Core adopte une posture d’agnosticisme sur les usages : tant que la transaction est valide et qu’elle paie les frais, elle est acceptée.
• Ce choix évite d’imposer des préférences sociales subjectives, qui pourraient fragmenter la communauté.
• L’équilibre est ainsi défini par le point de rencontre des incitations économiques, plutôt que par une hiérarchie de valeurs imposée.

Les limites de cet alignement

Externalités négatives

• L’équilibre de Nash n’est pas nécessairement « optimal socialement ».
• Un usage économiquement viable (par exemple inscrire des images ou du spam) peut être rationnel pour un acteur, mais imposer des coûts aux autres (stockage, bande passante, responsabilité juridique).
• Core assume ce risque en pariant que le marché corrigera par les frais.

Déplacement du pouvoir

• En confiant la régulation au marché, Core transfère implicitement le pouvoir aux mineurs et aux utilisateurs à forte capacité de paiement.
• Les opérateurs de petits nœuds perdent une partie de leur rôle de filtre social.
• Ce déséquilibre peut mener à un effet de centralisation implicite : seuls les acteurs ayant des moyens financiers façonnent l’évolution de l’espace de bloc.

Comparaison avec Knots

Knots rejette cette approche d’équilibre par le marché.

• Pour Luke Dashjr, laisser faire les incitations économiques n’est pas neutre : c’est favoriser ceux qui veulent détourner Bitcoin en registre de données.
• Knots adopte une logique de barrières ex ante : empêcher certains usages dès le départ, pour préserver un autre équilibre — celui où les opérateurs actuels gardent la maîtrise et où la vocation monétaire prime.

Ainsi :

• Core vise un équilibre de Nash centré sur les incitations économiques (frais, consensus minimal, neutralité).
• Knots vise un équilibre de Nash centré sur la souveraineté locale (filtrage par les nœuds, coûts sociaux internalisés en amont).

Une tension entre deux équilibres possibles

Bitcoin se trouve à la croisée de deux équilibres :

1. Équilibre Core :
   • Les acteurs suivent les règles de consensus et laissent le marché arbitrer.
   • Pas d’incitation à dévier, car toute transaction rentable finit par être incluse.
   • Risque : externalités négatives imposées aux nœuds, centralisation implicite du pouvoir.
2. Équilibre Knots :
   • Les opérateurs actuels fixent des barrières strictes.
   • Pas d’incitation à dévier localement, car chacun garde le contrôle de ce qu’il relaie.
   • Risque : fragmentation des mempools, innovation bridée, perte d’attractivité pour de futurs usages.

Conclusion

La posture de Core peut être lue comme une recherche d’équilibre de Nash : aligner consensus, policy et incitations économiques, afin qu’aucun acteur n’ait intérêt à contourner les règles.
Mais ce choix fait porter des coûts sur les utilisateurs actuels pour favoriser un hypothétique marché futur.
Face à cela, Knots défend un autre équilibre : préserver la priorité des utilisateurs actuels, quitte à accepter une possible dépriorisation des utilisateurs futurs.

Le débat entre Core et Knots n’est donc pas une querelle marginale : il s’agit d’un affrontement entre deux visions de l’équilibre social de Bitcoin, et de la place que doivent y occuper les incitations économiques d’un côté, la souveraineté individuelle de l’autre.

Impacts directs de la v30 de Bitcoin Core sur Bitcoin Knots

Contexte général

La sortie de Bitcoin Core v30 (2024) marque une rupture par rapport aux versions précédentes, non pas en termes de consensus (aucune règle de validation n’a été modifiée), mais au niveau des policies de relais et de standardness.
Pour un projet dérivé comme Bitcoin Knots, qui maintient volontairement une ligne plus restrictive et conservatrice, cette bascule entraîne des impacts techniques, opérationnels et sociaux significatifs.

Divergences de mempool et propagation

Avant v30 :

• Les différences Core/Knots concernaient essentiellement quelques filtres optionnels (rejecttokens, permitbaredatacarrier) mais la base de la relay policy restait largement compatible.

Avec v30 :

• Transactions avec plusieurs OP_RETURN : relayées par Core, rejetées par défaut par Knots.
• Transactions avec OP_RETURN > 80 octets : relayées par Core, rejetées par Knots.
• Bare datacarrier : relayées par Core, bloquées par défaut dans Knots (permitbaredatacarrier=0).
• Tokens/inscriptions : relayés par Core, filtrés par Knots (rejecttokens=1).

Conséquence :

• Les mempools Core et Knots divergent systématiquement.
• Certaines transactions circulent largement dans un sous-réseau (Core), mais restent invisibles dans l’autre (Knots).
• Cela modifie les chemins de propagation, avec des effets potentiels sur la latence d’inclusion et la probabilité de confirmation rapide.

Modification du paramètre datacarriersize

Dans Core v30 :

• datacarriersize perd son rôle de plafond strict.
• Les opérateurs ne peuvent plus restaurer facilement la limite de 80 octets.

Dans Knots :

• Le paramètre garde sa sémantique historique.
• Les configurations héritées de v29 continuent de fonctionner comme attendu.

Impact :

• Les fichiers de configuration ne sont plus portables entre Core et Knots.
• Les opérateurs doivent maintenir deux configurations distinctes selon l’implémentation.

Dette de maintenance et rebase

Situation de Knots :

• Knots intègre des patchs spécifiques (policy restrictive, nouveaux paramètres, RPC modifiés).
• Avec v30, les changements massifs de policy de Core obligent Luke Dashjr à :
  • réimplémenter certaines limitations supprimées par Core,
  • maintenir la compatibilité avec les API et RPC,
  • tester les divergences pour éviter des régressions.

Conséquence :

• Augmentation du coût de maintenance (tests, merges, documentation, packaging).
• Chaque release de Core devient plus coûteuse à intégrer dans Knots.
• Risque d’allongement du cycle de publication de Knots.

Effets sur l’écosystème et les intégrations

• Explorateurs, indexeurs et wallets : doivent tenir compte des différences Core/Knots (par ex. certaines transactions « rejetées localement » dans Knots peuvent apparaître « invalides » pour un utilisateur qui n’a pas conscience des divergences de policy).
• Interopérabilité inter-chaînes : un projet cross-chain qui ancre des états volumineux via OP_RETURN sera relayé dans Core mais pas dans Knots, réduisant la visibilité et la fiabilité de ses ancrages.
• Pools de minage : si une majorité des pools tourne sur Core, les transactions rejetées par Knots finiront tout de même par être minées, mais avec des délais de propagation accrus.

Impact social et gouvernance

Avec Core v30 :

• La gouvernance implicite se déplace vers les mineurs et le marché des frais.
• Les utilisateurs doivent accepter que leur nœud relaie la majorité des usages arbitraires (inscriptions, tokens), sauf modification locale du code.

Avec Knots :

• La gouvernance reste entre les mains des opérateurs de nœuds.
• Chaque opérateur exprime une préférence locale, ce qui peut être vu comme une forme de « veto social » contre les usages indésirables.

Conséquence :

• Fragmentation des règles sociales :
  • Core encourage une uniformité permissive,
  • Knots incarne une diversité de choix locaux.
• Tension accrue entre deux visions du rôle de Bitcoin :
  • un réseau monétaire neutre et universel (Core),
  • un système monétaire strictement orienté paiements (Knots).

Responsabilité et risques

• Sous Core v30 :
  • Les nœuds relaient automatiquement des données arbitraires (images, tokens, textes).
  • Les opérateurs assument malgré eux une responsabilité juridique et sociale en stockant et relayant des contenus potentiellement illégaux.
• Sous Knots :
  • Les filtres (rejecttokens, permitbaredatacarrier=0) réduisent cette responsabilité.
  • Les opérateurs gardent la maîtrise de ce qu’ils stockent et relaient.

Conclusion

La sortie de Core v30 représente une inflexion majeure qui élargit l’espace des usages possibles via OP_RETURN, mais au prix d’une divergence structurelle avec Knots.

• Sur le plan technique : mempools différents, configs incompatibles, dette de maintenance accrue.
• Sur le plan opérationnel : propagation asymétrique, risques de confusion pour les intégrations.
• Sur le plan social : bascule vers une gouvernance par le marché et les mineurs (Core) contre une gouvernance distribuée par les opérateurs de nœuds (Knots).

Cette situation accroît la polarisation de l’écosystème :

• Core ouvre Bitcoin à des usages variés, mais augmente la responsabilité des opérateurs et la centralisation implicite autour des mineurs.
• Knots maintient une ligne stricte, protégeant les petits opérateurs mais acceptant le risque de fragmentation.

Enjeux stratégiques de la coexistence Core / Knots

Introduction

Bitcoin ne repose pas sur un logiciel unique mais sur un consensus social incarné dans du code. L’existence de plusieurs implémentations (Core, Knots, et d’autres plus marginales comme btcd ou Libbitcoin) témoigne de la diversité de visions autour de la gouvernance et des usages légitimes du protocole.
Parmi elles, Knots, initié par Luke Dashjr, joue un rôle particulier : non pas remplacer Core, mais offrir une variante plus stricte et plus conservatrice. Cette coexistence est un facteur de résilience, mais elle soulève aussi des tensions et des risques.

Bénéfices stratégiques de la coexistence

Diversité logicielle et résilience

• La présence de Knots empêche Core de devenir une monoculture absolue.
• En cas de vulnérabilité critique ou de capture idéologique de Core, Knots offre une base alternative immédiatement utilisable.
• Cela réduit le risque systémique lié à la centralisation du développement.

Contrepoids doctrinal

• Core a évolué vers une politique plus permissive, privilégiant la neutralité du marché.
• Knots incarne une doctrine opposée : Bitcoin comme monnaie stricte, sobre et résistante au spam.
• Cette tension force la communauté à débattre continuellement des orientations, au lieu d’accepter une inertie silencieuse.

Souveraineté des opérateurs

• Avec Core, les opérateurs ont peu de leviers de contrôle policy.
• Knots réintroduit ces leviers (rejecttokens, permitbaredatacarrier, datacarriersize strict, etc.).
• Cela redonne aux nœuds un rôle de gouvernance active, contrebalançant la centralisation implicite autour des mineurs.

Risques liés à la fragmentation

Divergence de mempools

• Depuis la v30, certaines transactions circulent dans Core mais pas dans Knots.
• Cela crée des expériences utilisateurs différentes (transaction « invisible » pour un opérateur Knots mais visible dans un explorateur basé sur Core).
• Risque d’incompréhension et de perte de confiance pour les utilisateurs non experts.

Dette de maintenance

• Chaque divergence accroît le coût d’intégration pour Knots.
• Cela dépend fortement de l’investissement de Luke Dashjr, avec peu de développeurs permanents autour.
• Risque : si le projet s’essouffle, la diversité logicielle pourrait se réduire.

Risque politique

• Des acteurs hostiles à Bitcoin pourraient exploiter ces divergences pour dire : « le réseau est fragmenté », et plaider pour une standardisation externe (réglementaire).
• Cela rend plus visible la tension entre gouvernance technique et gouvernance sociale.

Critiques récentes adressées à Core (au-delà de la v30)

Neutralité supposée de la policy

• Core affirme relayer toutes les transactions valides dès lors qu’elles respectent la standardness.
• Mais la standardness est elle-même un choix social : certains voient dans la v30 une décision politique (favoriser inscriptions et tokens en ouvrant OP_RETURN).
• Ainsi, la prétendue « neutralité » est contestée.

Centralisation implicite autour des mainteneurs

• Même si les merges sont basés sur consensus social, le petit nombre de maintainers disposant des clés critiques concentre une responsabilité importante.
• Des critiques accusent Core d’être trop fermé, ou d’influencer la gouvernance par défaut à travers ses releases officielles.

Évolutions controversées

• Outre OP_RETURN et datacarriersize, d’autres changements (ephemeral anchors, assouplissement des règles witnesses) sont critiqués comme ouvrant des surfaces d’abus.
• Core est accusé de privilégier l’expérimentation au détriment de la sobriété.

Fonction de Knots dans ce contexte

Garde-fou idéologique

• Knots incarne la mémoire des choix conservateurs historiques.
• Même si minoritaire, il prouve qu’il existe une base technique pour une autre vision.

Signal politique

• Le simple fait que Knots rejette par défaut certaines transactions agit comme un signal social :
  • Bitcoin n’est pas unanimement favorable aux inscriptions et aux tokens.
  • Des opérateurs choisissent activement une autre politique.

Laboratoire policy

• Knots propose des paramètres absents de Core (rejecttokens, minrelaymaturity, etc.).
• Cela offre un terrain d’expérimentation pour tester des politiques de filtrage.
• Ces expériences nourrissent le débat global, même si elles ne sont pas reprises dans Core.

Implications sociales et politiques

Pour les utilisateurs finaux

• Ils bénéficient de la diversité : chacun peut choisir Core (permissif) ou Knots (restrictif).
• Mais ils subissent aussi la confusion : pourquoi une transaction circule-t-elle dans un explorateur et pas dans leur nœud ?

Pour les mineurs

• Si la majorité des pools utilisent Core, les transactions rejetées par Knots finiront tout de même par être minées.
• Mais la propagation peut être ralentie, créant des incitations économiques différenciées.

Pour la gouvernance globale

• La coexistence de Core et Knots illustre que Bitcoin est gouverné par le code, mais surtout par le choix des utilisateurs.
• Chaque opérateur exprime un vote implicite : exécuter Core ou Knots, et avec quelle configuration.
• Ce mécanisme confirme la nature polycentrique de la gouvernance Bitcoin.

Conclusion

La coexistence de Bitcoin Core et Bitcoin Knots est à la fois une force et une tension :

• Une force, car elle offre une résilience logicielle, une diversité doctrinale, et un garde-fou contre la capture de Core.
• Une tension, car elle entraîne fragmentation, dette de maintenance, et confusion pour les utilisateurs.

Au-delà de l’aspect technique, le débat révèle une opposition fondamentale :

• Core incarne la neutralité permise par le marché des frais et la centralité des mineurs.
• Knots incarne la sobriété monétaire et la souveraineté des opérateurs de nœuds comme barrière sociale.

Cette opposition n’est pas un défaut, mais un élément constitutif de la gouvernance distribuée de Bitcoin : un équilibre fragile entre ouverture et discipline, innovation et conservation, marché et communauté.

Une décision non contrainte par un problème technique immédiat

Contrairement à d’autres évolutions du protocole (SegWit en 2017 pour régler la maleabilité des transactions, Taproot en 2021 pour élargir les primitives cryptographiques), la v30 n’est pas née d’une nécessité technique absolue et une initiative de « package » de ces évolutions pluttôt à l’initiative des mainteneurs de Bitcoin Core.

Aucun bug critique ne rendait l’ancien modèle d’OP_RETURN inopérant.

• Aucun consensus social massif ne réclamait la levée des limites.
• Les contournements existants (via witnesses ou scripts complexes) n’avaient pas saturé la chaîne au point de mettre le réseau en danger.

Constat : la v30 est un choix proactif, non une réponse contrainte.

Motivations explicites de Core

Les discussions publiques autour de v30 font apparaître trois justifications principales :

Réduire les contournements techniques

• • En assouplissant OP_RETURN, Core espère décourager l’usage de constructions détournées (OP_FALSE OP_IF, inscriptions massives dans les témoins).
  • Argument : mieux vaut un canal explicite, visible, encadré, que des abus cachés ailleurs.

Harmoniser consensus et policy

• • La philosophie Core est que les règles de standardness devraient tendre à refléter les règles de consensus, pour limiter les divergences entre ce qui est techniquement valide et ce qui est relayé.
  • Cela réduit la « zone grise » où une transaction valide mais non standard circule mal.

Neutralité économique

• • En supprimant les limites arbitraires, Core renvoie le filtrage au marché des frais et aux mineurs.
  • Motivation idéologique : Bitcoin doit rester neutre et agnostique, sans imposer de préférences sociales via la relay policy.

Motivations implicites et critiques

Cependant, plusieurs critiques pointent que ces justifications ne suffisent pas à expliquer l’empressement ou la portée du changement.

Une réponse à un débat social plus qu’à un problème technique

• • Les contournements par witness ne menaçaient pas la stabilité du réseau.
  • Le choix d’ouvrir OP_RETURN revient donc à donner une légitimité implicite aux inscriptions et aux tokens.
  • Cela apparaît comme une prise de position dans le débat Ordinals/tokens, en faveur de la permissivité.

Risque de capture idéologique

• • Certains craignent que Core ait intégré une vision plus « neutre-marché » où tout usage est acceptable tant qu’il paie des frais, même si cela change la nature socio-économique de Bitcoin.
  • Ce choix n’était pas forcé, mais relève d’une orientation politique assumée.

Mise à l’épreuve du consensus social

• • En introduisant v30, Core « provoque » un test : la communauté accepte-t-elle de relayer massivement ces usages, ou des forks/policies alternatives (comme Knots) vont-elles se renforcer ?
  • C’est une manière de trancher implicitement un débat social, en laissant les opérateurs choisir leur camp.

Pourquoi créer un débat « inutile » ?

• Pour Core :
  • L’idée est d’anticiper les conflits futurs en normalisant un canal explicite (OP_RETURN élargi) plutôt que de laisser croître des usages hors contrôle.
  • C’est une stratégie de gestion des externalités : canaliser plutôt qu’interdire.
  • Provoquer l’obligation de choix entre Bitcoin Core et Knots
• Pour Knots :
  • Ce changement est perçu comme inutile et dangereux : il n’y avait pas de problème structurel, et cette décision accroît la responsabilité des utilisateurs (stockage de données illégales, surcharge réseau).
  • La v30 est donc vue comme une provocation idéologique, destinée à forcer une normalisation des usages « non monétaires ».

Conclusion critique

La v30 de Core illustre que dans Bitcoin, les débats politiques naissent souvent là où il n’y a pas de contrainte technique immédiate.

• Core a choisi de lever des limites pour harmoniser et « neutraliser » la policy.
• Mais ce choix ouvre un front idéologique : faut-il considérer Bitcoin comme un système monétaire strict, ou comme une plateforme neutre acceptant tout usage tant qu’il est payé ?

En ce sens, la v30 ne résout pas un problème, elle en crée un par choix délibéré, transformant une tension latente en débat explicite.

Conclusion générale

L’étude des divergences entre Bitcoin Core et Bitcoin Knots révèle bien plus qu’un désaccord technique sur la gestion de quelques paramètres de policy. Elle met en lumière la manière dont la gouvernance de Bitcoin s’exerce, à la croisée de contraintes techniques, d’enjeux sociaux et de visions philosophiques opposées.

Une histoire façonnée par la gouvernance du code

Depuis Satoshi et le passage des clés du dépôt à Gavin Andresen, puis à Wladimir van der Laan et enfin au collectif actuel de maintainers, Bitcoin Core s’est imposé comme la référence de facto.
Mais son autorité ne repose pas sur le consensus technique du protocole, plutôt sur le consensus social des utilisateurs qui choisissent de suivre ses releases. Les outils de revue (GitHub, mailing list, Review Club, BitDevs) incarnent ce modèle polycentrique où la légitimité vient de la transparence et de la discussion publique.

Knots, initié par Luke Dashjr, s’inscrit dans cette histoire comme une implémentation alternative : non pas pour créer une scission de consensus, mais pour rappeler qu’il existe une voie plus stricte, où les opérateurs de nœuds conservent un contrôle étendu sur ce qu’ils acceptent de relayer et stocker.

Les paramètres au cœur des tensions

Chaque paramètre analysé (OP_RETURN, datacarriersize, rejecttokens, permitbaredatacarrier, acceptunknownwitness, etc.) raconte une même histoire :

• Core tend à supprimer ou affaiblir les garde-fous, au nom de la neutralité et de la cohérence entre consensus et policy.
• Knots maintient ou introduit des garde-fous, au nom de la sobriété monétaire, de la protection des petits opérateurs et de la responsabilité sociale.

Ainsi, OP_RETURN illustre le basculement : conçu comme compromis minimal en 2013, il devient en 2024 un vecteur de données arbitraires élargi, non limité par Core. Knots en conserve l’esprit initial.

La v30 : un choix politique

La sortie de Core v30 n’était pas dictée par une contrainte technique ou un bug critique.

• Elle n’a résolu aucun problème de consensus.
• Elle n’a pas répondu à une urgence de sécurité.
• Elle a, au contraire, ouvert un débat social sur la légitimité des inscriptions et tokens, en rendant leur propagation plus simple et plus visible.

Les motivations affichées (réduire les contournements, harmoniser consensus et policy, laisser le marché arbitrer) sont légitimes. Mais la critique formulée par Knots et ses partisans est que ce choix n’était pas nécessaire, et qu’il expose les utilisateurs à de nouveaux risques (surcharge, stockage de données illégales, responsabilité involontaire).

En ce sens, Core n’a pas éteint une controverse : il l’a provoquée.

Les impacts pour l’écosystème

• Techniques : divergence de mempool, configurations non compatibles, dette de maintenance accrue pour Knots.
• Opérationnels : propagation asymétrique, confusion pour les utilisateurs et intégrateurs.
• Sociaux : polarisation entre deux visions de la gouvernance — centralité des mineurs et du marché (Core) vs souveraineté distribuée des nœuds (Knots).
• Politiques : ouverture d’un débat sur la responsabilité des opérateurs : doivent-ils être de simples relais neutres, ou des acteurs qui choisissent activement ce qu’ils acceptent d’héberger ?

Une tension constitutive de Bitcoin

La coexistence de Core et Knots est à la fois :

• une force : diversité logicielle, résilience contre la capture d’un projet unique, garde-fou idéologique ;
• un risque : fragmentation du réseau, confusion pour les utilisateurs, pression accrue sur les mainteneurs de Knots.

Cette tension reflète l’essence même de Bitcoin : un système qui n’est jamais gouverné par une seule entité, mais par la somme des choix individuels.

Le dilemme entre marché futur et utilisateurs actuels

Bitcoin est confronté à une question de gouvernance fondamentale : qui doit définir les priorités du réseau ?

Pouvoir au marché des utilisateurs futurs (logique Core)

En assouplissant les règles (OP_RETURN élargi, disparition de la limite stricte datacarriersize), Core délègue la régulation au marché des frais.

Ce marché inclut potentiellement des usages futurs, pas encore massifs mais porteurs de croissance (tokens, inscriptions, registres inter-chaînes).

• La priorité est donnée à l’ouverture et à la neutralité, permettant à de nouveaux entrants d’utiliser Bitcoin sans restriction sociale préalable.

Risques :

1. Les opérateurs actuels doivent supporter dès aujourd’hui les coûts (stockage, bande passante, responsabilité légale).
2. La gouvernance échappe en partie aux utilisateurs de terrain, qui ne peuvent plus filtrer facilement ce qu’ils considèrent comme abusif.
3. Les usages futurs deviennent une promesse incertaine qui dépriorise les besoins actuels (paiements sobres, légèreté des nœuds).

Pouvoir aux utilisateurs actuels (logique Knots)

• En maintenant des garde-fous (rejecttokens, permitbaredatacarrier=0, datacarriersize strict), Knots affirme que les utilisateurs actuels sont le marché, et que ce sont leurs préférences présentes qui fixent les règles sociales.
• Cela protège l’espace de bloc contre une utilisation opportuniste par des acteurs dont l’objectif principal est la visibilité et non l’efficience.
• Le réseau reste soutenable pour les opérateurs modestes, qui incarnent le socle de la décentralisation.

Risques :

1. Cette approche peut freiner l’innovation ou dissuader de nouveaux usages qui auraient pu trouver une place légitime.
2. Les futurs utilisateurs potentiels peuvent se détourner de Bitcoin au profit d’autres blockchains plus ouvertes.
3. Le marché se ferme sur lui-même, au risque d’une perte relative d’attractivité dans l’écosystème multi-chaînes.

Une tension irréductible

• Vision Core : parier sur les utilisateurs futurs, même au prix d’un coût immédiat pour les actuels.
• Vision Knots : défendre les utilisateurs actuels, même au risque de décourager des apports futurs.

Aucune des deux approches n’est exempte de danger :

• ouvrir trop largement peut transformer Bitcoin en registre de données encombré et juridiquement vulnérable,
• fermer trop strictement peut l’isoler et le réduire à une niche monétaire, alors que d’autres chaînes capteront la diversité des usages.

Ce dilemme illustre que Bitcoin n’est pas seulement un protocole technique, mais un champ de tension entre présent et futur, sobriété et ouverture, continuité et adaptation.

Du point de vue économique

Bitcoin Core vu par l’école autrichienne

• Principe : Core mise sur le marché libre comme régulateur.
• En supprimant les barrières « arbitraires » (limites OP_RETURN, datacarriersize strict), Core s’aligne avec l’idée autrichienne que ce sont les choix individuels, motivés par les incitations économiques (paiement des frais), qui doivent guider l’évolution.
• Lecture autrichienne : cela correspond à une forme de « catallaxie » (Hayek) — l’ordre spontané qui émerge des interactions volontaires entre participants, sans planification centrale.
• Avantage perçu : ouverture à l’innovation, émergence d’usages imprévisibles mais peut-être créateurs de valeur.
• Risque : externalités négatives. Comme Mises le soulignait, un marché n’est efficient que si les coûts sont internalisés ; or ici, certains coûts (stockage, responsabilité juridique) sont supportés par les opérateurs de nœuds qui n’ont pas choisi ces usages.

Bitcoin Knots vu par l’école autrichienne

• Principe : Knots permet aux opérateurs actuels d’exprimer leurs préférences locales (via rejecttokens, permitbaredatacarrier=0, datacarriersize strict).
• Cela correspond à l’idée autrichienne que la valeur est subjective et doit être déterminée par chaque individu. Ici, l’opérateur choisit de ne pas relayer ce qu’il juge inutile ou nuisible.
• Lecture autrichienne : c’est une forme de gouvernance distribuée par la préférence révélée — chaque nœud est un marché en miniature, et l’ensemble constitue une agrégation polycentrique.
• Avantage perçu : discipline monétaire, protection des petits opérateurs, alignement sur la fonction originelle de Bitcoin (moyen d’échange pair-à-pair).
• Risque : risque de « marché cloisonné » : en donnant un poids disproportionné aux acteurs actuels, on freine l’arrivée de nouveaux usages qui auraient pu être valorisés par des utilisateurs futurs. Cela rejoint une critique autrichienne classique de l’« immobilisme » si les acteurs refusent d’adapter leurs règles.

Synthèse selon les principes autrichiens

• Core reflète l’optimisme hayékien envers l’ordre spontané du marché libre : laisser circuler toutes les transactions valides et laisser les incitations économiques arbitrer.
• Knots reflète l’exigence misésienne que les coûts doivent être supportés par ceux qui choisissent — ici, les nœuds refusent d’être forcés à supporter des charges qu’ils ne valorisent pas.

L’opposition entre les deux peut être formulée ainsi :

• Core privilégie le pouvoir au marché futur des utilisateurs potentiels, au prix d’une contrainte accrue sur les opérateurs actuels.
• Knots privilégie le pouvoir aux utilisateurs actuels pour fixer leurs règles, au prix d’une possible dépriorisation des usages futurs.

Bitcoin Core selon la vision classique

• Neutralité et circulation libre : dans la tradition classique, la richesse vient de la libre circulation des biens et services.
  • Core, en supprimant les restrictions de policy (ex. limites d’OP_RETURN), s’aligne avec l’idée que le marché doit absorber et redistribuer les ressources selon l’offre et la demande.
• Rôle des frais comme prix d’équilibre : les frais de transaction jouent le rôle du prix qui équilibre l’offre (espace de bloc limité) et la demande (usages divers, monétaires ou non).
  • Cette logique correspond au principe ricardien : les prix s’ajustent pour refléter la rareté relative et orienter les comportements.
• Avantage perçu : efficience par l’ajustement naturel des prix. Les mineurs, motivés par la maximisation de revenus, sélectionneront les transactions les plus valorisées par le marché.
• Risque : externalités négatives non prises en compte (charge de stockage imposée aux nœuds, responsabilité de relayer des données), ce que les classiques reconnaissaient comme une limite des marchés libres lorsqu’il s’agit de biens publics ou de coûts diffus.

Bitcoin Knots selon la vision classique

• Discipline et limites imposées : Knots, en introduisant des restrictions explicites (rejecttokens, permitbaredatacarrier=0), agit comme une forme de régulation destinée à protéger la productivité fondamentale du réseau.
  • Pour les classiques, l’objectif central de l’économie est la production et la circulation de biens ayant une utilité réelle. Knots incarne ce souci : protéger la fonction monétaire contre les usages jugés improductifs.
• Préservation des coûts de production : les classiques (notamment Ricardo) insistaient sur le fait que la valeur dépend des coûts de production. Or, saturer Bitcoin avec des données arbitraires accroît les coûts (stockage, bande passante) sans augmenter la valeur monétaire produite.
• Avantage perçu : discipline économique, conservation des ressources rares (espace de bloc) pour les usages jugés essentiels.
• Risque : risque de rigidité — en fermant l’accès à certains usages, Knots peut empêcher des opportunités d’innovation qui auraient pu s’avérer productives. Les classiques, favorables au commerce international et à l’élargissement des échanges, auraient pu y voir une barrière injustifiée.

Synthèse selon la pensée classique

• Core incarne l’optimisme classique dans le mécanisme de marché : laisser les prix (frais) ajuster l’allocation de la ressource rare (espace de bloc).
• Knots incarne une prudence classique, proche de Say et Ricardo, qui considéraient que les ressources doivent être orientées vers des usages productifs et que certaines limitations peuvent être légitimes pour éviter un gaspillage ou une désorganisation.

Ainsi :

• Vision Core : marché libre → prix (frais) comme arbitre → équilibre naturel de l’offre et de la demande.
• Vision Knots : régulation sobre → protection des coûts de production → préservation de la fonction monétaire comme base productive.

Conclusion finale

Bitcoin n’est pas qu’un protocole technique : c’est un espace de négociation sociale.

Chaque paramètre de relay policy incarne un compromis entre efficacité économique, neutralité technique, et responsabilité sociale.

• Core et Knots ne sont pas des implémentations rivales au sens classique, mais des manifestes de gouvernance opposés.
• Core choisit d’ouvrir et de neutraliser : laisser les mineurs et le marché trancher.
• Knots choisit de restreindre et de responsabiliser : laisser les nœuds exprimer leurs préférences locales.

L’histoire récente (Core v30) montre que même en l’absence de problème technique urgent, des décisions peuvent provoquer des débats fondamentaux. C’est le signe que Bitcoin vit non seulement comme un code, mais comme une communauté en perpétuel dialogue sur sa propre nature.

Article publié originellement sur linkedin.

---

A propos de l’auteur

Cofondateur de 4NK, Nicolas Cantu est entrepreneur, conférencier, enseignant et expert de Bitcoin de longue date.