Learning From The LND Bug On Lightning – Bitcoin Magazine

Learning From The LND Bug On Lightning – Bitcoin Magazine

Dies ist eine redaktionelle Meinung von Shinobi, einem autodidaktischen Pädagogen im Bitcoin-Bereich und technisch orientierten Bitcoin-Podcast-Host.

Am 9. Oktober 2022 erstellte Burak von Bitmatrix (ein auf dem Liquid Network basierendes Swap-Tool) eine Transaktion und sendete sie an das Haupt-Bitcoin-Netzwerk, wobei er einen UTXO mit einem Tapscript-Multisig mit einem Schwellenwert von 998 von 999 ausgab. Diese Transaktion hatte 998 einzelne Unterschriften im Zeugenfeld und war fast 0,1 MB groß und nutzte komischerweise genau denselben öffentlichen Schlüssel für jeden der 999 Teilnehmer an der Multisig. Diese Transaktion verursachte eine massive Unterbrechung des Lightning-Netzwerks, indem sie einen Fehler in LND und btcd (einem alternativen Client für das Bitcoin-Netzwerk) aufdeckte.

Der gesamte Zweck dieser Transaktion bestand darin, die verbesserte Skalierbarkeit von Multisignatur-Skripten zu demonstrieren, die Taproot ermöglicht hat. Auch ohne die Verwendung von Schnorr-Signatur-basierten MuSig-Protokollen kann Taproot viel größere Multisig-Teilnehmergruppen ermöglichen als frühere Versionen von Bitcoin Script. Dies kann eine etwas nuancierte Diskussion in Bezug auf die vorherige Größenbeschränkung von Multisig sein, wenn Sie sich mit allen möglichen Möglichkeiten befassen, wie Sie Multisig mit Bitcoin Script erstellen können. Der Einfachheit halber werde ich einfach die vorherigen Beschränkungen diskutieren zu Pay-to-script-hash (P2SH) und Pay-to-witness-script-hash (P2WSH) Multisig-Konstruktionen. Wenn es um die Standardmethode für eine P2SH-Multisig geht, beträgt die maximale Größe der Teilnehmer nur 15, und im Fall der Standard-P2WSH-Multisig beträgt die maximale Größe 20. Diese Beschränkungen hängen davon ab, wie groß ein Skript sein darf diese verschiedenen Skriptoperationen verwenden, und Einschränkungen, wie viele Verarbeitungsvorgänge im Rahmen eines einzelnen Skripts durchgeführt werden dürfen. Die Verletzung eines dieser Limits macht eine Transaktion ungültig.

Mit der Implementierung von Taproot wurden diese Skriptgrößenbeschränkungen vollständig entfernt, was bedeutet, dass die einzigen Beschränkungen bei der Taproot-Skriptgröße die Blockgrößenbeschränkung selbst sind. Hier kommt das Problem in Bezug auf LND und btcd ins Spiel. Die in btcd implementierten Konsensregeln haben diese Beschränkungen in Bezug auf die Skriptgröße korrekt aufgehoben, aber das Problem ist, dass die Codebasis für die Peer-to-Peer-Kommunikation auch Überprüfungen der Skriptgröße implementiert hat, um eine doppelte Verteidigungsebene für Knotenbetreiber hinzuzufügen. Blöcke und Transaktionen würden eine Art Konsensvalidierung vor dem Konsens durchlaufen, bevor sie überhaupt zum Kernkonsenscode gelangen, der eine ordnungsgemäße Validierung durchführt, wobei die Logik darin besteht, dass doppelte Überprüfungen zusätzliche Verteidigungsebenen gegen ungültige Blöcke oder Transaktionen hinzufügen. Dieser Code wurde nicht ordnungsgemäß aktualisiert, um die Skriptgrößenbeschränkungen zu entfernen und weiterhin frühere Skriptbeschränkungen für SegWit gegen Taproot-Transaktionen durchzusetzen. Während also der eigentliche Konsenscode selbst diese sehr große Taproot-Transaktion ordnungsgemäß validiert hätte, wurde der Block, der sie enthält, nie wirklich von der Peer-to-Peer-Validierung in die eigentliche Konsensvalidierungslogik übergeben, was bedeutet, dass alle btcd-Knoten bei dem Block einschließlich blockiert wurden Buraks Transaktion.

Warum wirkte sich dies auf LND aus, da viele Leute Bitcoin Core unter ihrer LND-Instanz ausführen? Dies liegt daran, dass LND denselben Code verwendet, den btcd verwendet, um Blöcke zu empfangen und zu verarbeiten. Selbst wenn Ihr LND-Knoten auf Bitcoin Core ausgeführt wurde, was den relevanten Block ordnungsgemäß validiert und nicht angehalten hätte, hätte sich Ihre LND-Instanz geweigert, diesen Block zu akzeptieren, und angehalten, obwohl Ihr Hauptkettenknoten weiterhin ordnungsgemäß fortschritt.

