Kann ein böswilliger Majority Miner die Geschichte umschreiben?

Ist es der Fall, dass ein bösartiger Miner mit der Mehrheit der Hash-Power (sagen wir 99%) einen Double-Spending-Angriff durchführen kann, indem er den Verlauf umschreibt?

Wenn ja, kann ich nicht verstehen, wie. Wenn nein, unter welchen Umständen ist eine Doppelausgabe überhaupt möglich?

Betrachten Sie die folgenden einfachen Annahmen:

  1. Ein böswilliger Miner M kontrolliert 99 % der Hash-Power
  2. M kontrolliert nicht viel "Relaisleistung" (z. B. betreibt es nur einen einzigen Knoten im Netzwerk)
  3. Die aktuelle legitime Blockchain (vor dem Angriff) ist gabellos und besteht aus den Blöcken B0, B1, ..., B10, und 100 % der Knoten im Netzwerk stimmen darin überein.
  4. Der Angreifer möchte die Blöcke B6-B10 aufheben
  5. Der Angreifer hat die alternativen Blöcke B6' (auf B5), B7', ..., B11' abgebaut.

Wie kann der Angreifer den Angriff ausführen?

Wenn er B6' zuerst veröffentlicht, würden nicht alle Knoten es ablehnen, weil es auf einem anderen als dem letzten Block gebaut wurde, und so den Angriff verhindern?

Wenn er B11' zuerst veröffentlicht, würden nicht alle Knoten es ablehnen, weil es auf einem unbekannten Block aufgebaut ist (B10' noch nicht sieht), und so den Angriff verhindern?

Nebenbemerkung: Annahme 2 scheint irrelevant. Wenn M 99 % der Hash-Leistung kontrolliert, könnte es sicherlich Hunderte von Knoten auf der ganzen Welt betreiben. Es kann immer entscheiden, wie viele es verwenden möchte, je nach Bedarf für böswillige Handlungen.
Es kann immer noch nicht diese Hunderte von Knoten verwenden, um zu ändern, was andere Knoten denken.
Wenn ein Bitcoin-Knoten sicher wissen könnte, welches der letzte Block ist, wäre die ganze Sache mit den mehrfachen Bestätigungen nicht notwendig.
@pieter deshalb sagte ich irrelevant: ist so oder so egal.
Jannes: Sie sagen also, dass ein Angreifer mit dem gleichen Geldbetrag, aber ohne große Hash-Power dasselbe tun könnte? Das ist falsch. Die Anzahl der Knoten spielt keine Rolle, die Hash-Rate jedoch schon.
@ PieterWuille ehm ... Missverständnis hier. Annahme 2 sagt "Relaisleistung", dh die Anzahl der Knoten, die der Angreifer betreibt. Ich sage nur, es spielt keine Rolle, ob er 1 oder 100 Knoten betreibt, damit sein Angriff erfolgreich ist oder nicht. Es ist irrelevant.
@Jannes Entschuldigung! Ich habe übersehen, dass du von Annahme 2 sprichst.

Antworten (1)

Nehmen wir für eine Minute an, dass Ihre Theorie wahr ist und dass die tatsächlichen Knoten im Netzwerk diese neue, gültige und längere Blockchain nicht akzeptieren würden.

Das allein wäre ein Bug. Vielleicht ist es für eine 5-Block-Reorganisation nicht offensichtlich, aber wenn es eine 2-Block-tiefe wäre (was in der Praxis tatsächlich vorkommt), wäre Ihr Argument genauso wahr. Wenn es keine Möglichkeit gäbe, eine 2-Block-tiefe Reorganisation zu akzeptieren, würden die Knoten in ihrer kürzeren Kette stecken bleiben. Dies ist tatsächlich auch ausnutzbar: Jemand könnte absichtlich versuchen, Sie in einen solchen Zustand zu versetzen, da Sie keine neuen Zahlungen in der Kette sehen, die mit einer Zahlung in Konflikt geraten könnten, die der Angreifer Ihnen zu senden versucht.

Dies gilt für jede Reorganisationstiefe. Wenn wir keine 12-Block-tiefe Reorganisation akzeptieren, würde das Netzwerk in einem sehr wunden Zustand bleiben, wenn es jemals eine mehrstündige Partitionierung des Netzwerks geben würde. Die Fähigkeit, die längste gültige Kette unter allen Bedingungen zu akzeptieren, ist absolut erforderlich, um Bitcoin zu konvergieren.

Also: Wir brauchen einen Mechanismus, um so ziemlich jede Tiefe zu reorganisieren. Wie dies erreicht wird, hat sich in Bitcoin Core 0.10 mit der Einführung der Header-First-Synchronisation geändert.

Vor 0.10 würde der Angreifer zuerst B11' senden, wovon das Opfer nichts weiß. Es wird eine getblocksNachricht senden, um die Hashes von Blöcken zwischen B5 (unter Verwendung eines Blockfinders) und B11' anzufordern. Wenn es diese Hashes empfängt, lädt es sie einzeln mit herunter, stellt getdatafest, dass sie einen fehlenden Elternteil haben, legt sie in den Waisenpool (die Gruppe von Blöcken ohne bekannten Elternteil) und stellt fest, dass sie sich verbinden, wenn sie alle empfangen werden , und wechseln Sie dorthin.

Seit 0.10 würde der Angreifer invB11'. Das Opfer wird eine getheadersNachricht verwenden, um die Blockheader zwischen B5 und B11' und getdatafür den Block B11' selbst anzufordern. Wenn die Header ankommen, werden sie im laufenden Betrieb validiert (in der Reihenfolge zunehmender Höhe, sodass sie immer verbunden sind). Bis B11' ankommt, kennen wir bereits seine Eltern und wissen, dass dies (unter der Annahme, dass die Eltern gültig sind) tatsächlich die neue beste Kette sein wird. Wir beginnen dann damit, die tatsächlichen Blöcke B6' bis B10' zu holen, um die Lücken zu füllen, und wenn sie alle angekommen sind, schalten wir zu dieser Kette um.

Das soll nicht heißen, dass bei großen Umstrukturierungen nicht die Alarmglocken schrillen würden, oder?
Ja, in der Tat. An einem gewissen Punkt wird es unsicher genug, dass ein menschliches Eingreifen erforderlich sein kann.
Kann ein böswilliger Majority Miner die Geschichte umschreiben?
AntwortenHierDatenschutz-Bestimmungen1y, 0v