Protokollentwickler wirken hinsichtlich der Zukunft von Bitcoin oft pessimistischer als die meisten Bitcoiner. Der tägliche Umgang mit den Unvollkommenheiten von Bitcoin prägt sicherlich eine nüchterne Sichtweise, und es ist wichtig, darüber nachzudenken, was Bitcoin erreicht hat. Jeder auf der Welt, unabhängig von Rasse, Alter, Geschlecht, Nationalität oder einem anderen willkürlichen Kriterium, ist heute in der Lage, Werte in einem neutralen Währungsnetzwerk zu speichern und zu übertragen, das robuster ist als je zuvor. Allerdings gibt es bei Bitcoin Probleme, die vielen Bitcoinern nicht bewusst sind, die jedoch seine langfristigen Aussichten gefährden könnten, wenn sie nicht richtig angegangen werden. Ein Beispiel dafür sind die durch das Consensus Cleanup behobenen Schwachstellen.
Die Konsensbereinigung (BIP 541) ist ein Soft-Fork-Vorschlag, der darauf abzielt, mehrere seit langem bestehende Schwachstellen im Bitcoin-Konsensprotokoll zu schließen. Da es sich um einen Soft-Fork-Vorschlag handelt, unterscheidet er sich von den meisten anderen in dieser Ausgabe vorgestellten Bitcoin-Core-Bemühungen. Obwohl der Vorschlag in der Vergangenheit von Personen befürwortet wurde, die mit dem Bitcoin Core-Projekt in Verbindung stehen, gehört er eigentlich zur breiteren Kategorie der Bitcoin-Protokollentwicklung.
Wir werden jeden der vier Punkte des Vorschlags durchgehen und die Auswirkungen des angesprochenen Problems und der durchgeführten Abhilfemaßnahmen beschreiben. Wir werden diskutieren, wie sich die vorgeschlagenen Abhilfemaßnahmen entwickelt haben, um Rückmeldungen und neu entdeckte Schwachstellen zu beheben. Abschließend geben wir einen kurzen Überblick über den aktuellen Stand des Soft-Fork-Vorschlags.
Das Bitcoin-Netzwerk passt die Mining-Schwierigkeit an, um eine durchschnittliche Blockrate von einem pro 10 Minuten aufrechtzuerhalten. Ein „Off by One“-Bug (ein häufiger Programmierfehler) in seiner Implementierung löst einen Angriff namens Timewarp-Angriff aus, bei dem die meisten Miner die Blockproduktionsrate künstlich beschleunigen können, indem sie den Schwierigkeitsgrad nach unten manipulieren.
Glücklicherweise erfordert dieser Angriff einen Schwellenwert von 51 %+ an Minern, aber die künstliche Beschleunigung der Blockrate ist ein kritisches Problem. Dies bedeutet, dass vollständige Knoten nicht mehr die Kontrolle über die Ressourcennutzung haben und dass ein Angreifer den Zeitplan für die Ausgabe von Bitcoin-Subventionen erheblich beschleunigen kann.
Auch wenn dafür ein „51 %-Miner“ erforderlich ist, handelt es sich um eine deutliche Abweichung vom Standard-Bitcoin-Bedrohungsmodell. Ein 51-Prozent-Angriff ermöglicht es einem Miner traditionell, die Bestätigung einer Transaktion zu verhindern, solange er seinen Vorteil behält. Aber das Vorhandensein dieses Fehlers gibt ihnen die Macht, das Netzwerk innerhalb von nur 38 Tagen lahmzulegen, indem die Netzwerkschwierigkeit schnell reduziert wird.
Anstatt das Netzwerk lahmzulegen, ist es wahrscheinlicher, dass ein Angreifer diesen Fehler in geringerem Umfang ausnutzt. Aktuelle Miner könnten sich koordinieren, um die Blockrate zu vervierfachen (auf 2,5-Minuten-Blöcke) und gleichzeitig das Bitcoin-Netzwerk in einem scheinbar funktionsfähigen Zustand zu halten, was den verfügbaren Blockplatz effektiv vervierfachen und zukünftigen Minern Blocksubventionen stehlen würde. Kurzsichtige Benutzer könnten einen Anreiz erhalten, diesen Angriff zu unterstützen, da mehr verfügbarer Blockplatz – ceteris paribus – niedrigere Gebühren für On-Chain-Transaktionen bedeuten würde. Dies würde natürlich zu Lasten von Full-Node-Runnern gehen und die langfristige Stabilität des Netzwerks untergraben.
Der Timewarp-Angriff nutzt die Tatsache aus, dass sich die Schwierigkeitsanpassungsperioden nicht überschneiden, sodass Blockzeitstempel so festgelegt werden können, dass eine neue Periode zu beginnen scheint, bevor die vorherige zu Ende ist. Da es eine harte Abspaltung wäre, sie zu überlappen, besteht die nächstbeste Abhilfe darin, die Zeitstempel der Blöcke an den Grenzen der Schwierigkeitsanpassungsperioden zu verknüpfen. Die BIP 54-Spezifikationen schreiben vor, dass der erste Block einer Periode keinen Zeitstempel haben darf, der um mehr als zwei Stunden vor dem letzten Block der vorherigen Periode liegt.
Darüber hinaus schreiben die BIP 54-Spezifikationen vor, dass eine Schwierigkeitsanpassungsperiode immer eine positive Zeitspanne in Anspruch nehmen muss. Das heißt, dass der letzte Block für einen bestimmten Schwierigkeitsanpassungszeitraum möglicherweise nie einen früheren Zeitstempel als der erste Block hat. Wundert es Sie, dass dies nicht bereits der Fall ist? Wir waren überrascht, dass es überhaupt notwendig war. Es stellt sich heraus, dass dies eine einfache Lösung für einen cleveren Angriff im Zusammenhang mit Timewarp ist, den sich die pseudonymen Entwickler Zawy und Mark „Murch“ Erhardt bei der Überprüfung des Consensus Cleanup-Vorschlags ausgedacht haben.
Jeder Miner kann bestimmte teure Validierungsvorgänge nutzen, um Blöcke zu erstellen, deren Überprüfung lange dauert. Während die Validierung eines normalen Bitcoin-Blocks in der Größenordnung von hundert Millisekunden dauert, reichen die Validierungszeiten für diese „Angriffsblöcke“ von mehr als zehn Minuten auf einem High-End-Computer bis zu bis zu zehn Stunden auf einem Raspberry Pi (eine beliebte Wahl für Full-Node-Hardware).
Ein von außen motivierter Angreifer kann dies ausnutzen, um das gesamte Netzwerk zu stören, während in einer wirtschaftlich rationaleren Variante des Angriffs ein Miner seine Konkurrenz gerade lange genug verzögern kann, um seine Gewinne zu steigern, ohne dass es zu einer weitreichenden Netzwerkunterbrechung kommt.
Historische Versuche, dieses Problem zu entschärfen, waren turbulent, da dazu Beschränkungen der Skriptfunktionen von Bitcoin erforderlich waren. Solche Einschränkungen können konfiszierend wirken, was bei jedem ernsthaften Soft-Fork-Design unbedingt vermieden werden muss.
Matt Corallos ursprüngliches Great Consensus Cleanup 2019 schlug vor, diese langen Blockvalidierungszeiten zu lösen, indem einige obskure Operationen in Nicht-Segwit-Skripten („Legacy-Skripten“) ungültig gemacht werden. Einige äußerten Bedenken, dass, obwohl Transaktionen, die diese Vorgänge nutzen, jahrelang nicht standardmäßig von Bitcoin Core weitergeleitet oder abgebaut wurden, irgendjemand irgendwo immer noch darauf angewiesen sein könnte, ohne dass es jeder weiß. Dies muss natürlich gegen das praktische Risiko abgewogen werden, dass ein Miner dieses Problem für alle Bitcoin-Benutzer ausnutzt.
Auch wenn das Problem der Beschlagnahmung eher theoretischer Natur ist, gibt es einen philosophischen Punkt bei der Entwicklung des Bitcoin-Protokolls, indem versucht wird, eine angemessene Abhilfe für die Schwachstelle mit der kleinstmöglichen Beschlagnahmungsfläche zu schaffen. Meine spätere Version des Consensus Cleanup-Vorschlags ging auf dieses Problem ein, indem ich einen Grenzwert einführte, der das schädliche Verhalten genau lokalisiert, ohne einen bestimmten Bitcoin-Skriptvorgang ungültig zu machen.
Bitcoin-Blockheader enthalten einen Merkle-Root, der alle Transaktionen im Block festschreibt. Dadurch ist es möglich, einen prägnanten Nachweis zu erbringen, dass eine bestimmte Transaktion Teil einer Kette mit einem bestimmten Umfang an Proof of Work ist. Dies wird allgemein als „SPV-Nachweis“ bezeichnet.
Aufgrund einer Schwachstelle im Design des Merkle-Baums ermöglicht die Aufnahme einer speziell gestalteten 64-Byte-Transaktion in einen Block einem Angreifer, einen solchen Beweis für eine willkürliche gefälschte (nicht existierende) Transaktion zu fälschen. Dies kann verwendet werden, um SPV-Verifizierer auszutricksen, die üblicherweise zur Validierung eingehender Zahlungen oder Einzahlungen in ein Nebensystem eingesetzt werden. Es gibt Abhilfemaßnahmen, die es Prüfern ermöglichen, solche ungültigen Beweise abzulehnen. Diese werden jedoch oft übersehen – selbst von Kryptographie-Experten – und können in bestimmten Kontexten umständlich sein.
Die Consensus Cleanup behebt dieses Problem, indem Transaktionen ungültig gemacht werden, deren serialisierte Größe genau 64 Byte beträgt. Solche Transaktionen können von vornherein nicht sicher sein (sie können immer nur Gelder verbrennen oder sie irgendjemandem zum Ausgeben überlassen) und werden von Bitcoin Core seit 2019 nicht standardmäßig weitergeleitet oder abgebaut. Es wurden alternative Ansätze diskutiert, beispielsweise ein Umweg zur Verbesserung der bestehenden SchadensbegrenzungAaber die Autoren entschieden sich dafür, die Grundursache des Problems zu beheben, wodurch sowohl die Notwendigkeit für die Implementierer entfällt, die Abhilfemaßnahmen anzuwenden, als auch die Notwendigkeit, dass sie überhaupt über die Schwachstelle Bescheid wissen.
A: Festlegen der Merkle-Baumtiefe in einem Teil des Versionsfelds des Blockheaders
„Mirco… Mezzo… Macroflation – Overheated Economy“ ist der Titel eines Blogbeitrags4 Russell O’Connor veröffentlichte im Februar 2012, in dem er beschreibt, wie Bitcoin-Transaktionen dupliziert werden können. Dies war ein kritischer Fehler bei Bitcoin, der die Grundannahme widerlegte, dass Transaktionskennungen (Hashes) eindeutig sind. Dies liegt daran, dass die Coinbase-Transaktionen der Miner eine einzige leere Eingabe haben, was bedeutet, dass jede Coinbase-Transaktion mit denselben Ausgaben eine identische Transaktionskennung haben würde.
Dies wurde von den Entwicklern von Bitcoin Core (damals noch „Bitcoin“ genannt) mit BIP 30 behoben2wodurch vollständige Knoten beim Empfang eines Blocks eine zusätzliche Validierung durchführen mussten. Diese zusätzliche Validierung war zur Lösung des Problems nicht unbedingt erforderlich und wurde mit BIP 34 umgangen3 im selben Jahr. Leider ist der in BIP 34 eingeführte Fix unvollständig und die zusätzliche Validierung von BIP 30 wird in 20 Jahren erneut erforderlich sein. Abgesehen davon, dass diese Validierung nicht unbedingt notwendig ist, kann diese Validierung auch nicht von alternativen Bitcoin-Client-Designs wie Utreexo durchgeführt werden und würde sie effektiv daran hindern, die Blockchain vollständig zu validieren.
Mit der Consensus Cleanup wird eine robustere und zukunftssicherere Lösung für das Problem eingeführt. Alle Bitcoin-Transaktionen, einschließlich der Coinbase-Transaktionen, enthalten ein Feld zur „Zeitsperre“ der Transaktion. Der Wert des Feldes stellt die letzte Blockhöhe dar, bei der eine Transaktion ungültig ist. Die BIP 54-Spezifikationen verlangen, dass alle Coinbase-Transaktionen dieses Feld auf die Höhe ihres Blocks (minus 1) setzen.
Kombiniert mit einem cleveren Vorschlag von Anthony Towns, sicherzustellen, dass die Timelock-Validierung immer stattfindet, garantiert dies, dass keine Coinbase-Transaktion mit demselben Timelock-Wert in einem vorherigen Block enthalten sein könnte. Dies wiederum garantiert, dass keine Coinbase-Transaktion dieselbe eindeutige Kennung (Hash) wie jede frühere haben kann, ohne dass eine BIP 30-Validierung erforderlich ist.
Die durch das Consensus Cleanup (BIP 54) behobenen Schwachstellen stellen derzeit keine existenzielle Bedrohung für Bitcoin dar. Während einige das Potenzial haben, das Netzwerk lahmzulegen, ist es unwahrscheinlich, dass sie vorerst ausgenutzt werden. Allerdings könnte sich dies ändern, und es ist von größter Bedeutung, dass wir langfristige Risiken für das Bitcoin-Netzwerk proaktiv mindern, auch wenn das bedeutet, dass wir kurzfristig die Last der Koordinierung einer Soft Fork tragen müssen.
Die Arbeit an der Consensus Cleanup begann mit Matt Corallos ursprünglichem Vorschlag im Jahr 2019. Sie kam sechs Jahre später mit meiner Veröffentlichung von BIP 54 und einer Implementierung des Soft Forks in Bitcoin Inquisition, einem Testfeld für Bitcoin-Konsensänderungen, zustande. Während dieser Zeit erhielt der Vorschlag umfangreiches Feedback, verschiedene Alternativen wurden in Betracht gezogen und Abhilfemaßnahmen für zusätzliche Schwachstellen wurden integriert. Ich glaube, dass es jetzt bereit ist, mit Bitcoin-Benutzern zur Prüfung geteilt zu werden.
Der Consensus Cleanup ist ein Soft Fork. Entwickler des Bitcoin-Protokolls entscheiden, welche Verbesserungen sie priorisieren und der Öffentlichkeit zugänglich machen möchten. Die endgültige Entscheidung über eine Änderung der Konsensregeln von Bitcoin liegt jedoch bei den Benutzern. Die Wahl liegt bei Ihnen.
Verpassen Sie nicht Ihre Chance, es zu besitzen Das Kernproblem – mit Artikeln, die von vielen Kernentwicklern geschrieben wurden und die Projekte erläutern, an denen sie selbst arbeiten!
Bei diesem Stück handelt es sich um den Brief des Herausgebers, der in der neuesten Ausgabe vorgestellt wird Drucken Ausgabe des Bitcoin Magazine, The Core Issue. Wir teilen es hier als ersten Einblick in die Ideen, die in der gesamten Ausgabe untersucht wurden.
[1] https://github.com/bitcoin/bips/blob/master/bip-0054.md
[2] https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
[3] https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
