Dieses Update sollte man so schnell wie möglich installieren, denn die Bitcoins sind nicht sicher: Ein Konsens-Fehler in der Lightning-Software LND führt dazu, dass diese keine aktuellen Blöcke mehr synchronisiert. Jedem, der mit LND Lightning-Channels betreibt, drohen Verluste.
Es sieht aus wie eine ganz normale Transaktion, die Geld von der einen zur anderen Adresse überweist. Das einzige augenfällig Besondere ist ein OP_Return-Feld, in dem eine Nachricht untergebracht ist. Aber auch das istg eigentlich nicht bemerkenswert.
Dennoch hat diese eine Transaktion, die in Block 761.249 verbucht wurde, in den letzten Tagen für viel Aufregung und auch ein wenig Ärger gesorgt. Um Auffälligkeiten zu entdecken, muss man die Input-Skripte genauer anschauen. In ihnen findet man eine nahezu unendlich lange Liste an leeren Witness-Einträgen. Und genau dies hat offenbar den beliebten Lightning-Node LND zum Absturz gebracht.
„Bitcoin hat die Konsens-Regel, dass die Anzahl an Stack-Items in einer Reihe auf 1.000 begrenzt ist,“ schreibt der Urheber der Transaktion in einer Meldung im btcd-Repository, „Allerdings geht eine P2TR-Ausgabe, die OP_SUCCESSx enthält, dieser Regel vorher. Ich bildete nun eine P2TR-Ausgabe, die einen OP_SUCCESSx-Opcode mit 500,001 leeren Pushes enthielt. Das Ergebnis war ein Konsens-Konflikt zwischen btcd und Core.“
Ihr versteht … vermutlich eher wenig. Versuchen wir, das Ganze aufzubröseln:
btcd ist eine Bitcoin-Node-Software, die in der Programmiersprache Go geschrieben wurde. Sie ist die einzige gängige Alternative zu den C++-Nodes Core und Knots. btcd steht in enger Verbindung mit LND, der Lightning-Software von Lightning Labs, und läuft selbst dann im Hintergrund mit, wenn LND auf Basis von Core operiert.
Die besagte Transaktion beinhaltete einige sehr spezielle Inputs. Soweit ich sehe, wurde dies erst durch die neuen Transaktionsformate möglich, die das Taproot-Upgrade eingeführt hatte. In jedem Fall führten sie dazu, dass es einen Konsens-Konflikt zwischen btcd und Core gab: Die beiden Nodes verloren ihre Übereinstimmung über die Gültigkeit vergangener Ereignisse. Sie widersprachen sich. btcd lehnte den Block 761.249 ab, weil darin eine als ungültig wahrgenommene Transaktion steckt. Core hingegen akzeptiert den Block.
Da Bitcoin Core nun mit himmelweitem Abstand wichtiger ist als btcd, hat Core die Definitionsmacht über die Wirklichkeit. Wenn btcd nicht zustimmt, ist das keine abweichende Meinung, sondern ein Irrtum. Es gibt bei Bitcoin kein false balancing. Es gibt nur Wahrheit und Irrtum. btcd schert aus dem Konsens aus – und damit aus Bitcoin.
Die Folge: Die Lightning-Nodes mit LND konnten die Blockchain nicht länger synchronisieren. Sie ging von einem nicht mehr aktuellen Zustand der Blockchain aus.
Das wäre an sich nicht so tragisch. Aber wer nun weiß, wie Lightning funktioniert, mit den Payment-Channels und deren Vernetzung, der ahnt bereits, wie ungünstig dies ist: Denn wenn jemand nicht den aktuellen Zustand der Blockchain kennt, bekommt er nichts davon mit, wenn seine Payment-Channels geschlossen werden, und dies macht es für ihn unmöglich, auf eine regelwidrige Schließung der Channels mit der üblichen Sanktion zu reagieren.
Kurzum: Jeder, der einen LND-Node betreibt, muss fürchten, dass ihm jemand Geld stiehlt. Daher ist es fundamental wichtig, das erst gestern veröffentlichte Update, das den Bug fixt, so rasch wie möglich einzuspielen. Egal was ihr macht – das Update dürfte wichtiger sein.
Den Entwicklern von LND gereicht dieser Bug nicht eben als Ruhmesblatt. Schlimmer noch ist, dass es nicht zum ersten Mal vorkommt. Gregory Maxwell, ein niemals um scharfzüngige Analysen verlegener Bitcoin-Experte, kommentiert:
„Ich denke, das ist etwa das 5. Mal, dass btcd aus dem Konsens ausschert, weil es verschiedene Konsens-Limits duplikativ implementiert, als Teil der De-Serialisierung des Codes, und es dann nicht ganz richtig hinbekommt.“ BTCD übersetzt den Code aus Bitcoin Core, macht dabei aber einen kleinen Fehler. Maxwell erinnert daran, dass er vor dieser Vorgehendsweise schon beim ersten Fehler gewarnt habe.
Aus dem Grund steht in der OP_Return-Nachricht auch das folgende: „You’ll run CLN, and you will be happy.“ Du wirst C-Lightning (als Node) verwenden (anstatt LND), und du wirst glücklich werden. C-Lightning ist der in C geschriebene Lightning-Node von Blockstream, der rein auf Bitcoin Core aufbaut.
Wenn der eigene Node den Konsens verliert, ist das ärgerlich, aber nicht grundsätzlich gefährlich. Im Normalfall bekommt man lediglich keine neuen Blöcke mehr, was ziemlich rasch auffällt und nur verhindert, dass man neue Transaktionen sieht. Erst eine Konstruktion wie Lightning macht den Verlust des Konsens so gefährlich, da man die aktuellen Blockdaten braucht, um zu verhindern, dass man betrogen wird. Lightning führt keine grundsätzlich unbekannten Probleme ein – macht sie aber sehr viel gefährlicher.
Unter normalen Umständen könnte man einen solchen Bug, sobald er bekannt wurde, reparieren. Der nun getriggerte Bug war seit Wochen bekannt, wurde aber nocht nicht repariert. Denn in jedem Bugfix liegt auch eine Gefahr: Er ist ein öffentliches Eingeständnis, dass ein Bug existiert, und er führt jedem, der versteht, den Code zu lesen, vor Augen, wo und wie der Bug zu finden ist. Ein Bugfix ist quasi eine Anleitung, den Bug auszunutzen; sobald er veröffentlicht ist, steigt die Gefahr, dass dies geschieht, enorm. Was unter normalen Umständen ein tolerierbares Risiko darstellt, ist in einer Konstruktion wie Lightning, wo ein Konsens-Fehler prinzipiell zu Verlusten führen kann, eine brandgefährliche Operation.
sipa is spot on here, since the only way to exploit was w/ a non-std transaction (since the transaction would be > 10% of the max block size), my plan was to fix in a small release to avoid another flag day
however, I didn’t imagine someone would work w/ miners to mine it https://t.co/1SiFPGN1c2
— Olaoluwa Osuntokun (@roasbeef) November 1, 2022
Man möchte nicht in der Haut derer stecken, die für die Software verantwortlich sind. Ihr Zögern, den Bug zu reparieren, ist verständlich. Nachdem der Bug getriggert war, war es aber nicht mehr zu rechtfertigen. So hat der Angreifer also mit einer Onchain-Transaktion ein Update erzwungen.
