Ein Plädoyer für neutrale Regeln, harten Konsens, offene Märkte und erlaubnisfreie Innovation
Viele Bitcoin-Enthusiasten, die ich respektiere, unterstützen BIP 110. Sie wollen die Validierung zugänglich halten, Node-Betreiber vor unerwünschten Kosten und Inhalten schützen, bezahlbare Zahlungen erhalten und Bitcoin auf Sound Money statt auf universelle Datenspeicherung fokussieren. Das sind ernstzunehmende Anliegen. Ich teile die Ziele. Ich bin anderer Meinung, was das Mittel angeht. (GitHub
Dieser Artikel kritisiert den Vorschlag, nicht die Menschen dahinter. Ich unterstelle gute Absichten. Bitcoin ist am stärksten, wenn wir leidenschaftlich uneins sein können, ohne Verbündete mit Feinden zu verwechseln.
Es ist auch keine Verteidigung jeder Inschrift, jedes Tokens, jeder Datei oder jeder Anwendung. Manche mögen frivol, schädlich oder betrügerisch sein. Die Frage ist enger gefasst: Sollte eine umstrittene Nutzung derzeit gültiger, gebührenzahlender Transaktionen durch eine Änderung des Konsenses adressiert werden?
Nicht alle unten genannten Gründe haben das gleiche Gewicht, und mehrere verstärken sich gegenseitig. Das Argument ist kumulativ.
Was BIP 110 vorschlägt
Dieser Artikel befasst sich mit BIP 110 Version 1.0.0, dem „Reduced Data Temporary Softfork", der am 25. Juni 2026 auf den Status „Complete" (Abgeschlossen) gesetzt wurde. Gemäß BIP 3 bedeutet „Complete", dass die Autoren ihre geplante Arbeit abgeschlossen haben und die Übernahme empfehlen. Es bedeutet nicht, dass Bitcoin den Vorschlag übernommen hat oder dass die Community einen Konsens erzielt hat. Das BIPs-Repository stellt ausdrücklich klar, dass die Veröffentlichung nicht bedeutet, dass ein Vorschlag gut ist, Community-Konsens hat oder kurz vor der Übernahme steht. (GitHub
Während eines etwa einjährigen aktiven Zeitraums würde BIP 110 sieben Konsensbeschränkungen einführen. Es würde neue scriptPubKeys auf 34 Bytes begrenzen, mit einer Ausnahme von 83 Bytes für OP_RETURN; viele gepushte Nutzlasten und Skript-Argument-Zeugen-Elemente auf 256 Bytes begrenzen; das Ausgeben undefinierter Witness- und Tapleaf-Versionen verbieten, während die Erstellung solcher Outputs weiterhin erlaubt wäre; den Taproot-Anhang verbieten; Taproot-Kontrollblöcke auf 257 Bytes begrenzen; Tapscripts ablehnen, die OP_SUCCESSx-Opcodes enthalten; und die Ausführung von OP_IF oder OP_NOTIF in Tapscript ablehnen. (GitHub
Der Vorschlag bestandsschützt („grandfathers") nicht ausgegebeneTransaktionsoutputs, die vor der Aktivierung erstellt wurden. Das ist eine wichtige Schutzmaßnahme. Ich behaupte nicht, dass BIP 110 breitflächig existierende Bitcoins enteignet. Mein Einwand ist enger gefasst: Es entfernt prospektiv derzeit gültige Transaktionsfunktionalität, kann seltene vorab signierte Workflows betreffen, die sich über die Aktivierung erstrecken, reduziert die technische Optionalität und schafft einen Präzedenzfall dafür, Konsensbeschränkungen zu nutzen, um eine ansonsten gültige Nutzungskategorie zu unterbinden. (GitHub
BIP 110 schlägt auch ein modifiziertes BIP-9-Deployment vor. Es verwendet eine Signalschwelle von 55 Prozent der Miner, verglichen mit der in BIP 9 festgelegten Schwelle von 95 Prozent; eliminiert das herkömmliche Timeout und den FAILED-Status; fügt einen Pflichtsignalzeitraum hinzu; garantiert ein Lock-in auf der durchsetzenden Kette spätestens zu einer bestimmten Höhe; und fügt nach 52.416 aktiven Blöcken einen neuen EXPIRED-Status hinzu. (GitHub
Wie jeder Softfork wird BIP 110 nicht von einer zentralen Autorität verhängt. Benutzer wählen, welche Software und Regeln sie durchsetzen. Das Risiko entsteht, wenn wirtschaftlich bedeutende Teilnehmer materiell unterschiedliche Regeln durchsetzen, was Druck, Unsicherheit oder eine Kettenaufspaltung erzeugt.
Die Autoren liefern eine Referenzimplementierung, Testvektoren, eine detaillierte Begründung und eine offene Diskussion von Zielkonflikten. Das sind substanzielle Stärken des Dokuments. Der Vorschlag argumentiert, dass Dringlichkeit und temporäre Dauer die niedrigere Schwelle und die bewusst einfachen, pauschalen Beschränkungen rechtfertigen. Ich respektiere die Besorgnis und die Arbeit. Ich bin anderer Meinung, was die Risikobewertung angeht. (GitHub
I. Neutralität und Grundprinzipien
1. Konsens ist Bitcoins mächtigste Intervention. Ein Softfork macht einige Blöcke, die unter vorherigen Regeln gültig waren, für aktualisierte Nodes ungültig. Diese Macht sollte klaren, ernsthaften und allgemein verstandenen Fehlern vorbehalten sein.
2. Es ist keine Reparatur für einen etablierten Konsensfehler. BIP 110 korrigiert keine Inflation, Signaturvalidierung, Double-Spending oder einen bekannten kritischen Bug. Es adressiert ein umstrittenes externes Problem und einen Anwendungsfall, daher sollte die Beweislast besonders hoch sein.
3. Es erhebt ein umstrittenes Urteil zum Protokollgesetz. Der Vorschlag verlagert einen Streit über legitime Nutzung und Externalitäten von der Relay-Policy, Mining-Policy und den Märkten in die Konsensgültigkeit.
4. Bitcoin kann keine Absicht lesen. Das Netzwerk kann nicht wissen, ob Bytes ein Bild, einen Beweis, einen Vertrag, Metadaten, einen Authentifizierungsdatensatz oder eine zukünftige Anwendung darstellen.
5. Strukturelle Stellvertreter (Proxies) schaffen Kollateralrisiken. Da die Absicht nicht bekannt sein kann, schränkt der Vorschlag technische Formen ein, die sowohl unerwünschten als auch legitimen Zwecken dienen können.
6. Eine soziale Botschaft ist kein ausreichender Grund für eine Konsensänderung. Die Spezifikation behandelt die Aktivierung ausdrücklich als eine Möglichkeit zu kommunizieren, dass Datenspeicherung unerwünscht ist. Der Konsens sollte aus zwingenden technischen oder monetären Gründen geändert werden, nicht in erster Linie, um Missbilligung auszudrücken. (GitHub
7. Missbilligung ist nicht Ungültigkeit. Eine Transaktion kann trivial, spekulativ, anstößig oder verschwenderisch sein und dennoch den Regeln folgen und die für die Aufnahme erforderliche Gebühr zahlen.
8. Es schränkt die prospektive wirtschaftliche Freiheit auf der BIP-110-Kette ein. UTXOs vor der Aktivierung sind bestandsgeschützt, aber Benutzer, die während des aktiven Zeitraums UTXOs erstellen, hätten weniger gültige Möglichkeiten, diese zu strukturieren und auszugeben, als unter dem bestehenden Konsens.
9. Erlaubnisfreie Systeme müssen ungeprüfte Experimente tolerieren. Zu verlangen, dass Innovatoren ihren Nutzen beweisen, bevor sie bauen, kehrt die Bedeutung von erlaubnisfreier Innovation um.
10. Es stellt den Protokollkonservatismus auf den Kopf. Konservatismus auf der Basisschicht sollte bedeuten, den Konsens nur widerwillig zu ändern, nicht eifrig den Konsens zugunsten einer konservativen Nutzungsphilosophie zu ändern.
II. Die Beweislast wurde nicht erbracht
11. „Spam" ist kein Konsens-Primitiv. Es gibt keinen Opcode, der Spam von Nutzen unterscheiden kann. Diese Bezeichnungen entstehen aus menschlichem Urteilsvermögen.
12. „Monetär" und „nicht-monetär" sind nicht sauber trennbar. Ein Zahlungskanal, ein Reserveguthabenbeleg, eine Verwahrungspolitik, ein Smart Contract oder eine Abwicklungsverpflichtung sind sowohl finanzielle Aktivität als auch Daten.
13. Bekannte Anwendungsfälle sind nicht der gesamte Gestaltungsraum. Der Vorschlag sagt, er bewahre alle bekannten monetären Anwendungsfälle. Innovation wird dadurch definiert, was noch nicht bekannt ist.
14. Das BIP selbst quantifiziert nicht die Node-Belastung, die es beseitigen würde. Es beschreibt Kosten, schätzt aber nicht die relevante Bandbreite, Speicher, Validierungslast, Hardwareschwellen oder die Anzahl der Node-Betreiber, die wahrscheinlich gewonnen oder verloren gehen.
15. Es quantifiziert nicht den Dezentralisierungsnutzen. Die Behauptung, BIP 110 würde die Dezentralisierung verbessern, ist nicht mit einem messbaren Modell oder Ziel verbunden.
16. Es quantifiziert nicht die Zahlungserleichterung. Es schätzt nicht, wie stark die Transaktionsgebühren fallen würden, für wie lange oder wie viele Zahlungsnutzer profitieren würden.
17. Es kombiniert unterschiedliche Kosten zu einer Diagnose. UTXO-State-Wachstum, Initial-Sync-Bandbreite, Archivspeicher, Relay-Belastung und Validierungszeit haben unterschiedliche Ursachen und erfordern möglicherweise unterschiedliche Abhilfemaßnahmen.
18. Dringlichkeit wird behauptet, nicht operativ definiert. Der Vorschlag nennt die Situation dringend und eine Krise, liefert aber keine objektive Schwelle, ab der ein Konsenseingriff notwendig wird.
19. Ein historisches Relay-Policy-Limit ist kein Beweis für eine optimale Konsensgrenze. Ein Standardwert von 83 Bytes mag eine nützliche Policy sein, ohne eine zeitlose Blockgültigkeitsregel zu werden.
20. Die 256-Byte-Grenze ist heuristisch. Die Begründung bezieht sie teilweise auf komprimierte Bildgrößen und große kryptografische Integer, legt aber 256 Bytes nicht als optimale Grenze zwischen Sicherheit und Innovation fest. (GitHub
III. Der technische Umfang ist zu breit
21. Sieben separate Konsensänderungen werden gebündelt. Teilnehmer können nicht eine Einschränkung unterstützen und eine andere ablehnen. Sie müssen das Paket annehmen oder ablehnen.
22. Das stärkste technische Bedenken wird mit nicht zusammenhängenden Einschränkungen gebündelt. Große scriptPubKeys können UTXO-State- und Validierungskosten erhöhen. Wenn das eine messbare Gefahr darstellt, verdient es einen eng gefassten eigenen Vorschlag, nicht automatische Unterstützung für sechs zusätzliche Einschränkungen. (GitHub
23. Die 83-Byte-OP_RETURN-Policy wird zum Konsens. Das wandelt eine konfigurierbare Relay- und Mining-Präferenz in eine Blockgültigkeitsregel um.
24. Die 256-Byte-Grenzen schränken allgemeine Primitive ein. Sie zielen auf Datenspeicherung ab, indem sie breite Klassen von gepushten Nutzlasten und Skript-Argument-Zeugen-Elementen einschränken.
25. Das Ausgeben undefinierter Witness- und Tapleaf-Versionen würde deaktiviert. Diese Räume sind heute teilweise ungenutzt, weil sie für zukünftige Upgrades reserviert sind.
26. Der Taproot-Anhang (Annex) würde deaktiviert. BIP 341 reserviert den Annex für zukünftige Erweiterungen. Selbst wenn Benutzer ihn nicht verwenden sollten, bevor seine Bedeutung definiert ist, sollte das Schließen eines bewussten Upgrade-Pfades eine außergewöhnliche Rechtfertigung erfordern. (GitHub
27. Die Taptree-Tiefe würde reduziert. Eine Obergrenze von 257 Bytes für Kontrollblöcke begrenzt offengelegte Skriptpfade auf sieben Ebenen und kann komplexe Skriptbäume einschränken.
28. OP_SUCCESSx würde selbst in nicht ausgeführten Zweigen deaktiviert. BIP 342 hat diese Opcodes als saubere Upgrade-Hooks für zukünftige Softforks geschaffen. (GitHub
29. Ausgeführte OP_IF- und OP_NOTIF-Befehle wären in Tapscript verboten. Die Autoren betrachten sie als redundant und häufig missbraucht, räumen aber auch experimentelle Nutzungen und mögliche Miniscript-Effizienzen ein.
30. Der Vorschlag akzeptiert offen Pauschalität im Austausch für Geschwindigkeit. Seine Begründung sagt, dass ein ausgewogenerer Ansatz mehr Entwicklung und Überprüfung erfordern würde, also wählt er einfachere Einschränkungen, die für eine schnellere Bereitstellung gedacht sind. Dringlichkeit ist kein Ersatz für Präzision in Konsenscode. (GitHub
IV. Es opfert Kompatibilität und zukünftige Optionalität
31. Es schließt mehrere Upgrade-Pfade auf einmal. Annexes, zukünftige Witness-Versionen, zukünftige Tapleaf-Versionen und OP_SUCCESSx sind alle Teil des reservierten Gestaltungsraums von Bitcoin. (GitHub
32. Reserviert bedeutet nicht nutzlos. Es bedeutet, dass frühere Designer bewusst Optionswert für Bedürfnisse bewahrt haben, die noch nicht entstanden waren.
33. Eine einjährige Schließung kann dennoch Entwicklungszeitpläne stören. Die Autoren erwarten, dass zukünftige Softforks mehr als ein Jahr Koordination erfordern, aber das ist eine Schätzung, keine Garantie.
34. Es könnte BitVM-artige Designs erschweren. Die Spezifikation erkennt an, dass die Kontrollblockgrenze fortschrittliches Off-Chain-Contracting behindern könnte.
35. Es könnte Miniscript-generierte Tapleaves beeinträchtigen. Der Vorschlag räumt ein, dass einige Compiler-Ausgaben OP_IF enthalten können und angepasst werden müssten.
36. Es erfordert Änderungen in betroffenen Wallet-Tools. Der Abschnitt zur Rückwärtskompatibilität stellt fest, dass der Miniscript-Compiler modifiziert werden müsste, solange die Regeln aktiv sind.
37. Es schafft ein enges, aber eingeräumtes Risiko des Zugriffsverlusts auf Gelder. Das BIP identifiziert offen seltene vorab signierte Taproot-Szenarien, in denen UTXOs nach der Aktivierung eingefroren oder unerwartet ausgegeben werden könnten.
38. Bestandsschutz (Grandfathering) ist wertvoll, aber keine vollständige Isolierung. UTXOs vor der Aktivierung sind geschützt, dennoch können Workflows, die während des Deployments betroffene Outputs erstellen oder ausgeben, auf neue Einschränkungen stoßen.
39. Benutzern wird geraten, potenziell betroffene Gelder zu migrieren. Ein Vorschlag, der selbst von einer engen Benutzergruppe eine Migration verlangt, ist kein kostenloser Filter.
40. „Kein bekannter Anwendungsfall" ist kein Sicherheitsbeweis. Private Systeme, unveröffentlichte Verträge, experimentelle Wallets und zukünftige Protokolle sind nicht vollständig beobachtbar. (GitHub
V. Temporäre Konsensregeln schaffen dennoch echte Komplexität
41. Temporärer Konsenscode ist immer noch Konsenscode. Er muss spezifiziert, implementiert, überprüft, getestet, bereitgestellt, überwacht und später zurückgezogen werden.
42. Bestandsschutz macht die Gültigkeit von der Historie abhängig. Dieselbe Ausgabekonstruktion kann je nach Erstellungszeitpunkt des UTXO unterschiedlich behandelt werden.
43. Historieabhängige Regeln erhöhen die Implementierungskomplexität. Jede Implementierung muss die relevante UTXO-Erstellungshöhe identifizieren und die Ausnahmen identisch anwenden.
44. Die Aktivierung schafft eine kritische Grenze. Software und wirtschaftliche Akteure müssen sich darüber einig sein, wann die neuen Beschränkungen beginnen.
45. Der Ablauf (Expiration) schafft eine weitere. Sie müssen sich auch darüber einig sein, wann die Beschränkungen enden und zuvor eingeschränktes Verhalten wieder gültig wird.
46. BIP 110 fügt einen neuen EXPIRED-Status hinzu. Das erweitert die bekannte Deployment-Statusmaschine um ein neues Konsensverhalten.
47. Es entfernt das herkömmliche FAILED-Ergebnis. Das vorgeschlagene Deployment kann nicht einfach in der üblichen BIP-9-Weise auslaufen.
48. Es schafft mehrere Koordinationsfenster. Freiwillige Signalisierung, Pflichtsignalisierung, Lock-in, Aktivierung und Ablauf bieten jeweils Gelegenheiten für Abweichungen. (GitHub
49. Temporäre Regeln können dauerhafte Artefakte hinterlassen. Wallet-Code, Betriebsabläufe, Verträge und institutionelle Risikokontrollen benötigen möglicherweise Änderungen, die das Deployment überdauern.
50. Mehr Konsenszweige bedeuten mehr Fehlerfläche. Testvektoren reduzieren bekannte Risiken, können aber nicht jede private oder zukünftige Interaktion aufzählen.
VI. Die wirtschaftlichen und sicherheitstechnischen Auswirkungen sind ungewiss
51. Die Node-Externalität ist real, aber heterogen. Jeder vollvalidierende Node muss Blöcke herunterladen und verifizieren, während bereinigte Nodes (pruned nodes) alte Rohblockdaten verwerfen und die historische Speicherung begrenzen können. Die relevanten Kosten sollten getrennt gemessen werden. (Bitcoin Core
52. Das Problem der Gebührenempfänger ist nicht einzigartig für Datentransaktionen. Miner kassieren Gebühren, während Validatoren für jede Transaktion einige Kosten tragen. Das Ausmaß mag unterschiedlich sein, aber die grundlegende Struktur ist universell.
53. Technische Kosten sollten direkt gemessen werden. Für eine gegebene Datenmenge und Validierungsarbeit entstehen Ressourcenkosten durch Bytes, Zustand, Berechnung und Bandbreite, nicht dadurch, ob Beobachter den Zweck der Transaktion gutheißen.
54. BIP 110 kann Dateneinbettung nicht eliminieren. Die Spezifikation erkennt an, dass Benutzer Daten in kleinere Stücke aufteilen oder innerhalb erlaubter Strukturen tarnen können. (GitHub
55. Umgehung könnte Transaktionen ineffizienter machen. Fragmentierte oder verschleierte Kodierungen können mehr Struktur verbrauchen und die Analyse erschweren, ohne die zugrunde liegende Nachfrage zu beseitigen.
56. Der Gebühreneffekt ist mehrdeutig. Die Unterdrückung einer Nutzung kann Zahlungsgebühren senken, die gesamten Gebühreneinnahmen verringern, die Nachfrage in andere Kodierungen verschieben oder eine Kombination dieser drei Effekte bewirken.
57. Die Miner-Einnahmen werden wichtiger, je mehr die Subvention sinkt. Transaktionsgebühren sind ein Bestandteil der Blockbelohnung, während sich die Blocksubvention alle 210.000 Blöcke halbiert. (Bitcoin Developer Docs
58. Eine geringere aggregierte Gebührennachfrage kann die Sicherheit am Rande schwächen. Wenn BIP 110 die gesamte Gebührennachfrage reduziert, anstatt sie lediglich umzuverteilen, können geringere Miner-Einnahmen den Anreiz verringern, Rechenleistung (Hash Power) bereitzustellen, ceteris paribus.
59. Unterschiedliche Nachfrage kann den Gebührenmarkt widerstandsfähiger machen. Zahlungen, Kanäle, Verwahrungssysteme, Finanzanwendungen und andere Nutzungen müssen nicht gleichzeitig ihren Höhepunkt erreichen.
60. Die Spezifikation modelliert den Sicherheits-Zielkonflikt nicht. Sie argumentiert für billigere Zahlungen und niedrigere Node-Kosten, ohne die möglichen Auswirkungen auf Miner-Einnahmen, Hash-Investitionen oder die langfristige Tiefe des Gebührenmarktes abzuschätzen.
VII. Es gibt bessere Markt- und Politikinstrumente
61. Bitcoin hat bereits eine inhaltsneutrale Kapazitätsbeschränkung. Das Blockgewicht begrenzt die Transaktionskapazität jedes Blocks einheitlich. (GitHub
62. Gebühren rationieren bereits den knappen Blockraum. Benutzer signalisieren Dringlichkeit durch Gebote, und Miner wählen unter ihren eigenen Richtlinien gültige Transaktionen aus.
63. Die Blockbegrenzung und der Gebührenmarkt verlangen nicht, dass Benutzer ihren Zweck offenlegen. Sie wenden technische Gültigkeits- und Ressourcengrenzen an, anstatt einen semantischen Test darauf, ob eine Transaktion ausreichend monetär ist.
64. Die Relay-Policy bleibt ein weniger erzwängendes Werkzeug. Implementierungen und Node-Betreiber können wählen, welche unbestätigten Transaktionen sie weiterleiten, ohne gültige Blöcke neu zu definieren. Die Datenübertragungsrichtlinie von Bitcoin Core ist konfigurierbar. (GitHub
65. Die Mining-Policy bleibt freiwillig. Miner können Transaktionsklassen von ihren eigenen Blockvorlagen ausschließen, ohne dass jeder validierende Node Blöcke mit diesen ablehnen muss.
66. Policy ist unvollkommen, aber Unvollkommenheit ist kein Scheitern. Die direkte Einreichung bei Minern kann Relay-Filter umgehen. Diese Einschränkung verdient eine Analyse, keinen automatischen Sprung zum Konsensverbot.
67. Keine Transaktion hat ein Recht auf Aufnahme. Ein Miner kann eine Transaktion gemäß seiner eigenen Policy ablehnen, aber eine zuvor gültige Transaktion über einen Fork hinweg ungültig zu machen, ist eine viel folgenreichere Handlung.
68. Die Ressourcenbepreisung kann verbessert werden, ohne den Zweck zu klassifizieren. Wenn bestimmte Strukturen unverhältnismäßige Kosten verursachen, kann Bitcoin inhaltsneutrale Grenzen oder eine an den messbaren Ressourcenverbrauch gekoppelte Bepreisung untersuchen.
69. Bereinigung (Pruning) und optionale Daten-Designs verdienen weitere Forschung. Sie mögen nicht jedes Problem lösen, aber sie adressieren Speicherbelastungen direkter als eine Regel, die teilweise dazu gedacht ist, zu signalisieren, dass eine Nutzung unerwünscht ist.
70. Das BIP selbst räumt ein, dass Policy im Allgemeinen der richtige Ort ist, um Spam zu bekämpfen. Seine Unfähigkeit, eine perfekte Filterung zu garantieren, beweist nicht von selbst, dass der Konsens verwendet werden muss. (GitHub
VIII. Es hemmt Innovation und Adoption
71. Es erzeugt einen abschreckenden Effekt. Entwickler könnten Bitcoin meiden, wenn derzeit gültige Konstruktionen durch Konsens ausgesetzt werden können, um eine verwandte Nutzung zu unterdrücken.
72. Es privilegiert etablierte Anwendungsfälle. „Alle bekannten monetären Anwendungsfälle" schützt die Gegenwart, nicht die Zukunft.
73. Es zerstört Optionswert, bevor Wert entdeckt werden kann. Der beste zukünftige Nutzen eines Upgrade-Hooks hat möglicherweise noch keinen Namen.
74. Stabile Grundlagen sind wichtig für langlebige Verträge. Wallets, Verwahrungssysteme, Zahlungskanäle und Finanzprotokolle benötigen das Vertrauen, dass gültige Transaktionsstrukturen verfügbar bleiben.
75. Es verengt den Skript-Designraum. Das kann einige Konstruktionen größer, teurer, weniger elegant oder vorübergehend unmöglich machen.
76. Es kann die Forschung zu fortschrittlichen Verträgen verzögern. Das BIP akzeptiert ausdrücklich, dass BitVM-artige Arbeiten möglicherweise warten oder auf Testnets und Sidechains stattfinden müssen. (GitHub
77. Es drängt Experimente durch Konsens von Bitcoin weg. Testnets und Sidechains sind nützlich, aber Entwickler sollten nicht ohne zwingende Sicherheitsgründe von der Basisschicht verdrängt werden.
78. Zukünftige Layer-2-Systeme könnten von heutigen ungenutzten Hooks abhängen. Die Optionalität der Basisschicht kann Skalierung unterstützen, ohne häufige Aktivität auf der Basisschicht zu erfordern.
79. Anwendungen können Geld stärken. Bessere Wallets, Verwahrung, Abwicklung, Kredit, Wertpapiere und Prüfsysteme können den Nutzen, die Liquidität und die Nachfrage nach Bitcoin erhöhen.
80. Bitcoin muss sich nicht zwischen Geld und Technologie entscheiden. Seine monetäre Stärke kann durch ein offenes Netzwerk gestärkt werden, das sichere Wallets, Verträge, Verwahrung, Abwicklung und Innovation unterstützt.
IX. Der Aktivierungsmechanismus ist zu aggressiv
81. Die Schwelle von 55 Prozent ist eine große Abweichung von BIP 9. BIP 9 spezifiziert eine Schwelle von 95 Prozent für die Bereitschaft der Miner; BIP 110 schlägt 55 Prozent vor.
82. Eine umstrittene Einschränkung sollte größeres Vertrauen erfordern, nicht weniger. Die temporäre Dauer macht Koordinationsfehler nicht harmlos.
83. Die Miner-Signalisierung ist kein Referendum über alle Bitcoin-Nutzer. Rechenleistung (Hash Power) sichert und ordnet Transaktionen, aber Inhaber, Börsen, Wallets, Händler, Verwahrer und Unternehmen bestimmen, welche Regeln und welches Asset sie wirtschaftlich akzeptieren.
84. Die Pflichtsignalisierung ändert die Bedeutung der Nichtteilnahme. Während des festgelegten Zeitraums würden durchsetzende Nodes Blöcke ablehnen, die nicht Bit 4 signalisieren.
85. Das Deployment ist so ausgelegt, dass es spätestens in einer vorher festgelegten Höhe auf der durchsetzenden Kette einlockt. Das ist stärker, als lediglich die freiwillige Bereitschaft zu beobachten.
86. Das Fehlen eines FAILED-Status entfernt einen sauberen Ausstiegsweg. Ein Vorschlag, der nicht genügend freiwillige Unterstützung anziehen kann, sollte ohne erzwungene Koordination auslaufen können. (GitHub
87. Aktivierungsmechanismen können keinen Konsens herstellen. Sie können Softwarezustände koordinieren, aber keine soziale und wirtschaftliche Einigung herbeiführen.
88. Abweichende Durchsetzung kann das Netzwerk spalten. Wenn wirtschaftlich bedeutende Teilnehmer inkompatible Gültigkeitsregeln anwenden, kann das Ergebnis eine Kettenaufspaltung oder anhaltende Unsicherheit sein.
89. Eine vorübergehende Spaltung wäre nicht trivial. Liquidität, Verwahrung, Abwicklung, Buchhaltung und das Vertrauen der Benutzer könnten alle beeinträchtigt werden.
90. Harter Konsens ist Bitcoins Immunsystem. Die Senkung der Messlatte für eine umstrittene Anwendungsfallbeschränkung könnte ein ernsteres Risiko darstellen als das gezielte Datenspeicherungsproblem.
X. Der Präzedenzfall ist gefährlicher als das Ziel
91. Die Regeln laufen ab, aber der Präzedenzfall nicht. Zukünftige Kampagnen können sich auf BIP 110 als Beleg dafür berufen, dass der Konsens genutzt werden kann, um unerwünschte gültige Aktivitäten zu unterdrücken.
92. Dieselbe Logik kann wiederverwendet werden. Eine Fraktion kann eine andere Nutzung als nicht-monetär, schädlich, rechtlich riskant oder nicht unterstützt bezeichnen und deren Ausschluss fordern.
93. „Nicht unterstützte Nutzung" ist eine erweiterbare Kategorie. Bitcoin hat keinen zentralen Produktmanager, der seinen genehmigten Umfang dauerhaft definieren kann.
94. Zweckbezogene Grenzen werden zu politischen Grenzen. Sobald Gültigkeit von Urteilen über legitime Nutzung abhängt, werden Protokolldebatten zu Wettbewerben um Werte und Macht.
95. Das heutige Ziel begrenzt nicht das morgige Ziel. Datenschutztools, neuartige Verwahrung, Stablecoin-Abwicklung, Token-Systeme, Unternehmensanwendungen oder andere unpopuläre Nutzungen könnten mit ähnlichen Argumenten konfrontiert werden. Dies ist keine Vorhersage. Es ist ein Governance-Risiko.
96. Jede Einschränkung wird als Ausnahme dargestellt. Präzedenzfälle werden genau durch Fälle geschaffen, die ihre Befürworter für einzigartig halten.
97. Sozialer Zusammenhalt ist eine knappe Ressource. Die Kodierung eines kulturellen Streits in den Konsens kann Vertrauen und Koordinationskapazität verbrauchen, die für ernsthaftere Bedrohungen benötigt werden.
98. Jeder Stakeholder verdient ein Gehör. Entwickler, Node-Betreiber, Miner, Inhaber, Wallets, Börsen, Verwahrer, Unternehmen und Institutionen tragen alle unterschiedliche Risiken und Verantwortungen.
99. Kapital, das Risiken ausgesetzt ist, verdient Beachtung, ohne Kontrolle zu verleihen. Große Inhaber, Miner, Börsen, Verwahrer und Unternehmen besitzen keinen Konsens. Auch Entwickler oder Node-Betreiber, die allein handeln, tun dies nicht. Dauerhafte Einigung erfordert Koordination zwischen allen Beteiligten.
100. Unternehmensbeteiligung ist legitim, wenn sie Bitcoin stärkt. Unternehmen ermöglichen es Menschen, sich im Rahmen des Rechts mit Größe, Verantwortlichkeit, Kapital und Kontinuität zu organisieren. Sie verdienen keine besondere Autorität, sollten aber auch nicht als Außenseiter eines globalen Geldnetzwerks behandelt werden.
XI. Ein besserer Weg ist möglich
101. Teilnehmer können der Datenspeicherung widersprechen, ohne den Konsens zu ändern. Sie können deren Nutzung, Förderung, Indizierung, Weiterleitung oder das Mining ablehnen.
102. Strengere Softwareentscheidungen können freiwillig bleiben. Konkurrierende Implementierungen und konfigurierbare Richtlinien sind Merkmale eines offenen Netzwerks, keine Mängel.
103. Wir können die Messung verbessern, bevor wir eingreifen. Veröffentlichen Sie reproduzierbare Daten zu Bandbreite, Speicher, Validierungszeit, UTXO-Wachstum, Gebührenverdrängung und Node-Ökonomie.
104. Wir können messbare Ressourcenkosten ins Visier nehmen. Eine enge Regel, die an ein nachgewiesenes Denial-of-Service- oder Validierungsrisiko geknüpft ist, ist besser zu verteidigen als ein breites Paket, das teilweise an einen vermeintlichen Zweck gebunden ist.
105. Wir können die Datenplatzierung verbessern. Bessere Verpflichtungen, optionaler Speicher, Pruning und Layer-2-Architekturen können die Belastung reduzieren, während die Funktionalität erhalten bleibt.
106. Wir können die Transparenz des Gebührenmarktes verbessern. Bessere Werkzeuge und Modelle können zeigen, wer zahlt, wer die Kosten trägt und welche Nutzungen tatsächlich Zahlungen verdrängen.
107. Wir können Upgrade-Möglichkeiten bewahren, während die Forschung weitergeht. Ungenutzte Kapazität ist nicht unbedingt Verschwendung, wenn sie zukünftige Soft-Fork-Pfade schützt.
108. Wir können auf überwältigende Einigkeit warten. Die Kosten des Wartens sollten gegen die Kosten eines unnötigen Forks abgewogen werden. Ohne zwingende Beweise für einen Notfall und breite Übereinstimmung ist Zurückhaltung der sicherere Standard.
109. Wir können anderer Meinung sein, ohne Verbündete zu Feinden zu machen. BIP-110-Befürworter versuchen, Bitcoin zu schützen. Die respektvolle Antwort ist, auf ihre Bedenken einzugehen, während man ein Mittel ablehnt, das größere Risiken schafft.
110. Das vorgeschlagene Heilmittel ist gefährlicher als die Krankheit. BIP 110 würde den Konsens nutzen, um gültige Aktivitäten einzuschränken, zukünftige Optionen zu beschneiden, die Bereitstellung zu erschweren und einen Präzedenzfall zu schaffen, der später nicht mehr rückgängig gemacht werden kann. Das macht es zu einem Bitcoin-Iatrogenese-Vorschlag.
Hüter der Neutralität
Bitcoins Stärke ist nicht, dass alle jeder Nutzung zustimmen. Seine Stärke ist, dass Uneinigkeit durch neutrale Regeln und harten Konsens eingedämmt wird.
Gebühren bepreisen Blockraum. Nodes wählen die Richtlinie und validieren den Konsens. Miner bauen Blöcke. Inhaber allokieren Kapital. Entwickler schlagen Code vor. Unternehmen bauen Infrastruktur und Anwendungen. Protokolländerungen sollten nur dann obsiegen, wenn Validierung, Sicherheit, Nutzen und Kapital eine überwältigende Übereinstimmung erreichen.
Dies ist keine Verteidigung jeder Inschrift, jedes Tokens, jeder Datei oder Anwendung. Es ist eine Verteidigung der neutralen Regeln, die es Bitcoin ermöglichen, offen zu bleiben, während der Markt belohnt, was nützlich ist, und aufgibt, was nicht nützlich ist.
Bitcoin sollte auf der Basisschicht konservativ bleiben. Für mich bedeutet das, BIP 110 abzulehnen.
Bitcoin braucht keine Hüter der Reinheit.
Es braucht Hüter der Neutralität.
Primärquellen
Diese Analyse basiert hauptsächlich auf BIP 110 Version 1.0.0; den Prozess- und Statusdefinitionen von BIP 3; dem Aktivierungsdesign von BIP 9; den BIPs 141, 341 und 342; der Datenübermittlungs-Richtliniendokumentation von Bitcoin Core; der Pruning-Dokumentation von Bitcoin Core und der Bitcoin-Entwickler-Referenz zur Blockbelohnung. (GitHub
