Liquid Network: 3.400 BTC zurück, 598,5 BTC bleiben Faustpfand

Vorweg in eigener Sache#

Vor sieben Wochen habe ich einen Artikel gelöscht, den ich hätte stehen lassen sollen.

Er hieß „Warum ich mich in Liquid getäuscht habe", erschien am 22. Juli 2026 und stand gut eine Woche online. Darin habe ich meine eigene Meinung revidiert: Ich hatte die Liquid-Sidechain eine Weile für eine spannende Erweiterung von Bitcoin gehalten und auch so darüber geschrieben. Irgendwann fiel mir auf, dass ich mir das schöngeredet hatte. Selbst Aqua – eine wirklich angenehme Wallet, an der ich handwerklich wenig auszusetzen habe – schiebt am Ende Token auf einer fremden Kette hin und her. Eine Sidechain ist nicht die Hauptkette. Was dort liegt, ist kein Bitcoin, sondern ein Anspruch gegen fünfzehn Unternehmen und deren Software. Genau solche Sachen, schrieb ich damals sinngemäß, können dabei eben passieren.

Dann habe ich den Text zurückgezogen. Von der Seite, von Nostr, überall. Nicht, weil sich jemand beschwert hätte, und auch nicht, weil ich Streit gescheut hätte. Sondern weil ich es mit einem Grundsatz halte, der mir wichtig ist: keine negative Energie in die Welt setzen. Beim Wiederlesen kam mir der Text vor wie ein Angriff auf Leute, die es ernst meinen und ordentlich arbeiten. Etwas in die Welt zu geben, das vor allem gegen jemanden gerichtet ist, wollte ich nicht. Also nahm ich es weg.

Das musst du mir nicht glauben:

Das Löschen hat sich selbst dokumentiert. Auf den Nostr-Relays liegt bis heute mein signiertes Lösch-Event vom 12. August 2026, 14:26 UTC. Es nennt den Artikel beim Namen (warum-ich-mich-in-liquid-getaeuscht-habe), verweist auf die ursprüngliche Veröffentlichung und trägt die Begründung, die ich damals angegeben habe: „Meinungsartikel zurückgezogen – die sachliche Einordnung steht in ‚Liquid Network erklärt‘." Jeder kann es nachlesen: njump.me/note1rx9…. Die Signatur stammt aus meinem Schlüssel, der Zeitstempel von fremden Relays – nachträglich ändern kann ich weder das eine noch das andere. Und weil ich schon dabei bin, ehrlich zu sein: Die Begründung in diesem Lösch-Event ist die aufgeräumte, sachliche Version. Die eigentliche steht im Absatz darüber.

Am 6. September 2026 sind rund 4.000 BTC aus der Liquid-Reserve abgeflossen.

Der toxische Maximalist hätte recht behalten.

Was in dem alten Text stand – und was nicht:

Ich will daraus nicht mehr machen, als drinsteht: Kein Wort über Range Proofs, Caches oder Elements 23.3.3. Den konkreten Fehler hat niemand vorhergesehen, ich am allerwenigsten. Was drinstand, war das Allgemeinere und deshalb Unbequemere – dass eine Sidechain Risiken bündelt, die auf der Hauptkette gar nicht erst existieren, und dass man diesen Preis leicht kleinredet, wenn die Technik interessant genug ist. Diese Rechnung wurde am 6. September präsentiert. Nur eben durch eine Tür, an die keiner gedacht hatte.

Der Artikel steht seit heute wieder online – unverändert, kein Wort korrigiert, mit dem Datum vom 22. Juli: Warum ich mich in Liquid getäuscht habe. Ich habe ihn nicht wieder ausgegraben, weil ich recht behalten will. Sondern weil die Lehre daraus nicht die über Liquid ist, sondern die über das Löschen.

Zu dem Grundsatz stehe ich unverändert. Das Wegnehmen hat nur nicht das getan, was ich dachte.

Geschont hat es niemanden. Es hat dafür gesorgt, dass im September nichts mehr da war, wo vorher etwas stand. Ich hatte einen Angriff gesehen, wo eine Warnung lag. Das ist mein Teil an dieser Geschichte, und ich schreibe ihn hierhin, bevor ich über den Fehler anderer Leute schreibe.

Und noch etwas, das ich vor sieben Wochen nicht geschrieben hätte#

Bitcoin hat keine Marketingabteilung, keine Stiftung mit Vetorecht und keinen Chef, den man feuern könnte. Seine Verteidigung ist sozial. Dass es nie gekapert wurde – kein Premine, kein Wechsel auf Proof of Stake, der Blocksize-War überstanden, ein Jahrzehnt „Blockchain, nicht Bitcoin" abgeschüttelt – liegt nicht an der Kryptografie. Es liegt daran, dass genug Leute bereit waren, im richtigen Moment sozial unangenehm zu sein. Ketten mit freundlicher, „konstruktiver", offener Kultur sind reihenweise von ihren eigenen Stiftungen und Wagniskapitalgebern eingesammelt worden. Die toxischen Maximalisten sind das Immunsystem.

Das ist keine neue Idee, ich habe sie hier schon einmal aufgeschrieben – nur eine Ebene tiefer: Das „Gehirn" von Bitcoin ist gar kein Gehirn, sondern ein Immunsystem, dezentral, ohne Zentrum, und gerade deshalb nicht überstimmbar. Was für den Konsens gilt, gilt für die Kultur drumherum.

Bei Liquid hatten sie jahrelang recht, und es wurde als Lärm behandelt. Von mir auch. Ich habe meinen Text weggenommen, um meine eigene Ruhe zu behalten, und die Warnung ging mit. Das war der Fehler, nicht der Ton.

Den ausgleichenden, verständnisvollen Part können andere spielen. Dafür gibt es genug Leute.

Der Rest dieses Artikels ist Bericht: nachgerechnet, nachgeprüft, mit offengelegten Quellen.

Die Lage#

Es gibt Sätze, die klingen nach Lösung und sind keine. „Sende den Großteil zurück" war so einer. Am 7. September 2026 um 16:09 UTC schickten die Angreifer 3.400,0 BTC an die Reserve-Adresse des Liquid Network zurück – auf die Satoshi genau eine runde Zahl. Was sie behielten, ist ebenso rund: 598,50 BTC, gut 47 Millionen Dollar, exakt 15 Prozent der Beute.

Zwei Tage lang blieb offen, wie man das nennen soll. Seit dem 9. September, 11:45 UTC, ist es entschieden – nicht von Beobachtern, sondern von den Angreifern selbst: „You SHALL pay 10% using your own money as bug bounty or you will cause all your holders a 15% loss." Das ist keine Verhandlung mehr. Das ist eine Forderung, in die Bitcoin-Blockchain geschrieben, wo jeder sie lesen kann.

Update vom 10. September 2026, 21:30 Uhr:

Liquid läuft wieder. Seit dem 9. September, 21:05 UTC, produziert die Kette wieder Blöcke – und beide großen Explorer zeigen erstmals seit dem 6. September wieder denselben Block. Die Kettenspaltung ist damit geschlossen. Der Exploit-Block ist raus: Auf Höhe 4.050.336 sitzt heute ein anderer Block als am 6. September; der ungültige Peg-out wurde wie angekündigt verworfen. Die Bitcoin-Lücke bleibt: Die Angreifer halten weiterhin unbewegt 598,50 BTC, die Deckung liegt bei rund 85 %. Zweiter Patch: Elements 23.3.4 ist am 9. September erschienen – der erste Fix reichte nicht, warum, steht weiter unten. Alle Zahlen von mir am 10. September neu abgefragt.

Kurzfassung:

Am 6. September 2026 um 13:53 UTC 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. 35 Minuten später zahlte die Föderation 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. Nachdem Blockstream die Bridge-Nodes gepatcht hatte, kamen am 7. September um 16:09 UTC 3.400 BTC zurück; die Reserve steht bei 3.601,47 BTC, die Deckung bei rund 85 %. Die restlichen 598,50 BTC liegen unbewegt bei den Angreifern, die sie als Bounty beanspruchen und 10 % obendrauf fordern. Das Liquid-Netzwerk stand vom 7. bis zum 9. September still; seit dem 9. September, 21:05 UTC, läuft es wieder – ohne den Exploit-Block. 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 ich hier belegen kann – und was nicht:

Der Fehler ist zweifelsfrei: Ich habe 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 damals aktuelle öffentliche Release stammte vom 13. April 2026 und enthielt den Fix nicht. Wer es einsetzte – und das taten alle – lief mit dem Bug.

Diese drei Daten habe ich 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 erste Patch war nicht der letzte#

Am 8. September, 19:06 UTC, wurde in Elements ein zweiter Fix zusammengeführt – Pull Request #1600, „sigcache: harden range proof cache keys and add -norangeproofcache option". Am 9. September um 03:14 UTC erschien daraus die Notfall-Version Elements 23.3.4. Wer die Beschreibung liest, versteht, dass der Fix vom 3. August nur die halbe Miete war.

Der erste Patch hatte Asset-Generator und Ausgabeskript in den Cache-Schlüssel aufgenommen – aber sie schlicht aneinandergehängt. Genau daran hakt der zweite: Wenn man Felder ohne Trennung hintereinanderschreibt, können verschiedene Feldkombinationen dieselbe Bytefolge ergeben. AB + C sieht aus wie A + BC. Zwei unterschiedliche Prüfaufträge landen wieder unter demselben Schlüssel – dieselbe Kollision, nur eine Etage höher.

• Länge statt Aneinanderreihung – Der Cache-Schlüssel wird über CHashWriter gebildet. Jedes Feld wird mit seiner Länge vorangestellt geschrieben, dadurch ist die Zerlegung eindeutig und Feldgrenzen lassen sich nicht mehr verschieben.
• Auch der zweite Cache – Denselben Fehler hatte der Surjection-Proof-Cache – der Beweis, der belegt, dass ein Ausgang zu einem der Eingangs-Assets gehört. Beide bekommen jetzt eigene Domain-Trenner (r/s).
• -norangeproofcache – Neuer Startschalter, der den Range-Proof-Cache ganz abschaltet. Langsamer, aber ohne Neukompilieren betreibbar – ein Notausgang für Betreiber, die dem Cache vorerst nicht trauen.

Das ist die unbequemste Einzelheit dieses Vorfalls. Der Fix, auf dessen Grundlage die Angreifer die Coins zurückschickten – „Bridge nodes are patched" – hatte den Fehler nicht vollständig behoben, sondern nur den konkret ausgenutzten Weg verstellt. Dass ein zweiter Cache derselben Bauart danebenlag, fiel erst beim Aufräumen auf. Wer wissen will, warum Sicherheitsforscher auf Kollisionsfreiheit von Hash-Eingaben so penetrant bestehen: Hier stehen 4.000 BTC als Antwort.

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 ließ sich tagelang live beobachten: Blockstreams eigener Node stand auf Block 4.051.232 und hatte den umstrittenen Block 4.050.336 akzeptiert; der Node von mempool.space stand auf 4.050.335 und hatte ihn verworfen – exakt einen Block davor. Zwei ordentlich betriebene Nodes waren sich nicht mehr einig, welche Transaktionen es gegeben hat. Dazwischen lag ab dem 7. September, 04:49 UTC, ein kompletter Stillstand: Liquid produziert normalerweise jede Minute einen Block, gut zweieinhalb Tage lang produzierte es gar keinen.

Der Riss ist geschlossen#

Am 9. September, 21:05 UTC, ist die Kette wieder angelaufen – und zwar so, wie der Incident Report es angekündigt hatte. Ich habe es am 10. September nachgeprüft:

• Beide Nodes wieder einig – blockstream.info und liquid.network melden denselben Tip: Block 4.051.715 mit identischem Blockhash (e50bbe29…), Zeitstempel 10. September, 20:22 UTC. Die Kettenspaltung ist damit beendet.
• Der Exploit-Block ist raus – Auf Höhe 4.050.336 sitzt heute ein anderer Block: Hash d4eeaa11…, Zeitstempel 9. September, 21:05 UTC statt 6. September, 13:53 UTC. Die Kette wurde ab 4.050.335 neu gebaut, der ungültige Peg-out ist verworfen.
• 4.229,33 L-BTC im Umlauf – Die Peg-Bilanz stimmt auf beiden Nodes wieder überein: 18.382,15 BTC eingezahlt, 14.142,80 ausgezahlt, 10,03 verbrannt. Peg-ins und Peg-outs laufen wieder.

Auf der Sidechain ist die Geschichte damit korrigiert: Die L-BTC der ehrlichen Halter existieren wieder, das erfundene Geld ist aus der Buchführung verschwunden, als hätte es den 6. September nicht gegeben.

Auf der Bitcoin-Hauptkette hat sich nichts korrigiert. Die 3.996 BTC sind dort regulär ausgezahlt worden, 3.400 kamen freiwillig zurück, 598,50 BTC liegen weiterhin auf der Adresse der Angreifer – ich habe sie am 10. September erneut abgefragt, unbewegt bis auf ein paar Satoshi Werbemüll, den Fremde dorthin schicken.

Genau daran sieht man den Unterschied zwischen den beiden Schichten, und er ist selten so sauber zu besichtigen gewesen wie in diesen vier Tagen. Auf Liquid kann ein Zusammenschluss benannter Unternehmen die Geschichte per Beschluss zurückdrehen – zweieinhalb Tage Stillstand, ein Beschluss, ein Block weniger. Auf Bitcoin kann das niemand. Deshalb ist die Lücke, die dort gerissen wurde, immer noch offen und bleibt es, bis jemand sie freiwillig schließt.

Beide Eigenschaften sind dieselbe Eigenschaft:

Es wäre zu einfach, den Neustart als Beweis für Liquids Stärke zu lesen („seht, es ist ja repariert") oder als Beweis für seine Schwäche („seht, sie schreiben die Geschichte um"). Es ist beides, und zwar notwendig. Eine Kette, die korrigiert werden kann, wird korrigiert – von denen, die sie korrigieren dürfen, nach deren Maßstab. Eine Kette, die nicht korrigiert werden kann, bleibt beschädigt. Du musst dich nicht entscheiden, was besser klingt. Du musst dich entscheiden, welche der beiden Eigenschaften du für deine Ersparnisse willst.

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.

Ich hatte 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 die umlaufende L-BTC-Menge der Reserve auf der Bitcoin-Hauptkette gegenüberstellt. Seit dem Neustart ist das einfacher geworden, weil beide Nodes wieder dieselbe Bilanz melden. Stand 10. September:

• 4.229,33 L-BTC im Umlauf – Aus der Peg-Bilanz der wiederhergestellten Kette, auf beiden Explorern identisch. Der Anstieg gegenüber den 4.205,02 vom 9. September sind neue Einzahlungen seit dem Neustart.
• 3.601,47 BTC auf der Hauptadresse – Kontostand der Föderationsadresse bc1qdlld6a… auf der Bitcoin-Hauptkette, seit der Rückgabe praktisch unverändert. Von mir am 10. September erneut abgefragt.
• Rund 85 % Deckung – Es fehlen 627,85 BTC. Rund 25 davon sind frische Einzahlungen, die noch auf ihren Peg-in-Adressen liegen; bleiben gut 602 BTC echte Lücke – praktisch genau die 598,50, die die Angreifer halten.

Wer heute L-BTC hält, hält damit einen Anspruch, der zu gut fünf Sechsteln gedeckt ist. Das ist ungleich besser als die 4,7 % vom 7. September – und es ist immer noch kein 1:1-Peg. Daran hat der Neustart nichts geändert: Auf der Sidechain sind die Guthaben wieder da, das Bitcoin dahinter ist es nicht. Ob aus dem Rest ein realer Verlust wird, hängt an einer einzigen Frage: ob die letzten 598,50 BTC zurückkommen.

Wie ich auf die Zahlen komme:

Die Reserve ist der Kontostand der Föderationsadresse bc1qdlld6a… auf der Bitcoin-Hauptkette: 3.601,47203772 BTC, direkt über die mempool.space-API abgefragt. Davon kamen 3.400,0 BTC aus der Rückgabe, der Rest ist der alte Restbestand. Die umlaufende L-BTC-Menge kommt aus der Peg-Bilanz der wiederhergestellten Kette: 18.382,15146804 BTC eingezahlt, 14.142,79739199 ausgezahlt, 10,02779324 verbrannt – bleiben 4.229,32628281 L-BTC. Daraus ergeben sich 85,15 %. Eine Einschränkung, die ich offenlege: Diese eine Adresse ist nicht die vollständige Reserve. Einzahlungen landen bei Liquid zunächst auf abgeleiteten Peg-in-Adressen und werden erst später auf die Hauptadresse zusammengeführt. Seit dem Neustart sind gut 25 BTC eingezahlt worden, die auf bc1qdlld6a… noch nicht angekommen sind – die 85,15 % sind deshalb eine Untergrenze, die echte Deckung liegt ein wenig darüber. Ich nenne die Zahl trotzdem, weil sie die einzige ist, die sich von außen prüfen lässt, und weil die Lücke nach dieser Bereinigung fast exakt auf die einbehaltenen 598,50 BTC hinausläuft. Diese Vorsicht ist übrigens die Lehre aus dem Fehler, der in diesem Abschnitt steht.

Was ich daraus mitnehme:

Ich habe in der ersten Fassung die richtige Zahl abgefragt und die falsche Schlussfolgerung gezogen – weil ich die Buchhaltung des betroffenen Systems als unabhängigen Beleg behandelt habe. 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. Ich habe 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. Ich habe 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 mir verifiziert.
• 7.9., 12:43 UTC · Rückversicherung – „plz confirm again that we are sending the coins back to bc1qdlld6a…“ – die Angreifer lassen sich die Zieladresse ein zweites Mal bestätigen und legen verschlüsselte Details zum Fix bei.
• 7.9., 16:09 UTC · 3.400,0 BTC gehen zurück – Eine Transaktion, eine glatte Zahl, Bitcoin-Block 965.950. Der Rest von 598,50 BTC bleibt als Wechselgeld auf der Adresse der Angreifer liegen.
• 7.9., 17:54 UTC · Blockstream macht dicht – Ab jetzt sind Blockstreams Nachrichten zwar weiter PGP-signiert, ihr Inhalt aber an den Schlüssel der Angreifer verschlüsselt. Mitlesen geht nicht mehr, Echtheit prüfen schon.
• 7.9., 21:03 UTC · „:(“ – Die gesamte Antwort der Angreifer auf die erste verschlüsselte Nachricht. Zwei Zeichen, die alles über den Verlauf des Gesprächs sagen.
• 8.9., 14:25 UTC · „All messages will be in plaintext.“ – Die Angreifer kündigen an, die Vertraulichkeit aufzugeben – und damit, das Publikum als Druckmittel zu benutzen.
• 9.9., 11:45 UTC · Die Forderung – „You SHALL pay 10% using your own money as bug bounty or you will cause all your holders a 15% loss.“ Dazu die Ankündigung, den Schlüssel zu veröffentlichen, mit dem sich der verschlüsselte Teil des Gesprächs entziffern lässt.

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

Ich habe Blockstreams öffentlichen Sicherheitsschlüssel von blockstream.com/pgp.txt geladen und die signierten Nachrichten lokal mit GnuPG verifiziert – die alten wie die neueste vom 9. September, 08:31:53 UTC. Ergebnis in jedem Fall: gültige Signatur des Schlüssels mit dem Fingerabdruck 1176 542D A98E 71E1 3372 2EF7 4AC8 CC88 6844 A2D6, ausgestellt auf „Blockstream Security Reporting". Das beweist nicht, dass der Deal hält – aber es beweist, dass wirklich Blockstream schreibt, und dass beide Seiten bis heute miteinander reden.

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" war eine Behauptung – jetzt ist sie widerlegt#

In der Vorfassung stand hier, „Whitehat" sei eine Behauptung und kein Ausweis, und der einzige Test sei eine Transaktion. Der Test ist gelaufen. Er ist zu 85 % bestanden und in dem Teil durchgefallen, auf den es ankommt.

Die Nachricht vom 9. September beendet die Frage. Wer erst nimmt, dann 15 % einbehält und anschließend weitere 10 % aus dem Vermögen des Betroffenen fordert, damit die Halter nicht auf ihrem Schaden sitzen bleiben, betreibt keine Sicherheitsforschung. Er benutzt fremdes Geld als Hebel gegen dessen Eigentümer. Dass die Begründung stimmt – ein Unternehmen, das Milliardenwerte verwahrt, sollte deutlich mehr als 1,5 Millionen Dollar in Sicherheit stecken – ändert daran nichts. Eine zutreffende Kritik wird nicht dadurch zur Dienstleistung, dass man sie mit Geiseln vorträgt.

Das Muster ist seit Jahren Standardrepertoire: 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 ihren „Bounty"-Anteil verhandelt. Neu ist hier nur die Offenheit: Diesmal steht die Forderung im Klartext in der Bitcoin-Blockchain, samt der Ankündigung, den bislang verschlüsselten Teil des Gesprächs nachträglich zu veröffentlichen.

Wer den Preis festgelegt hat:

Niemand hat 15 % vereinbart. Es gibt keine Bounty-Zusage, kein Programm mit dieser Deckelung, keine Erklärung der Föderation, die diesen Betrag anerkennt. Die Angreifer haben die Summe bestimmt, indem sie sie einfach behielten – und verlangen die Bestätigung nachträglich. Genau das ist der Unterschied zwischen einer Belohnung und einer Wegnahme: Über eine Belohnung entscheidet der, der zahlt.

Für die Angreifer spricht weiterhin, dass die Coins bis heute nicht bewegt, nicht gemischt und nicht über Tauschdienste geschickt wurden – ich habe die Adresse am 9. September erneut geprüft, sie ist unangetastet. Das hält den Weg zu einer vollständigen Rückgabe offen. Es macht aus den vergangenen drei Tagen aber keine Rettungsaktion, sondern belegt nur, dass eine Entscheidung noch nicht gefallen ist.

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 Sidechain 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, habe ich 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.
• 7.9.2026 · 3.400 BTC kommen zurück – Nach dem Patch der Bridge-Nodes fließen 85 % zurück. Um 04:49 UTC hört Liquid auf, Blöcke zu produzieren.
• 9.9.2026 · Aus dem Angebot wird eine Forderung – Elements 23.3.4 erscheint mit dem zweiten, gründlicheren Fix. Wenige Stunden später verlangen die Angreifer 10 % zusätzlich – oder die Halter tragen den Schaden.
• 9.9.2026, 21:05 · Liquid läuft wieder – Nach knapp zweieinhalb Tagen Stillstand startet die Kette neu – ohne den Exploit-Block. Beide Explorer sind sich wieder einig. Die 598,50 BTC auf der Hauptkette bleiben, wo sie sind.

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

Seit dem 9. September, 21:05 UTC, läuft die Kette wieder, Peg-ins und Peg-outs funktionieren; einzelne Börsen haben ihre L-BTC-Ein- und -Auszahlungen aber noch nicht wieder freigegeben. Jetzt gilt: Wer Panik-Angebote unter Marktwert annimmt, verkauft womöglich zum Bruchteil eines Anspruchs, der zu rund 85 % gedeckt ist und später vollständig bedient werden könnte. Wer wartet, trägt das Risiko, dass die letzten 598,50 BTC nie zurückkommen. Beides ist eine echte Entscheidung, keine Formsache.

3. Die Wiederaufnahme genau lesen

Die Föderation hat die Kette am 9. September auf den Stand vor dem Exploit zurückgesetzt. Für ehrliche Halter heißt das: Der L-BTC-Bestand steht wieder da, wo er am 6. September stand. Das ist eine Buchungskorrektur auf der Sidechain, keine Rückkehr des Bitcoins auf der Hauptkette. Prüfe deshalb nicht nur deinen Wallet-Saldo, sondern die Reserve-Adresse – der Saldo zeigt den Anspruch, die Adresse zeigt die Deckung. Dass der Saldo wieder stimmt, ist das schwächere der beiden Signale.

4. 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.

5. Auf einen verifizierbaren Reserve-Nachweis bestehen

Ein Incident Report auf X 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 Wiederaufnahme. Nach 2020 hat Blockstream so etwas schon einmal geliefert – das ist ein realistischer Maßstab. Und wenn die 598,50 BTC ausbleiben: eine klare Aussage, wer die Lücke trägt.

6. Danach die Grundsatzfrage stellen

Nicht „ist Liquid sicher?", sondern: Wofür brauche ich diese Sidechain ü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.

Und noch etwas ist an diesen drei Tagen deutlich geworden. Die 85 %, die zurückkamen, kamen nicht durch Technik zurück, nicht durch Recht und nicht durch eine Versicherung. Sie kamen zurück, weil jemand sie zurückschicken wollte. Über die restlichen 15 % entscheidet dieselbe Instanz: die Laune eines Unbekannten. Wer das für eine Rettung hält, verwechselt Glück mit einem Sicherheitsmodell. Selbstverwahrung ist genau der Zustand, in dem diese Frage gar nicht erst gestellt werden muss.

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 – und wie viel kam zurück? SideSwap zufolge zahlte die Föderation am 6. September um 14:28 UTC 3.996 BTC aus. Am 7. September um 16:09 UTC gingen davon 3.400,0 BTC an die Föderationsadresse zurück. Auf der Adresse der Angreifer liegen weiterhin 598,50017761 BTC – beim Kurs vom 9. September (rund 79.100 US-Dollar) etwa 47 Millionen Dollar oder 41 Millionen Euro.

Sind die verbliebenen L-BTC gedeckt? Nicht vollständig. Rund 4.229 L-BTC stehen 3.601,47 BTC auf der Reserve-Hauptadresse gegenüber – eine Deckung von 85,15 %, und das ist eine Untergrenze: Frische Einzahlungen liegen noch auf ihren Peg-in-Adressen. Rechnet man sie heraus, bleibt eine Lücke von gut 602 BTC – praktisch genau die Summe, die die Angreifer einbehalten haben.

Behalten die Angreifer die 598,5 BTC? Offen. Sie beanspruchen den Betrag als Bounty, und niemand hat ihnen das zugesagt. Am 9. September haben sie zusätzlich verlangt, Blockstream solle 10 % aus eigenem Vermögen zahlen, sonst blieben die Halter auf 15 % Verlust sitzen. Die Coins sind bis heute unbewegt – der Weg zurück ist also offen, aber nichts daran ist verbindlich.

Ist das noch ein Whitehat-Vorgang? Nein. Ein Sicherheitsforscher meldet einen Fehler vor dem Abfluss und überlässt die Höhe einer Belohnung dem Betreiber. Hier wurde erst genommen, dann einbehalten und schließlich Geld gefordert, um Schaden von Dritten abzuwenden. Das ist Erpressung, auch wenn 85 % zurückgekommen sind.

Läuft Liquid wieder? Ja. Nach knapp zweieinhalb Tagen Stillstand (7. September, 04:49 UTC bis 9. September, 21:05 UTC) produziert die Kette wieder Blöcke, und beide großen Explorer melden wieder denselben Block – die Spaltung ist beendet. Auf Höhe 4.050.336 sitzt heute ein anderer Block als am 6. September: Der Exploit-Block wurde verworfen, der ungültige Peg-out existiert auf der Sidechain nicht mehr. Voraussetzung war das Update aller Functionaries auf Elements 23.3.4 (erschienen am 9. September, 03:14 UTC).

Sind meine L-BTC nach dem Neustart wieder da? Auf der Sidechain ja: Der Stand der ehrlichen Halter wurde wiederhergestellt, als hätte es den 6. September nicht gegeben. Das Bitcoin dahinter ist damit nicht zurückgekommen. Der Saldo in deiner Wallet zeigt den Anspruch, nicht die Deckung – und die liegt weiter bei rund 85 %, solange die 598,50 BTC bei den Angreifern liegen.

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? Am 8. September, 19:10 UTC, ist über den Liquid-Kanal auf X ein Incident Report erschienen: Ursache, Zeitpunkt, Patch-Zeiten, angekündigte Notfallversion und Wiederanlaufplan. Ein ausführliches Post-Mortem im Firmenblog steht weiter aus, dort ist der letzte Beitrag vom 28. August. Die inhaltliche Kommunikation mit den Angreifern läuft PGP-signiert über OP_RETURN-Nachrichten in der Bitcoin-Blockchain – seit dem 7. September, 17:54 UTC, ist ihr Inhalt zusätzlich verschlüsselt.

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: 10. September 2026, 21:30 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.

Offenlegung: Der Verfasser hat am 22. Juli 2026 einen Artikel über die Risiken der Liquid-Sidechain veröffentlicht und ihn eine Woche später selbst zurückgezogen. Er steht seit dem 10. September unverändert wieder online: Warum ich mich in Liquid getäuscht habe.

Quellen und eigene Prüfung: Ich habe am 7., 9. und 10. September 2026 selbst nachgeprüft und nicht aus Meldungen übernommen: die Kontostände der Angreifer-Adresse bc1ql4mfu6aundtkksxklfajs2h3t9nzcd6gyqjlte (am 10. September 598,50044115 BTC – der Zuwachs gegenüber dem 9. September sind ein paar Satoshi Werbemüll von Fremden) und der Föderations-Reserve bc1qdlld6antmv4xug242ed83q7k4rqw50cwfns38szx4qu2f4jwaxxsuhwxxr (3.601,47203772 BTC) über die mempool.space-API; die Rückgabe-Transaktion a6d697a25266ce3c78774fd1d75f896b7af522ada209b0f6228ea497bc49a46d in Bitcoin-Block 965.950 mit exakt 3.400,0 BTC an die Föderation; sämtliche OP_RETURN-Nachrichten des Schlagabtauschs bis zur Forderung vom 9. September, 11:45 UTC; die Gültigkeit der PGP-Signaturen von security@blockstream.com mit GnuPG gegen den unter blockstream.com/pgp.txt veröffentlichten Schlüssel, zuletzt für die Nachricht vom 9. September, 08:31:53 UTC; die umlaufende L-BTC-Menge auf beiden Ketten sowie – am 10. September – den wiederhergestellten Kettenzustand: identischer Tip-Hash e50bbe29… auf Höhe 4.051.715 bei blockstream.info und liquid.network (10. September, 20:22 UTC), der ausgetauschte Block auf Höhe 4.050.336 (d4eeaa11…, Zeitstempel 9. September, 21:05:10 UTC) und die auf beiden Nodes wieder deckungsgleiche Peg-Bilanz des L-BTC-Assets; den Zeitstempel des Exploit-Blocks 4.050.336 (6. September, 13:53:10 UTC – der Incident Report nennt dieselbe Uhrzeit in mitteleuropäischer Sommerzeit); sowie Commit 212c43f4, die Pull Requests #1599 und #1600 und das Release elements-23.3.4 (9. September, 03:14 UTC) über die GitHub-API des Elements-Repositorys. Offizielle Darstellung: Incident Report des Liquid-Kanals auf X vom 8. September, 19:10 UTC. Ergänzende Berichterstattung: news.bitcoin.com, The Hacker News, TRM Labs, Blocktrainer. 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.