Un plaidoyer pour des règles neutres, un consensus dur, des marchés ouverts et une innovation sans permission
De nombreux bitcoiners que je respecte soutiennent le BIP 110. Ils souhaitent maintenir la validation accessible, protéger les opérateurs de nœuds des coûts et contenus indésirables, préserver des paiements abordables et garder Bitcoin concentré sur la monnaie saine plutôt que sur le stockage de données à usage général. Ce sont des préoccupations sérieuses. Je partage les objectifs. Je ne suis pas d'accord sur le remède. (GitHub
Cet article critique la proposition, pas les personnes derrière elle. Je suppose la bonne foi. Bitcoin est le plus fort lorsque nous pouvons être en désaccord vigoureusement sans confondre alliés et ennemis.
Il ne s'agit pas non plus d'une défense de chaque inscription, jeton, fichier ou application. Certains peuvent être frivoles, nuisibles ou frauduleux. La question est plus étroite : une utilisation contestée de transactions valides et payant des frais devrait-elle être traitée en modifiant le consensus ?
Toutes les raisons ci-dessous n'ont pas le même poids, et plusieurs se renforcent mutuellement. Le cas est cumulatif.
Ce que propose le BIP 110
Cet article traite du BIP 110 version 1.0.0, le « Reduced Data Temporary Softfork », promu au statut « Complete » le 25 juin 2026. Selon le BIP 3, « Complete » signifie que les auteurs ont terminé leur travail prévu et recommandent l'adoption. Cela ne signifie pas que Bitcoin a adopté la proposition ou que la communauté a atteint un consensus. Le dépôt BIPs indique explicitement que la publication n'établit pas qu'une proposition est bonne, qu'elle a un consensus communautaire ou qu'elle est sur le point d'être adoptée. (GitHub
Pendant une période active d'environ un an, le BIP 110 ajouterait sept restrictions de consensus. Il limiterait les nouveaux scriptPubKeys à 34 octets, avec une exception de 83 octets pour OP_RETURN ; limiterait de nombreux payloads poussés et éléments de témoin d'argument de script à 256 octets ; interdirait de dépenser des versions de témoin et de Tapleaf non définies tout en permettant encore de créer de telles sorties ; interdirait l'annexe Taproot ; limiterait les blocs de contrôle Taproot à 257 octets ; rejetterait les Tapscripts contenant des opcodes OP_SUCCESSx ; et rejetterait les exécutions Tapscript de OP_IF ou OP_NOTIF. (GitHub
La proposition grandfathe les sorties de transactions non dépensées créées avant l'activation. C'est une sauvegarde importante. Je ne prétends pas que le BIP 110 confisque largement les bitcoins existants. Mon objection est plus étroite : il supprime de manière prospective des fonctionnalités de transaction actuellement valides, peut affecter des flux de travail pré-signés rares qui s'étendent sur l'activation, réduit l'optionalité technique et établit un précédent pour utiliser des restrictions de consensus afin de décourager une catégorie d'utilisation par ailleurs valide. (GitHub
Le BIP 110 propose également un déploiement BIP 9 modifié. Il utilise un seuil de signalement des mineurs de 55 %, contre 95 % spécifié dans le BIP 9 ; élimine le délai d'attente conventionnel et l'état FAILED ; ajoute une période de signalement obligatoire ; garantit le verrouillage sur la chaîne d'application au plus tard à une hauteur spécifiée ; et ajoute un nouvel état EXPIRED après 52 416 blocs actifs. (GitHub
Comme tout soft fork, le BIP 110 n'est pas imposé par une autorité centrale. Les utilisateurs choisissent quel logiciel et quelles règles appliquer. Le risque survient lorsque des participants économiquement significatifs appliquent des règles matériellement différentes, créant une pression, une incertitude ou une scission de chaîne.
Les auteurs fournissent une implémentation de référence, des vecteurs de test, une justification détaillée et une discussion franche des compromis. Ce sont des forces substantielles du document. La proposition soutient que l'urgence et la durée temporaire justifient le seuil plus bas et les restrictions intentionnellement simples et brutes. Je respecte la préoccupation et le travail. Je ne suis pas d'accord avec le calcul du risque. (GitHub
I. Neutralité et principes fondamentaux
1. Le consensus est l'intervention la plus puissante de Bitcoin. Un soft fork rend certains blocs valides sous les règles précédentes invalides pour les nœuds mis à jour. Ce pouvoir devrait être réservé à des défaillances claires, graves et largement comprises.
2. Ce n'est pas une réparation pour une défaillance de consensus établie. Le BIP 110 ne corrige pas l'inflation, la validation de signature, la double dépense ou un bogue critique connu. Il traite d'une externalité et d'un cas d'usage contestés, donc la charge de la preuve devrait être particulièrement élevée.
3. Il élève un jugement contesté en loi de protocole. La proposition déplace un différend sur l'utilisation légitime et les externalités de la politique de relais, de la politique minière et des marchés vers la validité du consensus.
4. Bitcoin ne peut pas lire l'intention. Le réseau ne peut pas savoir si les octets représentent une image, une preuve, un contrat, des métadonnées, un enregistrement d'authentification ou une future application.
5. Les proxys structurels créent un risque collatéral. Parce que l'intention ne peut pas être connue, la proposition restreint des formes techniques qui peuvent servir à la fois des fins défavorisées et légitimes.
6. Un message social n'est pas une raison suffisante pour un changement de consensus. La spécification traite expressément l'activation comme un moyen de communiquer que le stockage de données n'est pas le bienvenu. Le consensus devrait être modifié pour des raisons techniques ou monétaires impérieuses, pas principalement pour exprimer une désapprobation. (GitHub
7. La désapprobation n'est pas l'invalidité. Une transaction peut être triviale, spéculative, offensante ou gaspilleuse et toujours suivre les règles et payer les frais requis pour l'inclusion.
8. Il réduit la liberté économique prospective sur la chaîne BIP 110. Les UTXOs pré-activation sont grandfathered, mais les utilisateurs créant des UTXOs pendant la période active auraient moins de façons valides de les structurer et de les dépenser qu'avec le consensus existant.
9. Les systèmes sans permission doivent tolérer l'expérimentation non approuvée. Exiger des innovateurs qu'ils prouvent leur utilisation digne avant de construire inverse le sens de l'innovation sans permission.
10. Il met le conservatisme du protocole à l'envers. Le conservatisme à la couche de base devrait signifier une réticence à modifier le consensus, pas une empressement à modifier le consensus en faveur d'une philosophie d'utilisation conservatrice.
II. La charge de la preuve n'a pas été satisfaite
11. Le « spam » n'est pas une primitive de consensus. Il n'y a pas d'opcode qui puisse distinguer le spam de l'utilité. Ces étiquettes proviennent du jugement humain.
12. « Monétaire » et « non monétaire » ne sont pas proprement séparables. Un canal de paiement, une preuve de réserves, une politique de garde, un contrat intelligent ou un engagement de règlement est à la fois une activité financière et des données.
13. Les cas d'usage connus ne sont pas l'ensemble de l'espace de conception. L'innovation est définie par ce qui n'est pas encore connu.
14. Le BIP lui-même ne quantifie pas la charge des nœuds qu'il supprimerait. Il décrit les coûts mais n'estime pas la bande passante, le stockage, la charge de validation, les seuils matériels ou le nombre d'opérateurs de nœuds susceptibles d'être gagnés ou perdus.
15. Il ne quantifie pas le bénéfice de décentralisation. L'affirmation que le BIP 110 améliorerait la décentralisation n'est pas accompagnée d'un modèle mesurable ou d'un objectif.
16. Il ne quantifie pas le soulagement des paiements. Il n'estime pas de combien les frais de transaction baisseraient, pour combien de temps, ou combien d'utilisateurs de paiement en bénéficieraient.
17. Il combine des coûts distincts en un seul diagnostic. La croissance de l'état UTXO, la bande passante de synchronisation initiale, le stockage d'archives, la charge de relais et le temps de validation ont des causes différentes et peuvent nécessiter des remèdes différents.
18. L'urgence est affirmée plutôt que définie opérationnellement. La proposition qualifie la situation d'urgente et de crise, mais ne fournit aucun seuil objectif auquel l'intervention de consensus devient nécessaire.
19. Une limite historique de politique de relais n'est pas la preuve d'une limite optimale de consensus. Une valeur par défaut de 83 octets peut être une politique utile sans devenir une règle de validité de bloc intemporelle.
20. La ligne des 256 octets est heuristique. La justification la relie en partie à la taille d'image compressée et aux grands entiers cryptographiques, mais n'établit pas 256 octets comme une frontière optimale entre sécurité et innovation. (GitHub
III. La portée technique est trop large
21. Sept changements de consensus distincts sont regroupés. Les participants ne peuvent pas soutenir une restriction et en rejeter une autre. Ils doivent accepter ou rejeter le package.
22. La préoccupation technique la plus forte est regroupée avec des restrictions sans rapport. Les grands scriptPubKeys peuvent augmenter les coûts d'état UTXO et de validation. Si cela crée un danger mesurable, cela mérite une proposition de portée étroite par elle-même, pas un soutien automatique à six restrictions supplémentaires. (GitHub
23. La politique OP_RETURN à 83 octets devient un consensus. Cela convertit une préférence de relais et de minage configurable en une règle de validité de bloc.
24. Les limites de 256 octets contraignent les primitives générales. Elles ciblent le stockage de données en restreignant de larges classes de payloads poussés et d'éléments de témoin d'argument de script.
25. Dépenser des versions de témoin et Tapleaf non définies serait désactivé. Ces espaces sont inutilisés aujourd'hui en partie parce qu'ils sont réservés pour des mises à niveau futures.
26. L'annexe Taproot serait désactivée. Le BIP 341 réserve l'annexe pour des extensions futures. Même si les utilisateurs ne devraient pas l'employer avant que sa signification soit définie, fermer un chemin de mise à niveau délibéré devrait nécessiter une justification exceptionnelle. (GitHub
27. La profondeur du Taptree serait réduite. Une limite de bloc de contrôle de 257 octets restreint les chemins de script révélés à sept niveaux et peut contraindre les arbres de script complexes.
28. OP_SUCCESSx serait désactivé même dans les branches non exécutées. Le BIP 342 a créé ces opcodes comme hooks de mise à niveau propres pour les futurs soft forks. (GitHub
29. OP_IF et OP_NOTIF exécutés seraient interdits dans Tapscript. Les auteurs les considèrent comme redondants et souvent abusés, mais reconnaissent également des utilisations expérimentales et des efficacités possibles de Miniscript.
30. La proposition accepte ouvertement la brusquerie en échange de la vitesse. Sa justification dit qu'une approche mieux équilibrée nécessiterait plus de développement et de révision, donc elle choisit des restrictions plus simples destinées à un déploiement plus rapide. L'urgence ne remplace pas la précision dans le code de consensus. (GitHub
IV. Il sacrifie la compatibilité et l'optionalité future
31. Il ferme plusieurs chemins de mise à niveau à la fois. Les annexes, les futures versions de témoin, les futures versions de Tapleaf et OP_SUCCESSx font tous partie de l'espace de conception réservé de Bitcoin. (GitHub
32. Réservé ne signifie pas inutile. Cela signifie que les concepteurs précédents ont délibérément préservé la valeur d'option pour des besoins qui n'avaient pas encore émergé.
33. Une fermeture d'un an peut toujours perturber les calendriers de développement. Les auteurs s'attendent à ce que les futurs soft forks nécessitent plus d'un an de coordination, mais c'est une estimation, pas une garantie.
34. Cela peut compliquer les conceptions de type BitVM. La spécification reconnaît que la limite du bloc de contrôle pourrait entraver les contrats hors chaîne avancés.
35. Cela peut affecter les Tapleaves générés par Miniscript. La proposition reconnaît que certaines sorties de compilateur peuvent contenir OP_IF et nécessiteraient un ajustement.
36. Cela nécessite des changements dans les outils de portefeuille affectés. La section de rétrocompatibilité indique que le compilateur Miniscript aurait besoin d'être modifié pendant que les règles sont actives.
37. Cela crée un risque d'accès aux fonds étroit mais admis. Le BIP identifie franchement de rares scénarios Taproot pré-signés dans lesquels des UTXOs post-activation pourraient être gelés ou dépensés de manière inattendue.
38. Le grandfathering est précieux mais n'est pas une isolation complète. Les UTXOs pré-activation sont protégés, mais les flux de travail qui créent ou dépensent des sorties affectées pendant le déploiement peuvent toujours rencontrer de nouvelles contraintes.
39. Il est conseillé aux utilisateurs de migrer les fonds potentiellement affectés. Une proposition qui nécessite même une classe étroite d'utilisateurs de migrer n'est pas un filtre sans coût.
40. « Aucun cas d'usage connu » n'est pas une preuve de sécurité. Les systèmes privés, les contrats non publiés, les portefeuilles expérimentaux et les protocoles futurs ne sont pas entièrement observables. (GitHub
V. Les règles de consensus temporaires créent toujours une complexité réelle
41. Le code de consensus temporaire est toujours du code de consensus. Il doit être spécifié, implémenté, révisé, testé, déployé, surveillé et plus tard retiré.
42. Le grandfathering rend la validité dépendante de l'historique. La même construction de dépense peut être traitée différemment selon le moment où l'UTXO a été créé.
43. Les règles dépendantes de l'historique augmentent la complexité d'implémentation. Chaque implémentation doit identifier la hauteur de création de l'UTXO pertinente et appliquer les exemptions de manière identique.
44. L'activation crée une frontière critique. Les logiciels et les acteurs économiques doivent se mettre d'accord sur le moment où les nouvelles restrictions commencent.
45. L'expiration en crée une autre. Ils doivent également se mettre d'accord sur le moment où les restrictions prennent fin et où le comportement précédemment restreint redevient valide.
46. Le BIP 110 ajoute un nouvel état EXPIRED. Cela étend la machine à états de déploiement familière avec un nouveau comportement de consensus.
47. Il supprime le résultat FAILED conventionnel. Le déploiement proposé ne peut pas simplement expirer de la manière ordinaire du BIP 9.
48. Il crée plusieurs fenêtres de coordination. Le signalement volontaire, le signalement obligatoire, le verrouillage, l'activation et l'expiration introduisent chacun des opportunités de divergence. (GitHub
49. Les règles temporaires peuvent laisser des artefacts permanents. Le code du portefeuille, les procédures opérationnelles, les contrats et les contrôles de risque institutionnels peuvent nécessiter des changements qui survivent au déploiement.
50. Plus de branches de consensus signifie plus de surface de bugs. Les vecteurs de test réduisent le risque connu, mais ne peuvent pas énumérer chaque interaction privée ou future.
VI. Les effets économiques et de sécurité sont incertains
51. L'externalité des nœuds est réelle mais hétérogène. Chaque nœud de validation complète doit télécharger et vérifier les blocs, tandis que les nœuds élagués peuvent jeter les anciennes données brutes de blocs et limiter le stockage historique. Les coûts pertinents devraient être mesurés séparément. (Bitcoin Core
52. Le problème du bénéficiaire des frais n'est pas unique aux transactions de données. Les mineurs collectent les frais tandis que les validateurs supportent certains coûts pour chaque transaction. L'ampleur peut différer, mais la structure de base est universelle.
53. Les coûts techniques devraient être mesurés directement. Pour une quantité donnée de données et de travail de validation, les coûts de ressources proviennent des octets, de l'état, du calcul et de la bande passante, pas du fait que les observateurs approuvent ou non le but de la transaction.
54. Le BIP 110 ne peut pas éliminer l'incorporation de données. La spécification reconnaît que les utilisateurs peuvent diviser les données en morceaux plus petits ou les déguiser dans des structures autorisées. (GitHub
55. L'évasion peut rendre les transactions moins efficaces. Les encodages fragmentés ou obscurcis peuvent consommer plus de structure et compliquer l'analyse sans éliminer la demande sous-jacente.
56. L'effet sur les frais est ambigu. Supprimer une utilisation peut réduire les frais de paiement, réduire les revenus de frais globaux, déplacer la demande vers d'autres encodages, ou produire une combinaison des trois.
57. Les revenus des mineurs comptent davantage à mesure que la subvention diminue. Les frais de transaction sont une composante de la récompense de bloc, tandis que la subvention de bloc est réduite de moitié tous les 210 000 blocs. (Documentation développeur Bitcoin
58. Une demande de frais globale plus faible peut affaiblir la sécurité à la marge. Dans la mesure où le BIP 110 réduit la demande totale de frais plutôt que de simplement la réallouer, des revenus de mineurs plus faibles peuvent réduire l'incitation à engager de la puissance de hachage, toutes choses égales par ailleurs.
59. Une demande diversifiée peut rendre le marché des frais plus résilient. Les paiements, les canaux, les systèmes de garde, les applications financières et d'autres utilisations n'ont pas besoin d'atteindre leur pic en même temps.
60. La spécification ne modélise pas le compromis de sécurité. Elle plaide pour des paiements moins chers et des coûts de nœuds plus faibles sans estimer les effets possibles sur les revenus des mineurs, l'investissement en hachage ou la profondeur du marché des frais à long terme.
VII. De meilleurs outils de marché et de politique existent
61. Bitcoin a déjà une contrainte de capacité neutre en contenu. Le poids du bloc impose une limite commune à la capacité de transaction de chaque bloc. (GitHub
62. Les frais rationnent déjà l'espace de bloc rare. Les utilisateurs expriment l'urgence en enchérissant, et les mineurs sélectionnent les transactions valides selon leurs propres politiques.
63. La limite de bloc et le marché des frais ne demandent pas aux utilisateurs de déclarer leur but. Ils appliquent des limites techniques de validité et de ressources plutôt qu'un test sémantique de savoir si une transaction est suffisamment monétaire.
64. La politique de relais reste un outil moins coercitif. Les implémentations et les opérateurs de nœuds peuvent choisir quelles transactions non confirmées relayer sans redéfinir les blocs valides. La politique de porte-données de Bitcoin Core est configurable. (GitHub
65. La politique minière reste volontaire. Les mineurs peuvent exclure des classes de transactions de leurs propres modèles de blocs sans forcer chaque nœud de validation à rejeter les blocs les contenant.
66. La politique est imparfaite, mais l'imperfection n'est pas un échec. La soumission directe aux mineurs peut contourner les filtres de relais. Cette limitation mérite une analyse, pas un bond automatique vers l'interdiction par consensus.
67. Aucune transaction n'a un droit à l'inclusion. Un mineur peut rejeter une transaction selon sa propre politique, mais rendre une transaction précédemment valide invalide à travers un fork est un acte bien plus conséquent.
68. La tarification des ressources peut être améliorée sans classer le but. Si certaines structures imposent des coûts disproportionnés, Bitcoin peut étudier des limites neutres en contenu ou une tarification liée à l'utilisation mesurable des ressources.
69. L'élagage et les conceptions de données optionnelles méritent une recherche continue. Ils peuvent ne pas résoudre tous les problèmes, mais ils traitent les charges de stockage plus directement qu'une règle destinée en partie à signaler qu'une utilisation n'est pas la bienvenue.
70. Le BIP lui-même concède que la politique est généralement le bon endroit pour lutter contre le spam. Son incapacité à garantir un filtrage parfait ne prouve pas par elle-même que le consensus doit être utilisé. (GitHub
VIII. Il décourage l'innovation et l'adoption
71. Il crée un effet dissuasif. Les développeurs peuvent éviter Bitcoin si des constructions actuellement valides peuvent être suspendues via le consensus pour supprimer une utilisation connexe.
72. Il privilégie les cas d'usage existants. « Tous les cas d'usage monétaires connus » protège le présent, pas le futur.
73. Il détruit la valeur d'option avant que la valeur puisse être découverte. La meilleure utilisation future d'un hook de mise à niveau peut ne pas encore avoir de nom.
74. Des fondations stables comptent pour les contrats à longue durée de vie. Les portefeuilles, les systèmes de garde, les canaux de paiement et les protocoles financiers ont besoin de confiance que les structures de transaction valides resteront disponibles.
75. Il réduit l'espace de conception des scripts. Cela peut rendre certaines constructions plus grandes, plus chères, moins élégantes ou temporairement impossibles.
76. Il peut retarder la recherche avancée sur les contrats. Le BIP accepte explicitement que les travaux de type BitVM puissent devoir attendre ou se poursuivre sur des testnets et des sidechains. (GitHub
77. Il pousse l'expérimentation loin de Bitcoin par consensus. Les testnets et les sidechains sont utiles, mais les constructeurs ne devraient pas être déplacés de la couche de base sans un cas de sécurité impérieux.
78. Les futurs systèmes de couche 2 peuvent dépendre des hooks inutilisés d'aujourd'hui. L'optionalité de la couche de base peut soutenir l'échelle sans nécessiter une activité fréquente de la couche de base.
79. Les applications peuvent renforcer la monnaie. De meilleurs portefeuilles, garde, règlement, crédit, titres et systèmes de preuve peuvent augmenter l'utilité, la liquidité et la demande de Bitcoin.
80. Bitcoin n'a pas besoin de choisir entre la monnaie et la technologie. Sa force monétaire peut être renforcée par un réseau ouvert qui soutient des portefeuilles sécurisés, des contrats, la garde, le règlement et l'innovation.
IX. Le mécanisme d'activation est trop agressif
81. Le seuil de 55 % est un écart majeur par rapport au BIP 9. Le BIP 9 spécifie un seuil de préparation des mineurs de 95 % ; le BIP 110 propose 55 %.
82. Une restriction controversée devrait exiger une plus grande confiance, pas moins. La durée temporaire ne rend pas les dommages de coordination inoffensifs.
83. Le signalement des mineurs n'est pas un référendum sur tous les utilisateurs de Bitcoin. La puissance de hachage sécurise et ordonne les transactions, mais les détenteurs, les échanges, les portefeuilles, les commerçants, les dépositaires et les entreprises déterminent quelles règles et quel actif ils acceptent économiquement.
84. Le signalement obligatoire change le sens de la non-participation. Pendant la fenêtre spécifiée, les nœuds d'application rejetteraient les blocs qui ne signalent pas le bit 4.
85. Le déploiement est conçu pour se verrouiller au plus tard à une hauteur prédéterminée sur la chaîne d'application. C'est plus fort que de simplement observer une préparation volontaire.
86. L'absence d'un état FAILED supprime une sortie propre. Une proposition qui ne peut pas attirer un soutien volontaire suffisant devrait pouvoir expirer sans coordination forcée. (GitHub
87. La machinerie d'activation ne peut pas fabriquer le consensus. Elle peut coordonner les états logiciels, mais elle ne peut pas créer un accord social et économique.
88. Une application divergente peut diviser le réseau. Si des participants économiquement significatifs appliquent des règles de validité incompatibles, le résultat peut être une scission de chaîne ou une incertitude prolongée.
89. Une scission temporaire ne serait pas triviale. La liquidité, la garde, le règlement, la comptabilité et la confiance des utilisateurs pourraient tous être affectés.
90. Le consensus dur est le système immunitaire de Bitcoin. Abaisser la barre pour une restriction de cas d'usage contesté peut créer un risque plus sérieux que le problème de stockage de données ciblé.
X. Le précédent est plus dangereux que la cible
91. Les règles expirent, mais le précédent, non. Les futures campagnes peuvent citer le BIP 110 comme preuve que le consensus peut être utilisé pour supprimer une activité valide défavorisée.
92. La même logique peut être réutilisée. Une faction peut qualifier une autre utilisation de non monétaire, nuisible, juridiquement risquée ou non soutenue et chercher son exclusion.
93. « Utilisation non soutenue » est une catégorie extensible. Bitcoin n'a pas de gestionnaire de produit central qui peut définir en permanence son champ d'application approuvé.
94. Les limites basées sur le but deviennent des limites politiques. Une fois que la validité repose sur des jugements sur l'utilisation légitime, les débats de protocole deviennent des concours de valeurs et de pouvoir.
95. La cible d'aujourd'hui ne limite pas la cible de demain. Les outils de confidentialité, la nouvelle garde, le règlement de stablecoins, les systèmes de jetons, les applications d'entreprise ou d'autres utilisations impopulaires pourraient faire face à des arguments similaires. Ce n'est pas une prédiction. C'est un risque de gouvernance.
96. Chaque restriction est présentée comme exceptionnelle. Les précédents sont créés précisément par des cas que leurs défenseurs considèrent uniques.
97. La cohésion sociale est un actif rare. Encoder un différend culturel dans le consensus peut consommer la confiance et la capacité de coordination nécessaires pour des menaces plus sérieuses.
98. Chaque partie prenante mérite d'être entendue. Les développeurs, les opérateurs de nœuds, les mineurs, les détenteurs, les portefeuilles, les échanges, les dépositaires, les entreprises et les institutions portent tous des risques et des responsabilités différents.
99. Le capital à risque mérite d'être pris en compte sans conférer de contrôle. Les grands détenteurs, mineurs, plateformes d'échange, dépositaires et entreprises ne possèdent pas le consensus. Ni les développeurs ou les opérateurs de nœuds agissant seuls. Un accord durable nécessite une coordination entre tous.
100. La participation des entreprises est légitime lorsqu'elle renforce Bitcoin. Les entreprises permettent aux gens de s'organiser dans le cadre juridique avec échelle, responsabilité, capital et continuité. Elles ne méritent pas une autorité spéciale, mais ne doivent pas être traitées comme des étrangères à un réseau monétaire mondial.
XI. Une meilleure voie est possible
101. Les participants peuvent s'opposer au stockage de données sans modifier le consensus. Ils peuvent refuser d'utiliser, promouvoir, indexer, relayer ou miner ces données.
102. Des choix logiciels plus stricts peuvent rester volontaires. Des implémentations concurrentes et des politiques configurables sont des caractéristiques d'un réseau ouvert, non des défauts.
103. Nous pouvons améliorer la mesure avant d'intervenir. Publier des données reproductibles sur la bande passante, le stockage, le temps de validation, la croissance des UTXO, le déplacement des frais et l'économie des nœuds.
104. Nous pouvons cibler des coûts de ressources mesurables. Une règle étroite liée à un risque démontré de déni de service ou de validation est plus défendable qu'un ensemble large lié en partie à un objectif perçu.
105. Nous pouvons améliorer le placement des données. De meilleurs engagements, un stockage optionnel, l'élagage et les architectures de couche 2 peuvent réduire les charges tout en préservant la fonctionnalité.
106. Nous pouvons améliorer la transparence du marché des frais. De meilleurs outils et modèles peuvent montrer qui paie, qui supporte les coûts et quelles utilisations évincenent réellement les paiements.
107. Nous pouvons préserver les points d'ancrage de mise à niveau pendant que la recherche se poursuit. Une capacité inutilisée n'est pas nécessairement du gaspillage lorsqu'elle protège les futures voies de soft-fork.
108. Nous pouvons attendre un alignement écrasant. Le coût de l'attente doit être mesuré par rapport au coût d'un fork inutile. En l'absence de preuves convaincantes d'urgence et d'un large accord, la retenue est le défaut le plus sûr.
109. Nous pouvons être en désaccord sans transformer les alliés en ennemis. Les partisans du BIP 110 essaient de protéger Bitcoin. La réponse respectueuse est de répondre à leurs préoccupations tout en rejetant un remède qui crée des risques plus grands.
110. Le remède proposé est plus dangereux que la maladie. Le BIP 110 utiliserait le consensus pour restreindre l'activité valide, limiter les options futures, compliquer le déploiement et établir un précédent qu'il ne pourra pas effacer ultérieurement. Cela en fait une proposition iatrogène pour Bitcoin.
Gardiens de la neutralité
La force de Bitcoin n'est pas que tout le monde s'accorde sur chaque usage. Sa force est que le désaccord est contenu par des règles neutres et un consensus dur.
Les frais tarifent l'espace des blocs. Les nœuds choisissent la politique et valident le consensus. Les mineurs construisent des blocs. Les détenteurs allouent du capital. Les développeurs proposent du code. Les entreprises construisent des infrastructures et des applications. Les changements de protocole ne devraient prévaloir que lorsque la validation, la sécurité, l'utilité et le capital atteignent un alignement écrasant.
Ce n'est pas une défense de chaque inscription, jeton, fichier ou application. C'est une défense des règles neutres qui permettent à Bitcoin de rester ouvert tandis que les marchés récompensent ce qui est utile et abandonnent ce qui ne l'est pas.
Bitcoin devrait rester conservateur au niveau de la couche de base. Pour moi, cela signifie rejeter le BIP 110.
Bitcoin n'a pas besoin de gardiens de la pureté.
Il a besoin de gardiens de la neutralité.
Sources primaires
Cette analyse est basée principalement sur le BIP 110 version 1.0.0 ; les définitions de processus et de statut du BIP 3 ; la conception d'activation du BIP 9 ; les BIP 141, 341 et 342 ; la documentation de la politique de transport de données de Bitcoin Core ; la documentation d'élagage de Bitcoin Core ; et la référence de la récompense de bloc des développeurs Bitcoin. (GitHub
