• Bitcoin, policy et souveraineté des ressources : ce qui a changé dans ma confiance
  • Le mempool n’est pas seulement une prédiction du prochain bloc
  • Une ressource rare implique un choix
  • Ce que datacarriersize représentait
  • La liberté dans le code source et la liberté dans le nœud ne produisent pas le même coût
  • Core 30 n’est pas un événement isolé dans la conception du mempool
  • « Elle sera minée quand même » ne rend pas la policy inutile
  • Le marché des frais lui-même change lorsque le relay devient privé
  • Un nœud ne se réduit pas à un observateur des mineurs
  • blocksonly ne répond pas à cette question
  • La bonne policy ne peut pas être connue centralement
  • Pourquoi cela touche, pour moi, à la qualité de la monnaie
  • Le paradoxe des canaux privés
  • Pourquoi Core 30 représente pour moi un changement de sens
  • Une liberté qui exige de maintenir son propre code devient une liberté coûteuse
  • Ce qui a changé dans ma confiance
  • Conclusion

§Bitcoin, policy et souveraineté des ressources : ce qui a changé dans ma confiance

Pendant longtemps, ma confiance dans Bitcoin reposait sur une propriété qui allait bien au-delà de la rareté monétaire, de la preuve de travail ou de la conservation individuelle des clés.

Elle reposait sur une architecture dans laquelle chaque participant pouvait engager ses propres ressources selon ses propres critères.

Un nœud possède de la mémoire. Il consomme du calcul. Il utilise du stockage. Il ouvre des connexions. Il consomme de la bande passante. Il reçoit des transactions, choisit lesquelles conserver dans son mempool et participe éventuellement à leur propagation.

Ces ressources ont un coût.

Pour moi, leur allocation devait donc rester une décision de celui qui les possède.

C’est sur ce point précis que ma confiance s’est érodée.

Je ne parle pas ici de la quantité maximale de bitcoins, de la preuve de travail ou de la validité cryptographique des transactions. Mon interrogation porte sur une couche située avant le consensus : la transaction relay policy, c’est-à-dire les règles qu’un nœud applique aux transactions non confirmées qu’il accepte de stocker et de propager.

La documentation actuelle de Bitcoin Core donne une définition très claire de cette couche. La policy constitue un ensemble de règles supplémentaires au consensus, appliquées aux transactions non confirmées avant leur entrée dans le mempool. Bitcoin Core précise également que ces règles sont locales au nœud et configurables. Elles ne sont pas appliquées aux transactions déjà présentes dans les blocs.

Cette distinction est fondamentale.

Lorsqu’un bloc arrive, mon nœud vérifie les règles de consensus qu’il applique. Lorsqu’une transaction non confirmée arrive, il existe auparavant une autre question : est-ce que je souhaite consacrer mes ressources à cette transaction ?

Pour moi, cette seconde question possède une importance économique propre.

§Le mempool n’est pas seulement une prédiction du prochain bloc

Une conception aujourd’hui explicitement défendue par de nombreux contributeurs de Bitcoin Core consiste à considérer qu’un mempool doit représenter aussi fidèlement que possible les transactions susceptibles d’être minées.

Le texte publié par Bitcoin Core en juin 2025 est particulièrement explicite. Parmi les objectifs du relay, ses signataires placent la prédiction des transactions qui seront minées, l’estimation des frais, l’accélération de la propagation des blocs et la transmission des transactions rémunératrices aux mineurs. Ils expliquent ensuite qu’il est préférable, selon leur conception, que le logiciel d’un nœud possède une représentation réaliste de ce qui finira dans le prochain bloc.

Cette conception est cohérente techniquement.

Une mempool ressemblant à celle des mineurs améliore certaines estimations de frais. Elle facilite certaines stratégies de fee bumping. Elle rend plus probable la présence locale des transactions qui seront nécessaires à la reconstruction rapide d’un bloc compact.

