Heute Nacht kam es zu einem Fehler in Teilen des Lightning-Netzwerks (LN), genauer gesagt dem LND-Client, der am weitesten verbreiteten Implementierung des LN. Schuld war eine besondere Taproot-Transaktion, die den Fehler zum Vorschein brachte. Dies zwingt LND-Nodes nun zu einem Update, welches einen Hotfix für das entstandene Problem beinhaltet. Aktuell bestehende Zahlungskanäle waren von dem Problem nicht betroffen, sondern lediglich die Settlement-Transaktionen.
Was war geschehen?
Der Auslöser war eine besonders große Multisig-Transaktion, die in Kombination mit einer Maximalgröße in der LND/Btcd Taproot-Implementation zu dem Fehler führte.
Der Twitter-User "Burak" erzeugte in der gestrigen Nacht eine 998 aus 999 - MultiSig Transaktion mittels Tapscript (die neue Script-Sprache, die im Zuge des Taproot-Upgrades aktiviert wurde). Während er selbst sich noch darüber freute, dass diese ungewöhnliche Transaktion dank der neuen Funktionen insgesamt nur etwa 4,90 US-Dollar an Gebühren kostete, ahnte er noch nicht, welche Auswirkungen sie auf große Teile des Lightning-Netzwerks haben würde.
Denn bereits kurz nachdem die Transaktion in den Bitcoin-Block 757922 aufgenommen wurde, kam es im LND-Client zu einem Chain-Sync-Error und im Zuge dessen zu einer Diskussion im Github von LND, über die möglichen Gründe für den Fehler.
Während dem Github-User Richard J. Safier zunächst auffiel, dass es im Bitcoin-Testnetz zu dem Fehler kam, bemerkten einige bekannte Bitcoin-Entwickler, wie zum Beispiel benthecarman, schnell, dass auch das Mainnet davon betroffen war und der Fehler wohl in der Taproot Implementation von LND zu suchen sei und mit der maximalen Skriptgröße zusammen hänge.
"Es sieht so aus, als ob lnd/btcd einen Fehler in ihrer Taproot-Implementierung hat. In BIP342:
Skriptgrößenbegrenzung. Die maximale Skriptgröße von 10000 Bytes gilt nicht. Ihre Größe ist nur implizit durch die Blockgewichtsgrenze begrenzt [9].
Ich bin überrascht, dass dies bei den Tests nicht aufgefallen ist. Verwenden sie nicht die statischen Testvektoren?"
benthecarman
Relativ schnell konnte die betroffene Transaktion im Block ausfindig gemacht werden, was allerdings die Frage aufwarf, warum es auch im Testnetz zu Ausfällen kam, wenn es sich doch um eine Mainnet-Tx handelte. Auch hierauf war die Antwort allerdings schnell gefunden. Denn tatsächlich hatte Burak seine ungewöhnliche Transaktion zunächst auch im Testnetz gebroadcastet, bevor er sie in das Mainnet sendete.
Schnelle Fehlerbehebung
Dadurch, dass das LND-Team schnell auf den Auslöser des Fehlers aufmerksam gemacht wurde, konnte auch relativ zügig eine Lösung für das Problem gefunden und dieses somit behoben werden. Der bekannte Lightning-Entwickler Olaoluwa Osuntokun ("Roasbeef"), seines Zeichens der CTO bei Lightning Labs, erklärte:
"Hallo zusammen, vielen Dank, dass ihr uns auf dieses Problem aufmerksam gemacht habt. Ich habe das Problem, das zu diesem Vorfall führte, in der btcd Wire Parsing Bibliothek identifiziert.
Soweit ich das beurteilen kann, war nicht der Konsenscode das Problem, sondern die Wire Parsing Bibliothek, die fälschlicherweise immer noch eine frühere Prüfung zur Begrenzung der Witness-Größe durchsetzte, die von Segwit v0 übrig geblieben war."
Roasbeef
Da LND im Gegensatz zu anderen Implementierungen, wie z.B. Core-Lightning, die betroffene Bibliothek verwendet, um Blöcke zu parsen, die die Software aus dem Fullnode-Backend oder P2P Netzwerk erhält, waren auch nur LND-Nodes betroffen.
Bereits wenige Stunden später meldete Roasbeef via Twitter, die Veröffentlichung eines Hot-Fix Releases für LND (v0.15.2), in welchem der Fehler behoben wurde.
"Der Fix für die btcd wire parsing library kann hier gefunden werden: https://github.com/btcsuite/btcd/pull/1896
Diejenigen, die btcd-Knoten betreiben, können diesen Patch anwenden (ein offizielles Release ist in Vorbereitung) und die Nodes werden den Block wie erwartet akzeptieren, da es sich nicht um ein Konsensproblem handelt."
Roasbeef
Was Fullnode-Betreiber nun tun sollten
Die gängigen Fullnode-Softwares Umbrel, RaspiBlitz und Citadel, haben bereits Updates für die Fehlerbehebung bereitgestellt. Wer eine entsprechende LND-Fullnode betreibt, sollte sich alsbald darum kümmern, diese upzudaten.
Während dies bei Umbrel und Citadel einfach per Knopfdruck über die GUI möglich ist, hat der RaspiBlitz-Entwickler openoms via Twitter eine kurze Anleitung für das Update geteilt. Leute, die heute eigentlich ein Fullnode neu aufsetzen wollten, sollten noch etwas warten, bis auch die SD-Images entsprechend gefixt wurden und zum Download bereitstehen.