Dieser Fehler wurde sehr schnell gepatcht und meines Wissens nicht aktiv auf eine Weise ausgenutzt, die zu Schaden führte, aber dies ließ jeden LND-Knoten im Lightning-Netzwerk für potenziellen Diebstahl von Geldern in Kanälen offen, es sei denn, sie verwendeten einen externen Wachturm. Da der Knoten an diesem Block blockiert war, hatte er keine Echtzeitansicht der Blockchain, und für den Fall, dass eine Kanalgegenpartei einen alten Kanalstatus an die Blockchain übermittelt hätte, wäre er sich dessen völlig nicht bewusst gewesen und nicht in der Lage gewesen, darauf zu reagieren mit der entsprechenden Straftransaktion, um das Geld des Benutzers zu sichern. Dies war ein sehr schwerwiegender Fehler, der einen massiven Prozentsatz der Bitcoin im Lightning-Netzwerk einem Diebstahlrisiko aussetzte, es sei denn, die Benutzer patchten und aktualisierten ihre Knoten selbst oder überwachten ihre Kanäle persönlich, um im Falle einer Schließung manuell reagieren zu können mit veraltetem Zustand. Ich muss sagen, dass die überwiegende Mehrheit der nicht-technischen Node-Betreiber wahrscheinlich nicht dazu in der Lage gewesen wäre.

Glücklicherweise wurde dieses Problem nicht weithin ausgenutzt, aber wäre dies in der Codebasis entdeckt worden, bevor Buraks Transaktion in die Blockchain verschoben wurde, hätte dies von schlechten Akteuren auf sehr taktische Weise absichtlich ausgenutzt werden können. Eine Einzelperson oder eine Gruppe von Personen hätte sehr einfach eine große Anzahl von Kanälen im Netzwerk eröffnen und das gesamte Geld in diesen Kanälen durch einen U-Boot-Swap auf sich selbst zurücktauschen können, wobei alle Gelder im Kanal verblieben wären auf der anderen Seite und reichte dann eine große Taproot-Transaktion ein, wie es Burak tat, und schloss ihre Kanäle sofort mit einem veralteten Zustand. Die Opfer wären sich dessen nicht einmal bewusst, und selbst wenn, wäre es angesichts der relativ geringen technischen Kompetenz vieler Node-Betreiber sehr wahrscheinlich, dass die meisten Menschen nicht rechtzeitig reagieren könnten, um das Problem manuell mit a zu beheben Strafgeschäft.

Dieser Fehler hebt zwei wichtige Punkte hervor, die es zu beachten gilt. Erstens können mehrere unabhängige Implementierungen von Bitcoin-Knoten sehr gefährlich sein. Zum Glück betreibt fast niemand btcd als Knoten für irgendetwas Ernsthaftes, so dass die Auswirkungen, die dies auf das Basis-Bitcoin-Netzwerk hatte, etwas waren, das völlig ignoriert werden konnte, mit Ausnahme einer sehr kleinen Handvoll Personen, deren Knoten einfach ins Stocken gerieten. Wenn Bergleute BTCd ausgeführt hätten, hätte dies sehr leicht zu einem Chainsplit im Bitcoin-Netzwerk führen können, der alle BTCD-Betreiber von einer Minderheitskette entfernt hätte, für deren Korrektur ein manuelles Eingreifen erforderlich gewesen wäre. Das zweite Problem ist, dass im Fall von zweiten Schichten über dem Hauptnetzwerk die Implementierung von Konsensprüfungen sehr sorgfältig durchgeführt werden sollte. Dies ist ein kniffliges Problem, denn während jeder Lightning-Knoten, der auf einem vollständigen Bitcoin-Knoten läuft, theoretisch einfach 100 % dieser Validierung an diesen Knoten auslagern könnte, verwenden nicht alle Lightning-Knoten ihren eigenen vertrauenswürdigen vollständigen Knoten. Das wird sich wahrscheinlich nicht ändern – viele Benutzer werden Knoten aller Voraussicht nach weiterhin auf diese Weise betreiben, sodass die Überprüfung einiger oder aller Bitcoin-Konsensregeln bis zu einem gewissen Grad auch in Lightning-Implementierungen unterstützt werden muss.

Für die Zukunft hoffe ich, dass dies ein Weckruf dafür ist, wie wichtig es ist, sicherzustellen, dass Konsensvalidierungsprüfungen in allen Softwarebereichen in diesem Bereich synchron sind, da es ohne diese Synchronität zwischen allem keinen einzigen kohärenten Bitcoin gibt Netzwerk. Jeder sollte sehr froh sein, dass dies nicht zu einem massiven Exploit im gesamten Netzwerk geführt hat, aber die Leute sollten sich bewusst sein, wie ernst dieses Problem hätte sein können, wenn die Dinge nicht so abgelaufen wären, wie sie es taten.

Dies ist ein Gastbeitrag von Shinobi. Die geäußerten Meinungen sind ausschließlich ihre eigenen und spiegeln nicht unbedingt die von BTC Inc oder Bitcoin Magazine wider.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert