Liquid Network: 4.000 BTC aus Blockstreams Peg abgeflossen

Es gibt Zahlen, die muss man zweimal lesen. 197,47 BTC. So viel Bitcoin liegt am Mittag des 7. September 2026 noch in der Reserve-Adresse des Liquid Network. Am Vortag waren es rund 4.200.

Dazwischen liegen ein Cache, der eine Frage zu wenig gestellt hat, eine Kette, die sich in zwei Wahrheiten gespalten hat, und eine Verhandlung über 320 Millionen Dollar, die vollständig in der Bitcoin-Blockchain stattfindet.

Update vom 7. September 2026, 15:10 Uhr:

Seit der ersten Fassung dieses Artikels ist viel passiert. Die Ursache ist geklärt: ein Cache-Fehler in der Elements-Software, der ungedecktes L-BTC entstehen ließ – keine gestohlenen Schlüssel. Die Föderation hat den Peg angehalten, Börsen haben L-BTC-Ein- und -Auszahlungen gestoppt. Blockstream und die Angreifer verhandeln per OP_RETURN; wir haben die PGP-Signaturen der Blockstream-Nachrichten selbst geprüft – sie sind echt. Und wir korrigieren eine Aussage aus der ersten Fassung: Die verbliebenen L-BTC sind nicht voll gedeckt. Warum wir das zunächst anders gelesen haben und was tatsächlich stimmt, steht weiter unten. Die Erklärung des Bugs haben wir außerdem deutlich vertieft – inklusive der Frage, warum ein Balance Proof allein nicht genügt.

Kurzfassung:

Am 6. September 2026 hat jemand über einen Fehler in Elements – der Software, auf der Liquid läuft – rund 4.000 L-BTC ohne Deckung erzeugt und über den Peg-out-Dienst SideSwap in echtes Bitcoin getauscht. Die Föderation zahlte 3.996 BTC aus, weil aus ihrer Sicht alles korrekt war: gültige Signaturen, freigegebene Zieladresse, keine kompromittierten Schlüssel. Die Reserve fiel von rund 4.200 auf 197,47 BTC. Die Empfänger meldeten sich per OP_RETURN als „whitehats" und bieten an, den Großteil zurückzugeben – nachdem der Bug gepatcht ist. Blockstream hat am 7. September um 09:04 UTC PGP-signiert geantwortet: „Bridge nodes are patched, safe to return the funds." Die 3.998,5 BTC liegen zur Stunde unbewegt auf der Adresse der Angreifer. Bitcoin selbst ist nicht betroffen – kein Block, keine Regel, keine Wallet in Selbstverwahrung.

Die Ursache: ein Cache, der eine Frage zu wenig stellte#

Der Fehler liegt nicht bei SideSwap, und er liegt nicht in der Kryptografie. Er liegt in einer Abkürzung – und um zu verstehen, warum diese Abkürzung so teuer war, muss man kurz wissen, wie Liquid überhaupt prüft, was es nicht sehen kann.

Zwei Beweise, weil die Beträge verborgen sind#

Liquid nutzt Confidential Transactions: Die Beträge sind verschlüsselt. Sichtbar ist nur eine mathematische Zusage, ein sogenanntes Pedersen-Commitment. Ein Node sieht also nicht „5 L-BTC", sondern einen Punkt auf einer elliptischen Kurve. Damit trotzdem niemand Geld erfindet, muss er anders prüfen – mit zwei Beweisen.

Der Balance Proof zeigt: Die Summe der Eingänge entspricht der Summe der Ausgänge. Was reingeht, kommt raus. Das klingt, als wäre man damit fertig. Ist man nicht.

Denn ein Betrag ist hier eine Zahl in endlicher Arithmetik, und die kann überlaufen. Ohne weitere Absicherung ließe sich die Bilanz mit einem negativen Ausgang fälschen:

Warum der Balance Proof allein nicht reicht:

Ein Angreifer legt 1 L-BTC hinein und nimmt zwei Ausgänge heraus: einen über 4.000 L-BTC und einen über −3.999 L-BTC. Die Summe stimmt, der Balance Proof ist zufrieden. Den positiven Ausgang gibt der Angreifer aus, den negativen rührt er nie wieder an. Aus 1 wurden 4.000.

Genau das verhindert der Range Proof. Er beweist, ohne den Betrag zu verraten, dass der verborgene Wert im erlaubten Bereich liegt – nicht negativ, nicht übergelaufen. Elements lehnt zusätzlich jeden ausgabefähigen Ausgang ab, dessen bewiesene Untergrenze null ist. Der Range Proof ist damit die Schicht, an der die gesamte Geldmenge von Liquid hängt.

Die Abkürzung#

Range Proofs zu prüfen ist rechenintensiv – bei jedem Ausgang jeder Transaktion jedes Blocks. Also merkt sich jeder Node erfolgreiche Prüfungen: Diesen Beweis hatte ich schon, der war gültig. Damit er ihn wiedererkennt, braucht das Ergebnis eine Bezeichnung, den Cache-Schlüssel. Dort saß der Fehler.

Die Prüffunktion in Elements hängt an drei Dingen – das lässt sich im Quelltext nachlesen:

secp256k1_rangeproof_verify(ctx, &min_value, &max_value,
                            &commit,        // das Wert-Commitment
                            proof, len,
                            scriptPubKey,   // wird in den Beweis eingebunden
                            &tag);          // der Asset-Generator

Der entscheidende Punkt steckt im letzten Argument. Ein Pedersen-Commitment hat für sich genommen keine Bedeutung. Erst der Asset-Generator legt fest, welchen Betrag dieselben Bytes darstellen. Dieselbe Zusage unter einem anderen Generator ist ein anderer Betrag. Auch das Ausgabeskript geht in den Beweis ein.

Der Cache-Schlüssel kannte von diesen drei Dingen nur zwei – und ausgerechnet die beiden, die sich am leichtesten wiederverwenden lassen:

// vorher – Schlüssel nur aus Beweis + Wert-Commitment
hasher.Write(proof.data(), proof.size())
      .Write(commitment.data(), commitment.size())
      .Finalize(entry.begin());

// nachher – Asset-Generator und Skript gehören dazu
hasher.Write(proof.data(), proof.size())
      .Write(commitment.data(), commitment.size())
      .Write(asset_commitment.data(), asset_commitment.size())
      .Write(scriptPubKey.data(), scriptPubKey.size())
      .Finalize(entry.begin());

Gleicher Beweis plus gleiches Commitment ergab denselben Schlüssel – egal für welches Asset und welches Skript. Der Node meldete „kenne ich, ist gültig" für eine Prüfung, die er in dieser Kombination nie durchgeführt hatte.

Der Angriff#

Damit wird aus einem Effizienz-Fehler eine Anleitung. Man muss den Cache nur vorher füttern:

1. Den Cache füttern

Der Angreifer sendet eine völlig reguläre Transaktion mit gültigem Range Proof. Die Nodes prüfen sie ordentlich durch, alles korrekt – und legen das Ergebnis unter dem Schlüssel aus Beweis und Wert-Commitment ab.

2. Auf dem Schlüssel kollidieren

Jetzt eine zweite Transaktion, die denselben Beweis und dasselbe Wert-Commitment wiederverwendet – aber in einem anderen Kontext, für den dieser Beweis nie geprüft wurde. Der Cache-Schlüssel ist identisch.

3. Durchgewunken werden

Cache-Treffer. Der Node überspringt die Prüfung und meldet „gültig". Ob der Beweis in diesem neuen Kontext tatsächlich trägt, fragt niemand mehr – er tut es nicht. So entsteht L-BTC, für das nie Bitcoin eingezahlt wurde.

4. Auszahlen lassen

Das ungedeckte L-BTC geht an den Peg-out-Dienst SideSwap. Dort wird es regulär verbrannt, die Föderation prüft Signaturen und Zieladresse – beides einwandfrei – und zahlt echtes Bitcoin auf der Hauptkette aus.

Was wir hier belegen können – und was nicht:

Der Fehler ist zweifelsfrei: Wir haben den Cache-Schlüssel und die Prüffunktion im öffentlichen Elements-Quelltext gegeneinandergehalten, beides ist oben zu sehen. Die exakte Transaktion, mit der die Kollision erzeugt wurde, ist dagegen nicht öffentlich – und wegen der verschlüsselten Beträge auch nicht ohne Weiteres aus der Kette zu lesen. Der oben beschriebene Ablauf ist die Angriffsform, die dieser Fehler ermöglicht, nicht ein rekonstruiertes Protokoll der Tat.

Der Patch war schon geschrieben#

• 3. August 2026 – Blockstream-Entwickler Byron Hambly schreibt den Commit „fix: range proof cache bind to asset and scriptpubkey“ (212c43f4). Ohne Sicherheitshinweis, wie ein normaler Aufräum-Fix.
• 6. September, 17:21 UTC – Der Fix landet über Pull Request #1599 im Release-Zweig 23.3.x – knapp drei Stunden nachdem die 4.000 BTC bereits ausgezahlt waren.
• Version 23.3.3 – Das aktuelle öffentliche Release stammt vom 13. April 2026 und enthält den Fix nicht. Wer es einsetzte, lief mit dem Bug.

Diese drei Daten haben wir am 7. September direkt über die GitHub-API des Elements-Repositorys abgefragt. Sie sind öffentlich nachprüfbar – und sie erklären den bitteren Teil der Geschichte: Der Patch existierte seit über einem Monat. Er war nur nicht dort, wo er hätte sein müssen.

Warum 11-von-15 hier nichts genützt hat:

Das Multisig der Föderation schützt gegen kompromittierte Schlüssel – nicht gegen falsche Konsensregeln. Alle 15 Functionaries liefen mit derselben Elements-Version und damit mit demselben Bug. Sie hielten den Block einstimmig für gültig und signierten den Peg-out völlig korrekt. Auch die PAK-Whitelist griff nicht, denn sie prüft nur, wohin ausgezahlt wird – nicht, ob das L-BTC je hätte existieren dürfen. Jede Schutzschicht hat exakt das getan, wofür sie gebaut wurde. Der Fehler saß eine Ebene tiefer.

Der Riss geht mitten durch die Kette#

Ein Cache ist ein Gedächtnis, und Gedächtnisse unterscheiden sich. Ob ein Node den manipulierten Block akzeptierte, hing davon ab, ob er den fraglichen Beweis vorher schon einmal gesehen hatte. Damit war die Gültigkeit eines Blocks plötzlich keine Eigenschaft des Blocks mehr, sondern eine Eigenschaft der Vorgeschichte des jeweiligen Rechners.

Das lässt sich heute noch live beobachten. Wir haben am 7. September beide großen Liquid-Explorer nach ihrer aktuellen Blockhöhe gefragt:

• blockstream.info: Block 4.051.232 – Blockstreams eigener Node hat den umstrittenen Block 4.050.336 akzeptiert und folgt der Kette bis heute.
• liquid.network: Block 4.050.335 – Der Node von mempool.space hat den Block als ungültig verworfen und steht seitdem still – exakt einen Block vor dem Exploit.

Das ist kein Anzeigefehler. Das ist eine Kettenspaltung, und sie ist die ehrlichste Darstellung dessen, was passiert ist: Zwei ordentlich betriebene Nodes sind sich seit dem 6. September nicht mehr einig, welche Transaktionen es gegeben hat.

Korrektur: Die Deckung stimmt nicht#

In der ersten Fassung dieses Artikels stand, die Peg-Bilanz gehe rechnerisch weiterhin auf und wer noch L-BTC halte, sei „auf dem Papier voll gedeckt". Das war falsch, und der Grund dafür ist lehrreich.

Wir hatten die Reserve aus der Peg-Buchhaltung von blockstream.info abgeleitet: eingezahltes Bitcoin minus ausgezahltes Bitcoin. Diese Rechnung setzt aber voraus, dass jedes L-BTC aus einer echten Einzahlung stammt. Genau diese Annahme hat der Exploit gebrochen. Das erfundene L-BTC ging nie durch einen Peg-in, wurde aber durch den Peg-out ordnungsgemäß verbrannt – die Buchhaltung sieht deshalb ausgeglichen aus, obwohl das Geld weg ist. Eine Bilanz, die Inflation nicht abbilden kann, meldet auch keine.

Die tatsächliche Lage sieht man erst, wenn man den Node fragt, der den Exploit nicht akzeptiert hat:

• 4.205,02 L-BTC im Umlauf – Stand des letzten Blocks, den der Node von mempool.space für gültig hält (4.050.335). So viel L-BTC liegt in den Wallets ehrlicher Halter.
• 197,47 BTC in der Reserve – So viel Bitcoin liegt real auf der Reserve-Adresse der Föderation (bc1qdlld6a…). Von uns über die Bitcoin-Hauptkette geprüft, nicht aus einer Meldung übernommen.
• 4,7 % Deckung – Rund 4,7 Cent Bitcoin pro L-BTC – solange die Coins nicht zurückkommen. Das ist die eigentliche Nachricht dieses Vorfalls.

Wer heute L-BTC hält, hält also einen Anspruch, für den bis auf Weiteres knapp 5 % Deckung existieren. Ob daraus ein realer Verlust wird, hängt an einer einzigen Frage: ob die Angreifer die 3.998,5 BTC tatsächlich zurückschicken.

Was wir daraus mitnehmen:

Wir haben in der ersten Fassung die richtige Zahl abgefragt und die falsche Schlussfolgerung gezogen – weil wir die Buchhaltung des betroffenen Systems als unabhängigen Beleg behandelt haben. Sie ist es nicht. Bei Confidential Transactions ist die umlaufende Menge L-BTC von außen nicht direkt zählbar; Beträge sind verschlüsselt, Commitments sehen bei jedem Wert gleich aus. Deshalb konnte die Inflation überhaupt so lange unsichtbar bleiben – sie fiel erst auf, als die Bitcoin auf der Hauptkette fehlten. Vertraulichkeit auf einer Kette kostet Prüfbarkeit. Auch das ist ein Tauschhandel.

Die Verhandlung findet in der Blockchain statt#

Was seit dem Abend des 6. September zwischen Blockstream und den Angreifern passiert, ist ohne Beispiel: Beide Seiten schreiben ihre Nachrichten als OP_RETURN in Bitcoin-Transaktionen. Jeder kann mitlesen. Wir haben die Adresse der Angreifer ausgelesen und die Nachrichten entschlüsselt – hier ist der Verlauf, ohne den Werbe- und Spam-Müll, der sich inzwischen darüberlegt.

• 6.9., 18:30 UTC · „we are whitehats. contact us on chain“ – Die Angreifer melden sich aus der Adresse, auf der die 3.998,5 BTC liegen. Zwei Ausgänge, eine Botschaft, keine Forderung.
• 6.9., 19:31 UTC · Blockstream antwortet – „Please contact security@blockstream.com“ – 1.000 Satoshi und eine E-Mail-Adresse, geschrieben in die Kette.
• 6.9., 20:38 UTC · Gegenvorschlag Signal – Die Angreifer wollen über Signal reden. Blockstream bleibt auf der Kette – dort ist jede Nachricht öffentlich und signierbar.
• 7.9., 02:20 UTC · „sending most back … is that ok“ – Erstes konkretes Angebot: Rückgabe des Großteils an die Reserve-Adresse der Föderation. Das Wort „most“ bleibt bis heute unbeziffert.
• 7.9., 03:16 UTC · „Yes, thank you.“ – Blockstreams Antwort, PGP-signiert. Wir haben die Signatur gegen den auf blockstream.com veröffentlichten Schlüssel geprüft: gültig.
• 7.9., 03:30 UTC · Die Bedingung – „Please fix the bug first. The chain is under risk at latest commit right now. Make sure every node is patched.“ Die technischen Details liefern die Angreifer PGP-verschlüsselt mit.
• 7.9., 09:04 UTC · „Bridge nodes are patched, safe to return the funds.“ – Blockstream meldet die Nodes als gepatcht – erneut PGP-signiert, erneut von uns verifiziert. Seitdem: Stille.

Die Signaturen sind echt – geprüft, nicht geglaubt:

Wir haben Blockstreams öffentlichen Sicherheitsschlüssel von blockstream.com/pgp.txt geladen und beide signierten Nachrichten lokal mit GnuPG verifiziert. Ergebnis: gültige Signaturen des Schlüssels mit dem Fingerabdruck 1176 542D A98E 71E1 3372 2EF7 4AC8 CC88 6844 A2D6, ausgestellt auf „Blockstream Security Reporting". Signaturzeitpunkte: 7. September, 03:16:04 UTC und 09:04:57 UTC. Das beweist nicht, dass der Deal hält – aber es beweist, dass wirklich Blockstream schreibt.

Der gefälschte Gegenvorschlag#

Warum das Signieren keine Formalie ist, zeigt derselbe Bitcoin-Block 965.912. Dort steht neben Blockstreams signierter Nachricht noch eine zweite:

„Thank you for finding the bug, we are working on a fix immediately, please send 3900 Bitcoin back to this address, you may keep the 98 BTC as Bounty reward."

Freundlicher Ton, plausible Zahlen, großzügige „Belohnung" – und keine Signatur, dafür eine andere Empfängeradresse. Jemand hat versucht, sich in eine 320-Millionen-Dollar-Rückgabe hineinzuschreiben. Auf derselben Adresse liegen inzwischen dutzende weitere Nachrichten: Memecoin-Werbung, Monero-Tauschdienste, Bettelbriefe, ein Anwalt aus New York, der Pro-bono-Beistand anbietet.

Das ist der zweite unterschätzte Befund dieses Vorfalls. Ein öffentlicher Kanal ist manipulationsanfällig, sobald er wertvoll wird. Was ihn rettet, ist nicht der Kanal, sondern die Signatur. Genau dasselbe Prinzip, auf dem Bitcoin selbst beruht.

„Whitehat" ist eine Behauptung, kein Ausweis#

Die Nachricht in der Kette liest sich beruhigend. Sie sollte es weiterhin nicht.

Die Formulierung ist seit Jahren Standardrepertoire nach großen Exploits: Beim Poly-Network-Hack 2021 (rund 610 Millionen Dollar) und beim Euler-Finance-Exploit 2023 (rund 197 Millionen Dollar) haben die Angreifer ebenfalls über On-Chain-Nachrichten kommuniziert, sich als Whitehats bezeichnet und anschließend über die Rückgabe verhandelt – inklusive der Frage, welchen Anteil sie als „Bounty" behalten.

Für die Whitehat-These spricht diesmal einiges: Die Coins wurden bis heute nicht bewegt, nicht gemischt, nicht über Tauschdienste geschickt. Die Kommunikation ist technisch kompetent und die Bedingung – erst patchen, dann zurückgeben – ergibt fachlich Sinn. Dagegen spricht die schlichte Tatsache, dass echte Sicherheitsforscher sich vor dem Abfluss beim Betreiber melden, nicht danach bei der Öffentlichkeit. Und dass „den Großteil zurück" bis zur Stunde keine Zahl hat.

Der einzige Test, der zählt:

Nicht die Nachricht. Nicht der Ton. Nicht die Signatur der Gegenseite. Sondern eine Transaktion, die 3.998,5 BTC an bc1qdlld6a… zurückschickt. Bis dahin ist „Whitehat" eine Erzählung, die einen Diebstahl in eine Rettungsaktion umbenennt – und die praktischerweise auch dann noch verfügbar ist, wenn man sich später anders entscheidet.

Bitcoin ist nicht betroffen – das ist keine Floskel#

Hier ist Präzision wichtiger als Dramatik.

Am Bitcoin-Protokoll ist nichts passiert. Kein Block wurde umgeschrieben, keine Regel gebrochen, keine Signatur gefälscht. Wer seine Bitcoin auf einer Hardware Wallet in Selbstverwahrung hält, hat von diesen zwei Tagen exakt nichts gemerkt – und das ist keine Beschwichtigung, sondern der Kern der Sache.

Betroffen ist eine Nebenkette mit einem völlig anderen Sicherheitsmodell. Bei Bitcoin prüft dein eigener Node jede Regel, und tausende unabhängige Implementierungsinstanzen prüfen mit. Bei Liquid liefen alle 15 signierenden Functionaries mit derselben Software – ein einziger Fehler in dieser Software genügte, um die gesamte Föderation gleichzeitig blind zu machen. Das ist ein bewusster Tauschhandel: schnellere Blöcke, vertrauliche Beträge, tokenisierte Assets – bezahlt mit Vertrauen in eine benannte Gruppe und in einen einzigen Code-Pfad. Wie dieser Tausch technisch funktioniert, haben wir ausführlich im Liquid Network erklärt beschrieben.

Der 6. September 2026 hat diesen Tauschhandel nicht widerlegt. Er hat nur die Rechnung präsentiert.

Es ist nicht der erste Riss im Liquid-Peg#

Wer den Vorgang einordnen will, sollte 2020 kennen.

Am 26. Juni 2020 machte der Entwickler James Prestwich (Summa) eine Inkonsistenz zwischen den Timelocks in Liquids Functionary-Hardware (HSMs) und den Functionary-Servern öffentlich. Die Folge: Bei einer großen UTXO über 870 BTC lief der Timelock für rund 40 Minuten ab. In diesem Fenster hätten die Inhaber eines 2-von-3-Notfallschlüssels die Coins bewegen können – vorbei am eigentlich vorgeschriebenen 11-von-15-Multisig.

Blockstream bestätigte den Bug, patchte ihn und betonte, die Backup-Recovery-Schlüssel seien nie verwendet worden. Aber die Größenordnung war bemerkenswert: Der Fehler existierte laut den damaligen Berichten seit 18 Monaten und betraf über 2.000 UTXOs.

• 2018 · Liquid startet – Erste produktive Bitcoin-Sidechain mit Föderationsmodell. Schnelle Blöcke, Confidential Transactions, tokenisierte Assets.
• 2020 · Timelock-Bug wird öffentlich – 870 BTC waren für rund eine Stunde über einen 2-von-3-Notfallschlüssel angreifbar. Bug bestand 18 Monate, über 2.000 UTXOs betroffen.
• 2026 (Q1) · 87 Föderationsmitglieder – Die Föderation wächst auf 87 Mitglieder auf sechs Kontinenten – die Zahl der signierenden Functionaries bleibt bei 15.
• 3.8.2026 · Der Fix wird geschrieben – Der Range-Proof-Cache-Bug wird im Elements-Master behoben – ohne Sicherheitswarnung, ohne Release.
• 6.9.2026 · 4.000 BTC verlassen den Peg – Ungedecktes L-BTC wird erzeugt und über SideSwap ausgezahlt. Die Reserve fällt auf 197,47 BTC. Der Patch landet drei Stunden zu spät im Release-Zweig.

Zwischen 2020 und 2026 liegt derselbe Befund: Die Schwachstelle war nie die Kryptografie. Sie lag in Betriebsorganisation und Software-Monokultur – in Release-Prozessen, Patch-Verteilung und der Annahme, dass 15 identische Systeme fünfzehnfache Sicherheit bedeuten. Sie bedeuten das Gegenteil, wenn der Fehler im gemeinsamen Code sitzt.

Was L-BTC-Halter jetzt tun sollten#

Ganz nüchtern, ohne Panik – und ohne Verharmlosung:

1. Prüfen, ob du überhaupt L-BTC hältst

Viele Nutzer haben L-BTC, ohne es so zu nennen: in Sidechain-fähigen Wallets, über bestimmte Börsen, in Liquid-basierten Handels- oder Tokenisierungsprodukten. Wenn du ausschließlich Bitcoin auf der Hauptkette und im Lightning Network hältst, betrifft dich der Vorgang nicht.

2. Abwarten – handeln geht ohnehin kaum

Peg-ins und Peg-outs sind gestoppt, die Bridge-Nodes abgeschaltet, große Börsen haben L-BTC-Ein- und -Auszahlungen ausgesetzt. Wer jetzt Panik-Angebote unter Marktwert annimmt, verkauft womöglich zum Bruchteil eines Anspruchs, der später wieder vollständig bedient wird. Wer stattdessen auf Rückgabe wartet, trägt das Risiko, dass sie ausbleibt. Beides ist eine echte Entscheidung, keine Formsache.

3. Andere Liquid-Assets im Blick behalten

USDT, DePix und tokenisierte Wertpapiere auf Liquid sind vom Bug nicht betroffen – sie hängen nicht am Bitcoin-Peg. Aber sie sind während der Pause bewegungsunfähig. Ein Emittentenrisiko ist damit nicht verschwunden, es ist nur ein anderes.

4. Auf einen verifizierbaren Reserve-Nachweis bestehen

Ein Blogpost reicht nicht. Was zählt: eine signierte Post-Mortem-Analyse, eine belegte Patch-Verteilung über alle Functionaries und ein nachprüfbarer Nachweis der Hauptketten-Bestände nach der Rückgabe. Nach 2020 hat Blockstream so etwas schon einmal geliefert – das ist ein realistischer Maßstab.

5. Danach die Grundsatzfrage stellen

Nicht „ist Liquid sicher?", sondern: Wofür brauche ich diese Nebenkette überhaupt? Wenn die Antwort „günstiger sparen" oder „einfacher aufbewahren" lautet, ist die Antwort falsch. Dafür ist die Selbstverwahrung auf der Hauptkette da – notfalls mit Multisig, wenn die Beträge groß werden.

Die eigentliche Lehre#

Ein föderierter Peg ist keine Layer 2 im Sinne von „Bitcoin, nur schneller". Er ist Fremdverwahrung mit zusätzlichen Schritten – professionell gemacht, geografisch verteilt, mit ordentlicher Hardware, aber im Kern eben doch: fremde Leute halten deine Schlüssel und fremder Code entscheidet, was als dein Guthaben gilt.

Das ist kein Vorwurf an Liquid. Liquid hat nie etwas anderes behauptet; das Whitepaper ist da vollkommen ehrlich. Der Fehler entsteht erst in der Vermarktung, wenn aus „Sidechain mit Föderationsvertrauen" in der Zusammenfassung ein „Bitcoin Layer 2" wird und die Leute den Unterschied nicht mehr hören.

Der Unterschied ist genau der, den man an einem Tag wie diesem spürt. Auf der Hauptkette gibt es keinen Tag, an dem 95 % der Reserve verschwinden können – weil es keine Reserve gibt. Es gibt nur UTXOs und Schlüssel, und wenn du den Schlüssel hast, hast du die Coins. Kein Cache entscheidet, ob dein Bitcoin existiert. Deshalb ist der eigene Node kein Hobby für Technikbegeisterte, sondern der Unterschied zwischen Prüfen und Glauben.

Der Satz, auf den es hinausläuft:

Jede Schicht über Bitcoin, die dir eine Bequemlichkeit verkauft, verkauft dir gleichzeitig ein Vertrauensverhältnis. Manchmal lohnt sich der Tausch – für Handel, für Tokenisierung, für schnelle Abwicklung zwischen Unternehmen. Für Sparen lohnt er sich nie.

Häufige Fragen#

Ist Bitcoin gehackt worden? Nein. Das Bitcoin-Protokoll, die Hauptkette und alle Wallets in Selbstverwahrung sind unberührt. Betroffen ist ausschließlich das Liquid Network, eine separate Sidechain mit eigenem Sicherheitsmodell und eigener Software.

Was war die Ursache? Ein Cache-Fehler in Elements, der Software hinter Liquid. Damit Nodes nicht jeden teuren Range Proof doppelt prüfen, merken sie sich erfolgreiche Prüfungen. Der Schlüssel dieses Gedächtnisses bestand aber nur aus Beweis und Wert-Commitment – der Asset-Generator und das Ausgabeskript fehlten, obwohl die Prüfung selbst von beiden abhängt. Wer den Cache zuerst mit einer gültigen Transaktion füttert und dann eine zweite mit demselben Schlüssel nachschiebt, bekommt ein „gültig" für eine Prüfung, die nie stattgefunden hat. So entstand L-BTC ohne Deckung. Keine Schlüssel wurden gestohlen.

Wie viel Bitcoin ist abgeflossen? SideSwap zufolge zahlte die Föderation am 6. September um 14:28 UTC 3.996 BTC aus. Auf der Adresse der Angreifer liegen aktuell 3.998,49937410 BTC. Beim Kurs vom 7. September (rund 79.300 US-Dollar) sind das etwa 317 Millionen Dollar oder 273 Millionen Euro.

Sind die verbliebenen L-BTC gedeckt? Derzeit nicht. Rund 4.205 L-BTC stehen 197,47 BTC in der Reserve-Adresse gegenüber – eine Deckung von etwa 4,7 %. Das ändert sich in dem Moment, in dem die Angreifer die Coins zurückschicken. Bis dahin ist es der Stand der Dinge.

Ist SideSwap schuld? Nein. Der Dienst hat einen regulären Peg-out-Auftrag verarbeitet; das eingelieferte L-BTC war für ihn von echtem L-BTC nicht unterscheidbar. Der PAK-Schlüssel von SideSwap wurde laut Liquid nicht kompromittiert.

Was ist ein Peg-out? Der Rückweg von der Sidechain zu Bitcoin: Auf Liquid wird L-BTC vernichtet, danach geben die Functionaries die entsprechende Menge echtes Bitcoin auf der Hauptkette frei. Dafür braucht es 11 von 15 Signaturen, und die Zieladresse muss über die Peg-out Authorization Keys freigegeben sein. Beides hat funktioniert – geprüft wurde nur nie, ob das vernichtete L-BTC echt war.

Hat Blockstream sich geäußert? Öffentlich bislang nur knapp; ein Post-Mortem im Firmenblog steht aus, CEO Adam Back schweigt. Die inhaltliche Kommunikation läuft PGP-signiert über OP_RETURN-Nachrichten in der Bitcoin-Blockchain. Wir aktualisieren diesen Artikel, sobald eine offizielle Stellungnahme vorliegt.

Muss ich jetzt meine Bitcoin von der Börse holen? Das solltest du unabhängig von diesem Vorfall. Bitcoin bei einem Dritten ist eine Forderung gegen ein Unternehmen, nicht Bitcoin. Der Liquid-Vorgang ist nur die aktuellste Erinnerung daran.

👉 Liquid Network erklärt 👉 Sicher aufbewahren 👉 Workshop besuchen

Weiterlesen#

• Wie sicher ist Bitcoin? – Warum die Basisschicht ein anderes Sicherheitsversprechen gibt als jede Schicht darüber – und wo die tatsächlichen Risiken liegen.
• Multisignatur-Wallets – Wenn Beträge groß werden: mehrere Schlüssel, die du selbst kontrollierst – statt fremder Föderation.
• Eigene Node betreiben – Sechs Gründe, warum Prüfen besser ist als Glauben – der Unterschied, um den es in diesem Artikel geht.

---

Stand: 7. September 2026, 15:10 Uhr. Dieser Artikel wird weiter aktualisiert.

Korrekturhinweis: In der ersten Fassung vom 6. September hieß es, die verbliebenen L-BTC seien rechnerisch voll gedeckt. Das war falsch; die Passage wurde ersetzt und der Fehler im Abschnitt Korrektur erklärt.

Quellen und eigene Prüfung: Wir haben am 7. September 2026 selbst nachgeprüft und nicht aus Meldungen übernommen: den Kontostand der Angreifer-Adresse bc1ql4mfu6aundtkksxklfajs2h3t9nzcd6gyqjlte und den Bestand der Föderations-Reserve bc1qdlld6antmv4xug242ed83q7k4rqw50cwfns38szx4qu2f4jwaxxsuhwxxr über die mempool.space-API; sämtliche OP_RETURN-Nachrichten des Schlagabtauschs; die Gültigkeit der beiden PGP-Signaturen von security@blockstream.com mit GnuPG gegen den unter blockstream.com/pgp.txt veröffentlichten Schlüssel; die auseinanderlaufenden Blockhöhen von blockstream.info und liquid.network; sowie Commit 212c43f4, Pull Request #1599 und den Quelltext von src/script/sigcache.cpp über die GitHub-API des Elements-Repositorys. Ergänzende Berichterstattung: news.bitcoin.com, crypto.news, Blocktrainer, defiprime. On-Chain-Erstmeldung von ErgoBTC. Hintergrund zum Timelock-Bug 2020: Blockstream Engineering Blog und CoinDesk.

---

Dieser Artikel erschien zuerst auf bitcoinlighthouse.de – dort findest du auch unsere Bitcoin-Workshops in München.