TL;DR
Luke Dashjr reichte Bitcoin CVE-2023-50428 am 09.12.2023 gegen Bitcoin Core bis Version 26.0 ein. Der NVD-Eintrag bewertet die Lücke mit 5.3 MEDIUM und markiert sie als Disputed. Er beschreibt, wie eine OP_FALSE OP_IF Hülle in Taproot Script-Path Witness-Daten das -datacarriersize-Policy-Limit umgeht. Bitcoin Core nannte das eine Policy-Frage, keinen Konsens-Bruch, und lieferte nie einen Fix. Bitcoin Core 30.0 vom 10.10.2025 hob das Standard--datacarriersize-Limit von 83 Bytes auf 100 000 Bytes an, über PR #32359, ein Faktor 1 200 und das Gegenteil dessen, was die CVE forderte. Bitcoin Knots patchte den Filter in 25.1.knots20231115 und wuchs von etwa 69 Nodes im Januar 2024 auf rund 4 240 von 23 842 erreichbaren Nodes bis September 2025. Gelder waren nie gefährdet. Konsens wurde nie gebrochen.
Der CVE den Luke Dashjr gegen Bitcoin Core einreichte
Ich arbeite im Krypto-Selbstverwahrungs-Bereich und sehe seit Anfang 2023 zu, wie die Inscriptions-Debatte ganze Räume voller Bitcoin-Entwickler spaltet. Luke Dashjr reichte CVE-2023-50428 am 09.12.2023 gegen Bitcoin Core bis Version 26.0 ein. Sein Argument war simpel. Inscriptions betten beliebige Payload in Witness-Daten ein, mit einem Skript-Muster, das der bestehende -datacarriersize Policy-Filter ignoriert. Als Knots-Maintainer nannte Dashjr das eine Schwachstelle. Die Core-Maintainer nannten es eine Policy-Wahl.
Der NVD-Eintrag trägt CVSS v3.1 Base Score 5.3 MEDIUM mit Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L. Dieser Vektor zählt. Confidentiality Impact: keiner. Integrity Impact: keiner. Nur Availability zeigt Low Impact. Keine Gelder gefährdet. Keine Schlüssel gefährdet. Keine ungültigen Blöcke. Nur Node-Relay-Kapazität.
Die NVD-Statuszeile lautet Disputed. Die Bitcoin Core Maintainer prüften den Filter-Patch auf bitcoin/bitcoin Issue #29187 und lehnten den Merge ab. Bitcoin Knots lieferte im selben Monat einen eigenen Filter in Version 25.1.knots20231115.
Was der Mechanismus tatsächlich macht
Bitcoin-Transaktionen tragen kleine Mengen beliebiger Daten. Der klassische Pfad ist OP_RETURN. Die Node-Policy -datacarriersize deckelte OP_RETURN-Payloads standardmässig auf 83 Bytes (80 Payload plus 3 Opcode-Overhead). Diese Obergrenze war immer ein Policy-Filter, keine Konsens-Regel.
Die CVE beschreibt einen anderen Pfad. In einem Taproot Script-Path Spend kann das Witness beliebiges Skript enthalten. Eine Inscription verpackt ihre Payload in eine OP_FALSE OP_IF <Daten> OP_ENDIF Hülle. Das OP_FALSE garantiert, dass der bedingte Zweig nie ausgeführt wird. Die Payload wird als inerte Pushdata behandelt statt als ausführbarer Code. Der -datacarriersize Filter prüfte diesen Pfad nie. Beliebige Payload-Grössen passierten ungefiltert.
Das ist ein Policy-Bypass, kein Konsens-Bruch. Jede Inscription-Transaktion ist nach Konsens-Regeln eine valide Bitcoin-Transaktion. Miner schliessen sie ein. Full Nodes akzeptieren sie. Umgangen wird nur ein Relay-Filter, und auch nur auf Nodes, die ihn durchsetzten.
Warum Bitcoin Core es Policy nannte und nicht Konsens
Die Core-Position stützte sich auf zwei technische Beobachtungen und eine Governance-Beobachtung.
Die technischen Beobachtungen waren simpel. Die zitierten Transaktionen sind konsens-valid. Node-Operatoren können heute schon eigene Relay-Policies konfigurieren. Den Referenz-Client zu zwingen, valide Transaktionen global zu blockieren, wäre eine schwerere Intervention als die Inscriptions selbst.
Die Governance-Beobachtung war härter. Bitcoin Core hat kein Mandat, soziale Kämpfe zu gewinnen. Die Maintainer liefern die Referenz-Implementation. Operatoren, die nicht einverstanden sind, können Alternativ-Clients laufen lassen, ohne den Konsens zu spalten. Bitcoin Knots existierte genau dafür: Operatoren, die Inscription-Relay als schädlich sahen, hatten einen Opt-in-Pfad.
Casey Rodarmor startete Ordinals auf dem Bitcoin Mainnet am 21.01.2023. Inscription Nr. 0 wurde am 14.12.2022 erstellt. Als die CVE im Dezember 2023 eingereicht wurde, lief die Technik bereits fast ein Jahr im aktiven Mainnet-Einsatz. Die Katze war aus dem Sack.
Zwei Clients spalteten sich
Bitcoin Core lehnte den Filter-Patch ab. Inscription-Transaktionen blieben unter der Standard-Core-Policy relay-fähig.
Bitcoin Knots 25.1.knots20231115 lieferte den Filter. Der Knots-Inspektor liest das Witness nach einer OP_FALSE OP_IF Hülle ab und verwirft die Transaktion beim Relay, wenn die Payload die konfigurierte Obergrenze überschreitet.
Beide Clients setzen dieselben Konsens-Regeln durch. Beide validieren dieselben Blöcke. Sie unterscheiden sich nur darin, welche Transaktionen sie vor dem Mining weiterleiten.
Knots-Adoption war ein Barometer dafür, wie viel des Netzwerks der Filter-Position zustimmte. Erreichbare Knots-Nodes wuchsen von rund 69 im Januar 2024 auf etwa 4 240 von 23 842 erreichbaren Nodes Anfang September 2025, etwa 17,78 Prozent des lauschenden Netzwerks. Dieser Anstieg fiel mit dem v30.0 Policy-Streit zusammen, nicht mit der ursprünglichen CVE-Einreichung.
Zwei Jahre später erhöhte Bitcoin Core das Limit 1200x
Bitcoin Core 30.0 erschien am 10.10.2025. Eine Zeile Policy in den Release Notes rahmte die ganze Episode neu.
PR #32359 von Peter Todd hob das Standard--datacarriersize von 83 Bytes auf 100 000 Bytes an. Das ist ein Faktor 1 200. Derselbe PR entfernte ausserdem die Obergrenze der OP_RETURN Outputs pro Transaktion. Operatoren, die das alte Verhalten wollten, konnten weiter -datacarriersize=83 beim Start übergeben.
Das Framing zählt. Zwei Jahre nachdem eine CVE Core aufforderte, den OP_RETURN-Filter zu verschärfen, veröffentlichte Core eine Version, die ihn ausser Kraft setzte. Die Maintainer argumentierten im PR-Thread, die Durchsetzung sei unhaltbar geworden. Inscriptions hatten das Limit ohnehin über Witness-Hüllen umgangen. Der OP_RETURN-Cap bestrafte den einen Pfad, der explizit für kleine Mengen beliebiger Metadaten gedacht war, während er den unbeabsichtigten Pfad weit offen liess. Die Maintainer rahmten die Änderung als Symmetrie, nicht als Kapitulation.
Lies es wie du willst. Der Policy-Filter, den die CVE von Core erweitern wollte, ignoriert jetzt standardmässig mehr als hundert Kilobyte pro Transaktion.
Bitcoin Knots lief mit seinem eigenen, strikteren Filter parallel weiter. Das v30.0 Release trieb den Knots-Adoption-Anstieg im September 2025.
Was die Episode über Bitcoin Governance zeigt
Bitcoin hat keinen CEO. Keinen Vorstand. Keinen Weg, einen Sicherheits-Patch auf eine Referenz-Implementation zu erzwingen. Tieferer Blick auf das Protokoll: Technical Deep Dive.
CVE-2023-50428 testete, ob eine eingereichte CVE den sozialen Prozess um Bitcoin Core unter Druck setzen kann. Die Antwort war Nein. Die CVE wurde ein öffentlicher Eintrag. Der Patch wurde kein Default. Zwei Jahre Debatte später ging Core in die Gegenrichtung.
Das Resultat ist das System wie designt, nicht wie kaputt. Ein Entwickler, der widersprach, lieferte einen anderen Client. Operatoren, die mit ihm einverstanden waren, liessen diesen Client laufen. Die Referenz-Implementation setzte Defaults, die der On-Chain-Realität entsprachen. Das Netzwerk produzierte durchgehend Blöcke. Keine Gelder gefährdet. Kein Konsens gebrochen.
Wer hier einen Sicherheitsvorfall sucht, findet keinen aufzuräumen. Wer einen Governance-Meilenstein sucht: so sieht einer in Bitcoin aus. Eine eingereichte Meinungsverschiedenheit, zwei Clients, ein Netzwerk, das ohne Einstimmigkeit läuft, und ein Default, der irgendwann der Realität nachzieht.
Für Wallet-Hygiene, die unabhängig von Relay-Policy-Streits gilt, siehe die Bitcoin Self-Custody Anleitung und die BIP-39 Brute-Force Anleitung. Für die Inscriptions-Seite der Geschichte siehe Bitcoin Ordinals erklärt.
Weiterlesen:
- CVE-2023-50428 NVD Detail
- CVE-2023-50428 cve.org Record
- bitcoin/bitcoin Issue #29187
- Bitcoin Core 30.0 Release Notes
- release-notes-30.0.md auf GitHub
- PR #32359 Remove arbitrary limits on OP_RETURN datacarrier outputs
- Ordinals Protocol Docs
Neu bei Bitcoin? Beginne mit Kapitel 1. Es dauert acht Minuten.
Das ganze Bild? Lies alle 19 Kapitel kostenlos oder bestelle das gedruckte Buch.