BIP152 repose effectivement sur cette dernière propriété. Lorsqu’un nœud possède déjà localement les transactions annoncées par leurs identifiants courts, il peut reconstruire le bloc sans les télécharger intégralement. Lorsqu’elles manquent, un échange supplémentaire getblocktxn/blocktxn devient nécessaire.

Je reconnais donc pleinement la valeur technique d’un mempool représentatif.

Mon désaccord apparaît lorsque cette fonction de prédiction devient progressivement la définition dominante de ce que doit être le mempool d’un utilisateur.

Je considère également le mempool comme l’expression d’une allocation locale de ressources.

Ces deux propriétés peuvent coexister jusqu’à un certain point. Elles produisent cependant des arbitrages. Une policy plus restrictive peut rendre mon mempool moins représentatif de celui d’un mineur. Elle peut dégrader localement mon estimation des frais. Elle peut provoquer davantage de transactions manquantes lors de certaines reconstructions de blocs compacts.

Je peux accepter ces coûts.

Ils font partie de mon calcul.

J’estime que la décision d’accepter ou non cet arbitrage devrait appartenir à l’opérateur qui fournit les ressources.

§Une ressource rare implique un choix

Une machine qui relaie une transaction effectue un travail réel.

Elle consomme quelques octets ou kilo-octets de mémoire. Elle exécute des vérifications. Elle maintient des structures de données. Elle consomme de la bande passante en réception et en émission. Elle conserve éventuellement cette transaction pendant plusieurs heures. Elle contribue à la diffuser vers d’autres pairs.

Pris individuellement, le coût d’une transaction peut sembler négligeable.

À l’échelle d’un système ouvert, la question devient celle de l’allocation d’une ressource rare entre des usages concurrents.

Aucun observateur extérieur ne possède une fonction d’utilité universelle permettant de déterminer quelle transaction mérite mes ressources.

Le propriétaire de la machine dispose de l’information locale : capacité de sa connexion, coût de son infrastructure, objectifs de son nœud, menaces qu’il souhaite réduire, services qu’il fournit, usages qu’il souhaite favoriser, compromis qu’il accepte.

Cette connaissance est distribuée.

Le réseau peut alors émerger de la somme de millions d’arbitrages locaux.

C’est précisément ce que j’attendais d’une architecture monétaire réellement décentralisée : des règles communes minimales pour déterminer la validité monétaire, accompagnées d’une grande liberté laissée aux participants dans l’organisation des ressources nécessaires au fonctionnement du réseau.

§Ce que datacarriersize représentait

L’histoire de datacarriersize illustre bien cette conception.

Lorsque l’option a été introduite dans Bitcoin Core, le commit portait explicitement le titre « Enable customising node policy for datacarrier data size ». Le texte d’aide décrivait le paramètre comme la taille maximale des données dans les transactions data-carrier que le nœud accepte de relayer et de miner.

Le sens économique de cette option me paraît important.

L’opérateur disposait d’une quantité de ressources.

Le logiciel lui exposait directement un mécanisme lui permettant de déterminer une limite.

Avec Bitcoin Core 30, cette policy a changé. La valeur par défaut de datacarriersize est passée à 100000, ce que les release notes décrivent elles-mêmes comme un déplafonnement effectif, puisque d’autres limites de taille interviennent auparavant. La valeur 83 reste disponible et restaure la borne quantitative des versions précédentes. Core 30 autorise également plusieurs sorties data-carrier dans une même transaction standard et applique désormais cette limite à leur taille agrégée.

Le détail est important.

datacarriersize=83 existe toujours.

L’utilisateur peut donc retrouver une limite quantitative de 83 octets.

L’espace des transactions auquel cette valeur s’applique a cependant changé : plusieurs data carriers sont maintenant admis et leur consommation est agrégée.

Le même nombre ne représente donc plus exactement la même policy structurelle.

Core 30 a également abaissé les valeurs par défaut de minrelaytxfee et incrementalrelayfee à 0,1 sat/vB. Ces paramètres restent configurables.

Je ne vois aucun problème de principe à ce qu’un logiciel propose de nouveaux défauts.

Mon interrogation concerne la distinction entre modifier une valeur configurable et modifier l’espace des politiques que le logiciel permet simplement d’exprimer.

Une limite de taille est quantitative.

Un seuil de frais est quantitatif.

blocksonly=1 est presque un interrupteur global : le code actuel de Bitcoin Core indique que ce mode rejette les transactions reçues des pairs et désactive leur broadcast et rebroadcast automatiques, sous certaines exceptions.

Entre ces extrêmes existe un espace beaucoup plus vaste : filtrer certaines structures de transactions, certaines formes de data-carrier, certaines topologies, certaines catégories de scripts ou certains comportements, tout en continuant à participer normalement au relay du reste.

C’est cette granularité qui m’intéresse.

§La liberté dans le code source et la liberté dans le nœud ne produisent pas le même coût

Bitcoin Core rappelle à juste titre qu’aucun contributeur ne peut forcer les utilisateurs à installer une nouvelle version. Le projet n’effectue pas de mise à jour automatique et son propre texte de 2025 affirme que les utilisateurs disposent de la liberté ultime de choisir leur logiciel et d’implémenter les policies qu’ils désirent.

Je considère cette affirmation exacte.

Le code est disponible.

Il peut être modifié.

Une autre implémentation peut être utilisée.

Une version antérieure peut continuer à fonctionner tant que les conditions techniques nécessaires sont réunies.

Ma préoccupation se situe au niveau du coût économique d’exercice de cette liberté.

Une option présente dans bitcoin.conf coûte presque zéro à exercer.

Modifier quelques valeurs demande une compétence minimale.

Utiliser une autre implémentation représente déjà un coût supplémentaire : audit, confiance, maintenance, compatibilité, suivi des mises à jour.

Maintenir soi-même une divergence dans le code demande encore davantage de compétences, de temps et de tests.

La liberté théorique subsiste dans tous ces cas.

Son prix d’exercice change considérablement.

Pour cette raison, le périmètre de configuration offert directement par l’implémentation dominante possède une importance économique réelle.

Lorsqu’un choix passe d’une option utilisateur à une décision inscrite dans l’architecture interne du logiciel, le pouvoir n’est pas supprimé mathématiquement. Le coût nécessaire pour l’exercer est déplacé.

Cette distinction me paraît fondamentale.

§Core 30 n’est pas un événement isolé dans la conception du mempool

La version 31 poursuit une transformation importante de la logique du mempool avec l’introduction du cluster mempool.

Bitcoin Core 31 abandonne les anciennes limites d’ancêtres et de descendants au profit de limites portant sur des clusters. Les transactions à l’intérieur du mempool sont désormais ordonnées selon le feerate auquel elles sont estimées devoir être minées, et cette organisation sert à la construction des templates, à l’éviction des transactions et aux annonces de relay. Les limites de clusters restent configurables par des arguments spécifiques.

Il s’agit d’un travail d’ingénierie substantiel et cohérent avec l’objectif déclaré : construire un mempool capable de mieux représenter l’économie du mining et d’optimiser la sélection des transactions.

Je vois ici une orientation architecturale.

Le mempool tend à devenir un modèle local de l’espace économique anticipé par les mineurs.

Dans cette conception, une transaction qu’un mineur rationnel est disposé à inclure possède de fortes raisons d’être relayée par les nœuds, car son exclusion réduit la fidélité du modèle.

Mon point de départ est différent.

Le mineur possède ses ressources et choisit les transactions qu’il souhaite recevoir et inclure.

L’opérateur d’un nœud possède ses ressources et choisit les transactions qu’il souhaite recevoir et propager.

Ces deux acteurs peuvent poursuivre des fonctions d’utilité différentes.

Le réseau trouve ensuite un équilibre entre ces décisions.

Je considère cette hétérogénéité comme une propriété économique du système.

§« Elle sera minée quand même » ne rend pas la policy inutile

L’objection la plus fréquente consiste à observer qu’une transaction refusée par une grande partie des nœuds peut parvenir directement à un mineur.

C’est exact.

Un service de broadcast spécialisé, une connexion directe, un réseau de relay particulier ou tout autre mécanisme out-of-band peut transmettre une transaction aux producteurs de blocs.

Si elle respecte leurs critères et le consensus, elle peut être minée.

Cette possibilité ne supprime pas l’effet économique de la policy locale.

Elle change le chemin nécessaire pour atteindre le producteur du bloc.

Le coût de propagation ne disparaît pas. Il est supporté par un autre acteur.

Le service peut décider de le facturer.

Le mineur peut décider de le subventionner parce qu’il espère recevoir les frais de transaction.

Un tiers peut exploiter cette infrastructure pour d’autres raisons.

Dans chacun de ces cas, une ressource est consommée quelque part.

Plus important encore, la structure de dépendance change.

Une transaction largement relayée par le réseau P2P dispose de nombreux chemins vers de nombreux mineurs.

Une transaction dépendant d’un service spécialisé doit atteindre les mineurs auxquels ce service dispose effectivement d’un accès.

Si plusieurs services se concurrencent, cette dépendance peut être limitée.

Si quelques acteurs dominent cet accès, elle devient plus importante.

Il n’existe donc aucune nécessité d’affirmer qu’une transaction refusée par les nœuds coûtera systématiquement davantage à son émetteur.

Le mineur peut parfaitement absorber ce coût.

L’effet certain est plus précis : quelqu’un doit fournir le chemin que les nœuds ayant refusé la transaction ont choisi de ne pas fournir.

Cette observation rejoint d’ailleurs une préoccupation formulée directement par les contributeurs de Bitcoin Core. Leur déclaration sur le relay explique que celui-ci doit notamment aider les mineurs à découvrir les transactions rémunératrices afin qu’ils n’aient pas à dépendre de mécanismes de soumission out-of-band, mécanismes qu’ils décrivent comme susceptibles d’affaiblir la décentralisation du mining.

Nous partageons donc le constat sur l’importance de la topologie de propagation.

La divergence porte sur la conclusion.

Le texte de Core conclut qu’il vaut mieux relayer les transactions susceptibles d’être minées afin d’éviter la migration vers ces canaux privés.

J’en tire une autre conséquence : si une utilisation donnée ne trouve de chemin vers les mineurs qu’en construisant une infrastructure spécialisée, cette contrainte constitue elle-même une information économique.

Elle révèle que certains propriétaires de ressources P2P ne souhaitent pas subventionner cette utilisation.

Faire disparaître ce signal du réseau général pour maintenir l’uniformité des mempools me semble retirer une dimension du processus de découverte économique.

§Le marché des frais lui-même change lorsque le relay devient privé

Une mempool publique fournit de l’information.

Elle permet d’observer les transactions en attente, leurs feerates, leurs dépendances et une partie de la concurrence pour le blockspace.

Cette représentation a toujours été imparfaite : les mempools diffèrent, les nœuds ne reçoivent pas les transactions simultanément et les mineurs peuvent recevoir des transactions privées.

Lorsque la proportion de transactions privées augmente, la différence entre l’offre observable dans les mempools publics et l’offre réellement accessible aux mineurs augmente également.

À partir d’un certain niveau, l’estimation publique du marché des frais devient moins complète.

Les producteurs de blocs et les acteurs ayant accès au flux privé disposent alors d’une information que les autres participants ne possèdent pas.

Il s’agit ici d’une conséquence économique déduite de l’architecture, et non d’une règle du protocole.

Elle mérite néanmoins d’être prise au sérieux.

Un marché fonctionne d’autant mieux que l’information pertinente peut circuler entre de nombreux participants.

Un marché dans lequel une fraction croissante des ordres transite par des chemins privés produit mécaniquement davantage d’information privée.

Bitcoin Core cherche justement à limiter cette situation en rendant le mempool public plus proche de ce que les mineurs voient réellement.

Je partage l’objectif de maintenir un réseau P2P économiquement pertinent.

Je considère toutefois que cet objectif doit rester compatible avec la souveraineté d’allocation des ressources de ceux qui composent ce réseau.

§Un nœud ne se réduit pas à un observateur des mineurs

Un nœud me sert à vérifier les blocs.

Il me sert à vérifier les transactions qui me concernent.

Il me permet de suivre mes UTXO sans dépendre de la confiance accordée à un serveur distant.

Il me permet de diffuser mes propres transactions.

Il peut fournir une estimation locale du marché des frais.

Toutes ces fonctions sont essentielles.

J’en ajoute une autre : il me permet de participer au réseau selon mes propres conditions économiques.

Si sa fonction devient principalement de reproduire aussi fidèlement que possible les décisions anticipées des mineurs, l’utilisateur se retrouve progressivement en aval du processus de sélection.

Le mineur décide ce qu’il est disposé à acheter sous forme de transactions rémunératrices.

Le mempool tente de prédire ce choix.

L’opérateur optimise ensuite son comportement pour reproduire cette réalité.

Dans cette architecture, le nœud reste souverain pour valider le consensus.

Sa fonction économique dans la phase précédant le minage devient davantage adaptative.

C’est précisément ce déplacement qui modifie ma perception de Bitcoin.

Je pensais que les utilisateurs du réseau participaient aussi à l’émergence de ses priorités par les ressources qu’ils choisissaient individuellement d’allouer.

Une transaction largement acceptée trouvait naturellement de nombreux chemins de propagation.

Une transaction faiblement acceptée devait trouver d’autres chemins.

Les mineurs restaient libres de la recevoir autrement.

Chaque acteur supportait les conséquences économiques de son choix.

Cet agencement me paraît profondément sain.

§blocksonly ne répond pas à cette question

L’existence de blocksonly démontre que l’opérateur peut refuser presque entièrement de participer au relay des transactions.

Bitcoin Core indique que ce mode empêche la réception ordinaire des transactions provenant des pairs et désactive leur broadcast automatique, avec certaines exceptions.

Historiquement, Bitcoin Core a également désactivé l’estimation des frais lorsque blocksonly est actif, ce qui montre bien le compromis fonctionnel associé à cette configuration.

Cette possibilité est utile.

Elle ne répond toutefois pas au problème de granularité.

Un propriétaire de ressources peut raisonnablement vouloir relayer les transactions monétaires ordinaires, participer activement au réseau P2P et refuser certaines structures qu’il juge inutile de transporter.

Entre le relay presque universel défini par une policy amont et l’absence presque totale de relay existe un espace considérable de préférences locales.

C’est cet espace que je souhaite préserver.

§La bonne policy ne peut pas être connue centralement

Je ne prétends pas connaître la policy optimale pour tous les utilisateurs.

Cette prétention serait précisément contraire au principe que je défends.

Certains opérateurs souhaitent un mempool reproduisant au plus près celui des mineurs.

Leur choix possède une justification rationnelle.

Certains souhaitent maximiser la qualité de leur estimation de frais.

Certains souhaitent minimiser la consommation de bande passante.

Certains souhaitent appliquer des restrictions supplémentaires.

Certains souhaitent tout relayer dès lors que le coût économique de la transaction est suffisant.

Certains souhaitent ne relayer aucune transaction.

La valeur de ces choix dépend de circonstances locales que le développeur de l’implémentation ne connaît pas entièrement.

Le logiciel peut proposer d’excellents défauts.

Il peut protéger l’utilisateur contre des attaques de déni de service.

Il peut définir des limites nécessaires à la complexité algorithmique.

Il peut documenter les conséquences de chaque option.

Je considère cependant que l’architecture atteint une qualité supérieure lorsqu’elle expose autant que raisonnablement possible les arbitrages économiques à celui qui supporte leurs coûts.

La distinction est importante entre une règle rendue nécessaire par une propriété de sécurité objective et un choix exprimant une préférence sur l’utilisation des ressources.

§Pourquoi cela touche, pour moi, à la qualité de la monnaie

Une monnaie ne se résume pas à son unité de compte.

Sa qualité dépend également des institutions techniques qui permettent de la vérifier, de la transmettre et de la conserver.

Dans Bitcoin, ces institutions sont largement constituées de logiciel.

La distribution du pouvoir économique dépend donc en partie de l’endroit où le logiciel place les décisions.

Une décision placée dans le consensus s’impose à tous ceux qui veulent accepter la même chaîne.

Une décision placée dans une policy locale peut varier entre utilisateurs.

Une décision codée sans option dans l’implémentation dominante reste modifiable grâce au code source, mais son changement exige davantage de compétences et de coûts.

Ces trois niveaux n’ont pas la même structure économique.

C’est pourquoi je considère la configurabilité comme une propriété monétaire indirecte.

Elle détermine la capacité des utilisateurs ordinaires à transformer leur préférence en comportement réel sans demander à un développeur, à un pool ou à un service intermédiaire de l’implémenter pour eux.

Plus les choix locaux peuvent être exprimés directement, plus l’information et la décision restent distribuées.

Plus leur exercice exige une infrastructure spécialisée, plus apparaissent des intermédiaires capables de monétiser cette complexité.

§Le paradoxe des canaux privés

Les canaux out-of-band ont une fonction légitime.

Ils empêchent qu’une majorité de nœuds de relay puisse bloquer définitivement la communication entre un émetteur et un mineur consentant.

Cette propriété contribue à la résistance à la censure.

Leur existence est donc saine.

Leur généralisation comme mode normal de propagation produit une structure différente.

Si une part importante des transactions doit passer par quelques infrastructures capables de joindre efficacement les mineurs, la capacité d’accès à ces infrastructures acquiert une valeur économique.

Les utilisateurs ordinaires deviennent davantage dépendants de services spécialisés.

Les mineurs bénéficiant des meilleures connexions privées peuvent obtenir une information que les autres ne possèdent pas.

Les mempools publics deviennent une représentation plus partielle de la demande réelle de blockspace.

BIP152 rappelle également qu’une plus grande divergence entre les transactions connues localement et celles présentes dans les blocs implique davantage de transactions manquantes lors de leur reconstruction et peut nécessiter des échanges supplémentaires.

Il existe donc un compromis réel.

Une policy locale hétérogène possède un coût réseau.

Une infrastructure privée possède également un coût et crée ses propres dépendances.

Aucun de ces coûts ne suffit à déterminer universellement le bon choix pour tous les utilisateurs.

§Pourquoi Core 30 représente pour moi un changement de sens

Core 30 n’a pas supprimé la possibilité de régler datacarriersize.

La valeur historique de 83 reste disponible.

Core 30 n’a pas empêché l’utilisateur de modifier minrelaytxfee.

Core 31 conserve également de nombreux réglages et rend configurables ses nouvelles limites de clusters.

Le changement que je perçois est plus profond qu’une disparition d’option particulière.

Il concerne le sens attribué à la policy.

Historiquement, datacarriersize avait été introduit explicitement comme un moyen de personnaliser la policy du nœud.

La déclaration de 2025 donne aujourd’hui une doctrine beaucoup plus explicite : lorsque des transactions disposent d’une demande économique durable et finissent régulièrement dans les blocs, la policy de Core doit tendre à les relayer afin que le mempool reste proche de ce qui sera miné.

C’est une position intellectuellement cohérente.

Elle place le comportement attendu du mineur au centre de la définition pratique de la policy de relay.

Ma conception place davantage le propriétaire du nœud au centre de l’allocation des ressources de ce nœud.

À mes yeux, la différence porte sur l’architecture même de la décentralisation.

§Une liberté qui exige de maintenir son propre code devient une liberté coûteuse

Il restera toujours possible de répondre : « le code est libre, il suffit de le modifier ».

Techniquement, c’est vrai.

Économiquement, cette réponse ne me suffit plus.

Une liberté dont l’exercice exige de devenir mainteneur C++, de suivre en permanence les changements du mempool, de résoudre des conflits, de porter des patches et de maintenir une suite de tests n’est accessible qu’à une fraction infime des utilisateurs.

