Im Wikipedia-Artikel über Merkle-Bäume habe ich das gerade gelesen und konnte nicht verstehen, wo das Problem liegt:
Zweiter Preimage-Angriff
Die Merkle-Hash-Wurzel gibt nicht die Baumtiefe an, was einen Second-Preimage-Angriff ermöglicht, bei dem ein Angreifer ein anderes Dokument als das Original erstellt, das dieselbe Merkle-Hash-Wurzel hat. Für das obige Beispiel kann ein Angreifer ein neues Dokument erstellen, das zwei Datenblöcke enthält, wobei der erste Hash 0-0 + Hash 0-1 und der zweite Hash 1-0 + Hash 1-1 ist.
Eine einfache Lösung ist in Certificate Transparency definiert : Beim Berechnen von Blattknoten-Hashes wird den Hash-Daten ein 0x00-Byte vorangestellt, während 0x01 vorangestellt wird, wenn interne Knoten-Hashes berechnet werden. Die Begrenzung der Größe des Hash-Baums ist eine Voraussetzung für einige formale Sicherheitsbeweise und hilft dabei, einige Beweise strenger zu machen. Einige Implementierungen begrenzen die Baumtiefe unter Verwendung von Hash-Baumtiefenpräfixen vor Hashes, sodass jede extrahierte Hash-Kette nur dann als gültig definiert wird, wenn das Präfix bei jedem Schritt abnimmt und immer noch positiv ist, wenn das Blatt erreicht wird.
Meine ersten Fragen sind: Ist das wirklich ein Problem bei Bitcoin? Wenn ja, wie wird es im Bitcoin-Kern gelöst?
Meine zweite Frage lautet: Könnte dieses Problem gelöst werden, indem die Baumtiefe jedes Blocks direkt in der Blockchain gespeichert wird? Oder wenn wir gerade von Bitcoin sprechen, würde sich das irgendwie negativ auf das Blockvalidierungsverfahren selbst auswirken?
Ja, diese Arten von Angriffen wirken sich auf Bitcoin aus und sind bekannt und beschrieben. Bitcoin hat keine Konsensminderungen für sie, da dies Konsensänderungen erfordert, die schwierig durchzuführen sind. Es ist bekannt, dass das Merkle-Tree-Design von Bitcoin mehrere Schwachstellen aufweist.
Der bei Wikipedia beschriebene besondere Angriff besteht darin, dass eine interne Ebene als gültiges Dokument präsentiert werden kann. In Bitcoin ist dies theoretisch möglich, obwohl es erhebliche Arbeit erfordern würde, einen Block zu erstellen, in dem die Transaktionen Hashes erzeugen, die dann als gültige Transaktionen deserialisiert werden können. Wenn ein solcher Block erzeugt würde, könnte dies aufgrund des Verhaltens rund um das Caching ungültiger Blöcke zu einer Netzwerkpartition führen. Offensichtlich besteht die Lösung dafür darin, sicherzustellen, dass zwischengespeicherte ungültige Blöcke sorgfältig behandelt werden, um zu vermeiden, dass Blöcke für Dinge abgelehnt werden, die von Dritten verformbar sind.
Tatsächlich führte dieses spezielle Problem zu einer Schwachstelle in Bitcoin Core 0.13, die inzwischen behoben wurde. Eine Beschreibung der Schwachstelle ist auf der bitcoin-dev-Mailingliste verfügbar .
Es gibt einen anderen verwandten Angriff, der in die andere Richtung geht – einschließlich einer Transaktion in einem Block, der als interner Knoten in einem Merkle-Baum interpretiert werden könnte. Dieser Angriff könnte verwendet werden, um auf SPV-Wallets abzuzielen und diese Wallets dazu zu bringen, zu glauben, dass eine Transaktion in einem Block enthalten ist, obwohl dies nicht der Fall ist. Dieser Angriff wird von Sergio Demian Lerner in diesem Blogbeitrag beschrieben .
Die einzig wahre Lösung für diesen zweiten Angriff erfordert eine Art Konsensänderung, um die Baumtiefe einzuführen. Aber Konsensänderungen sind schwierig, und es gibt noch andere Dinge, die getan werden können. SPV-Wallets können sich selbst schützen, indem sie prüfen, dass keine internen Knoten als gültige Transaktionen serialisiert werden können. Es ist unglaublich unwahrscheinlich, dass ein solcher interner Knoten zufällig erscheint, daher sollte dies keine wirklichen Auswirkungen auf den Benutzer haben. In Bitcoin Core werden zum Schutz vor diesem Angriff 64-Byte-Transaktionen nicht weitergeleitet. Da 64-Byte-Transaktionen kleiner sind als jede Standardtransaktion, ist dies sicher.