Le droit de modifier le code source reste indispensable.

L’exposition des choix au niveau de la configuration possède une autre fonction : elle permet à un utilisateur de transformer directement sa propriété matérielle en décision économique.

Cette facilité d’expression est une composante de la décentralisation effective.

Je ne souhaite pas que tous les utilisateurs adoptent ma policy.

Je souhaite qu’ils puissent adopter la leur.

§Ce qui a changé dans ma confiance

Je continue à reconnaître les propriétés exceptionnelles du consensus Bitcoin.

Je continue à reconnaître la valeur d’un actif dont les règles monétaires peuvent être vérifiées indépendamment.

Je continue à reconnaître l’importance de la preuve de travail, de la conservation individuelle des clés et de la validation locale.

Mon doute porte désormais sur une autre promesse que j’avais placée au même niveau : celle d’un réseau composé d’acteurs autonomes capables de participer selon leurs propres arbitrages.

Lorsque le rôle du nœud évolue vers la reproduction du mempool attendu des mineurs, une partie de cette autonomie économique devient secondaire par construction.

Lorsque la réponse à une préférence différente devient blocksonly, la modification du code ou l’utilisation d’une autre implémentation, le coût de l’expression de cette préférence augmente.

Lorsque le contournement normal des policies passe par des services spécialisés connectés aux mineurs, une nouvelle couche d’intermédiation apparaît.

Lorsque l’existence de ces contournements est utilisée pour conclure que les policies locales sont inutiles, on oublie ce qu’elles représentent : le droit d’un propriétaire à décider de l’usage de sa propre ressource.

Je ne demande pas à ma policy d’empêcher une transaction d’exister.

Je ne lui demande pas d’empêcher un mineur de la recevoir.

Je ne lui demande pas de rendre invalide un bloc conforme au consensus.

Je lui demande quelque chose de beaucoup plus simple : que mon nœud ne soit pas obligé, pour participer pleinement au réseau P2P, de consacrer ses ressources à des usages que je n’ai pas choisis.

Si un autre nœud souhaite les relayer, il peut le faire.

Si un mineur souhaite créer son propre canal, il peut le faire.

Si un service souhaite financer cette propagation, il peut le faire.

Le coût, l’information et la dépendance associés à ces décisions se distribuent alors entre les acteurs qui ont volontairement décidé de les assumer.

Cette distribution des choix me paraît constitutive d’un système réellement décentralisé.

§Conclusion

Ma perte de confiance ne vient donc pas d’une transaction particulière, d’un OP_RETURN, d’une valeur de datacarriersize ou d’un désaccord ponctuel avec des développeurs.

Elle vient d’un changement de principe.

J’avais compris Bitcoin comme un système dans lequel le consensus définissait le minimum commun nécessaire à la monnaie, tandis que les participants conservaient une grande latitude pour organiser volontairement leurs propres ressources autour de ce minimum.

Je considère aujourd’hui qu’une autre conception gagne du terrain : le nœud doit principalement observer, modéliser et relayer ce que les producteurs de blocs sont économiquement susceptibles d’accepter.

Cette conception possède de solides arguments techniques. Elle améliore la fidélité du mempool, certaines estimations de frais et certaines propriétés de propagation. Les documents de Bitcoin Core l’expliquent clairement.

Elle ne correspond plus à la raison profonde pour laquelle j’accordais à Bitcoin une valeur particulière.

Pour moi, une monnaie décentralisée doit préserver autant que possible la faculté de chacun de décider de l’allocation de ses propres ressources, sans que l’usage normal de son nœud soit défini par anticipation à partir des préférences des mineurs ou de l’implémentation dominante.

La rareté monétaire protège la quantité.

La validation indépendante protège les règles.

La conservation des clés protège la propriété.

La libre allocation des ressources protège l’autonomie économique de ceux qui font réellement fonctionner le réseau.

C’est cette dernière propriété que je considère désormais suffisamment affaiblie pour remettre en cause ma confiance dans Bitcoin tel que je l’avais compris.