100% Attacke auf Bitcoin (Wo liegt mein Denkfehler)

Hallo zusammen…

Seit einiger Zeit mache ich mir Gedanken über ein fiktives Angriffsszenario auf Bitcoin. Es wirkt sehr einfach, daher vermute ich, dass ich einen Denkfehler habe oder dass mir einfach Details des Protokolls fehlen. Aber vielleicht könnt ihr mir auf die Sprünge helfen :slight_smile:

Bei Bitcoin „gewinnt“ ja immer die längste Kette an (gültigen) Blöcken. Bei 51% Attacke mint der Angreifer daher mit mindestens 51% der Gesamtrechenleistung „heimlich“ Blöcke, die er dann erst veröffentlicht, wenn seine Kette (deutlich?) länger als die öffentliche Kette ist. Als Folge dessen übernehmen alle Nodes dem Bitcoin-Protokoll entsprechend die heimlich geminten Blöcke des Angreifers als neue Wahrheit und verwerfen die zuvor akzeptierten Blöcke (also die öffentlich geminten seit der Fork (Angreifer <> Öffentlichkeit)).
Der Angreifer benötigt also sehr viel Rechenleistung, da die Difficulty (vorgegeben durch die Chain zum Zeitpunkt der Fork) bereits sehr hoch ist.

ABER: Was wäre, wenn man bei einem sehr frühen Block anfängt? Oder gar dem Genesis-Block? Hier sind aktuelle CPUs dem von Satoschi damals deutlich überlegen. Problem: Aufholen könnte man die 12 Jahre leider nicht. Damit die Blöcke protokollgemäß gültig sind und dann von allen Nodes akzeptiert würden, müsste man sich an das Difficulty-Adjustment halten, wodurch man unterm Strich 12 Jahre brauchen würde, um 12 Jahre aufzuholen. Nicht wirklich sinnvoll ohne Zeitmaschine. Und die haben wir ja nicht. Oder vielleicht doch?!

Der Zeitgeber in einem PC kennt ja keine universelle Wahrheit/Zeit. Technisch ist es (je nach System einfacher oder komplizierter) möglich, die „Uhr“ in einem Rechner mit beliebiger Geschwindigkeit ticken zu lassen. Hebt man die Geschwindigkeit der Uhr (nicht die der CPU!) um das 100fache an, werden aus 12 Jahren keine 2 Monate. Die Rechenleistung der CPU im zeitmanipulierten System ist dann zwar entsprechend anders, das ist aber egal, da das Protokoll die Justierung der Difficulty ja immer so vornimmt, dass es im eigenen (Zeit-)System immer ca. 10min bis zum nächsten Block sind. In 2 Monaten veröffentlicht man 710.000 valide, selbst geminte Blöcke und damit eine Blockchain, die deutlich länger als die dann aktuell öffentlich geminte ist. Von der Änderung auf Normalgeschwindigkeit merken die Blöcke nichts. Sie haben ja ihre gültigen Zeitstempel aus der Vergangenheit und die öffentlichen Nodes haben auch keine Möglichkeit zu erkennen, ob die Zeitstempel denen der „Echtzeit“ entsprechen (wie auch?). Was zählt ist, dass alle Blöcke inkl. Zeitstempel über ihre Hashs miteinander valide verknüpft sind. Und das sollte ihr definitiv der Fall sein. Folglich ist die quasi leere, von mir allein in 2 Monaten gemite Blockchain der neue, gültige Ledger des Bitcoin-Protokolls. Ich allein habe dann knapp 19 Millionen BTC.
Boom, Bitcoin ade…
Klar, nützt einem nicht viel. Aber wenn man die Welt einfach nur brennen sehen möchte…

Was sagt ihr dazu? Wo liegt mein Denkfehler?
Argumentation bitte vorrangig auf der konzeptionellen Ebene. Also keine Diskussion, wie man im Details die Uhr schneller ticken lassen kann oder ähnliches :wink:

Nein. Die Rechenleistung (Hashrate) hat nichts mit irgendwelchen Einstellungen der Uhr auf deinem Rechner zu tun. Die Rechenleistung in (Hashes pro Sekunde) ist das, was dein Computer halt in einer Sekunde schafft. Das ist eine technische, physikalische Grenze deiner Hardware.

Natürlich bleibt die Hashrate von außen betrachtet identisch. Aber ein System mit manipulierter Uhr glaubt, dass die Hashrate anders ist und justiert entsprechend die Difficulty anders. Abgesehen davon würde das ja nichts am Funktionsprinzip ändern.

Hashrate hat nichts mit Uhr zu tun.

Die Difficulty wird aufgrund der führenden Nullen im Hash angenommen.

Natürlich hat die Hashrate etwas mit einer Uhr zu tun.
Hashrate = Hashes pro Zeiteinheit. Die Zeiteinheit wird durch die Uhr gemessen :wink:
Ein System mit einer langsamer laufenden Uhr, berechnet eine höhere Hashrate, als eines mit einer schneller laufenden Uhr.

Die Difficulty definiert, wie viele führende Nullen der Hash haben muss, um als gültig zu gelten.

Aber wir bewegen uns vollkommen von meiner Frage weg…

Deswegen ist aber die tatsächliche, physikalische Rechenleistung nicht größer oder kleiner.

Du kannst deinem Computer nicht mehr Rechenleistung geben indem du die Uhrzeit anpasst, wie bist du denn darauf gekommen?

Mal angenommen du fährst 100km/h auf der Autobahn. Wenn du jetzt im System deines Autos die Uhr so manipulierst dass das Auto denkt du fährst nur 50km/h wird dir das im Auto zwar so angezeigt,

… aber dein Auto fährt trotzdem noch 100km/h.

Die 100km/h kann man jetzt auch mit Abgaswerten ersetzen und dann sind wir beim Diesel-Skandal :wink:

Ich hab doch auch nie behauptet, dass der Rechner mehr Rechenleistung bekommt :roll_eyes:

Was ich gesagt habe ist, dass das Miningtool eine andere Rechenleistung ermittelt. Das muss es, da sich die Anzahl der Hashes nicht verändert (eben weil die Rechenleistung konstant bleibt), die gemessene Zeiteinheit aber anders ist als in einem System ohne manipulierte Uhr.

Die vom System ermittelte Hashrate ist für das oben genannte Beispiel aber vollkommen irrelevant, da die Difficulty-Adjustment die Difficulty sowieso so justiert, dass (im System der manipulierten Uhr) alle ca. 10 min ein Block gefunden wird. Geht die Uhr dort 100mal so schnell, wird der Rechner (vollkommen unabhängig von seiner Rechenleistung) in Realzeit alle 0.1 min einen Block finden.
(Vorausgesetzt natürlich, wie in meiner Annahme beschrieben, dass man mit dem Genesis-Block oder einem sehr frühen Block beginnt. Also einem, wo die Difficulty noch in einem Bereich lag, der für den angreifenden Rechner handhabbar ist.)

Jetzt verstehe ich was du meinst, das würde aber auch nicht funktionieren.

In deinem manipulierten System würdest du zwar „alle 10 Minuten“ einen Block finden, die tatsächliche Difficulty in diesem System wäre dann aber deutlich geringer als in der echten (denn du musst ja trotzdem real ein echtes Proof of Work finden - Und das ist Physik die du nicht manipulieren kannst).

Die deutlich geringere Difficulty führt zu komplett anderen Hashes und macht somit die ganze Chain ungültig (gegenüber der echten). Aber wenn du was an den Transaktionen manipulieren möchtest wäre das ja genauso der Fall.

Wie gesagt, die Chain muss nicht nur in sich selbst gültig, sondern auch mit allen anderen Kopien im Netzwerk identisch sein. Und das ist sie in so einem Fall nicht.

Die Idee eines Angriffs ist ja eigentlich die aktuelle Kette im geheimen weiter zu Minen um dann einen Double-Spend zu versuchen, indem man zum Beispiel eine Exchange reinlegt. Mit deinem manipulierten System könntest du auch nicht geheim voraus Minen da deine Difficulty dann nicht mit der aktuellen Vorgabe des Netzwerks übereinstimmt. Edit: Und da diese Chain natürlich ein geringeres PoW als die echte hat.

Verstehe also immer noch nicht worauf du jetzt hinaus willst.

Die „längste“ Kette ist die Kette mit dem meisten Proof of Work!
Nicht die Kette mit den meisten Blöcken.
https://learnmeabitcoin.com/technical/longest-chain

5 „Gefällt mir“

Nein, wenn du wirklich eine längere Kette(mit dem meisten Proof of Work) hast die sich seit Block Nr2 von der uns aktuellen Chain abspaltet, kannst du sie ins Netzwerk publishen und die gesamte Bitcoin Historie überschreiben.

Also den Sinn und Zweck des Ganzen möchte ich erstmal hinten anstellen. Für einen Angreifer, der einfach nur das Interesse hat, Bitcoin zu zerstören, ist ein Doublespend ja z.B. egal. Würde der oben beschriebene Angriff funktionieren, wäre immerhin das ganze Bitcoin-Netzwerk mit leeren Blöcken gefüllt und somit unbrauchbar.

Warum muss die Kette des Angreifers die Hashes der aktuellen Kette enthalten um gültig zu sein? Die so vom Angreifer geminte Blockchain ist doch in sich vollkommen konsistent und entspricht 100%ig dem Bitcoinprotokoll.

Eine 51% Attacke ist doch im Grunde nichts anderes. Sobald der Angreifer dort seine Blöcke ins Netzwerk freigibt unterscheiden die sich doch auch in ihren Hashes von denen der offiziellen, aktuellen Kette. Und jetzt stell dir vor, der Angreifer hätte sich einfach einen Block eher raus gesucht. Oder 2 eher. Oder 694485 eher…
Man kann sich ja einen beliebigen Block aus der Vergangenheit herausnehmen und dort anknüpfen. Die Konsistenz muss ja nur rückwärts gerichtet bestehen. Von dort kann man dann ganz gemütlich den Regeln des Netzwerks entsprechend (sehr schnell durch die manipulierte Uhr) eine extrem lange, in sich vollkommen gültige Kette minen. Klar, die hat am Ende eine verschwindend kleine Difficulty. Aber das ist den Nodes doch egal. Meines Wissens nach übernehmen die Nodes dem Protokoll nach immer die längste, in sich konsistente Kette. Unabhängig von der Difficulty, die die Kette am Ende vorgibt. Im Normalfall kommt es mal vor, dass ein oder zwei Blöcke gelöscht und durch neue ersetzt werden. Bei einer 51% Attacke könnten ein ein paar Dutzend werden. Bei mir eben 694485+.

Super!
Denkfehler aufgedeckt!

Vielen Dank :slight_smile:

Genau den Gedankengang hatte ich vor einigen Monaten auch, bin dadurch auf die Webseite https://learnmeabitcoin.com gestoßen. Kann die ganze Seite nur bestens empfehlen, die technischen Erklärungen sind TOP!

Ich lese ihn gerade noch einmal, die erste Version von Bitcoin hatte wohl sogar genau den von dir beschriebenen Bug :slight_smile:

Satoshi didn’t initially realize that choosing the correct chain by just counting blocks allows for some extremely easy attacks. Version 0.1 just counted blocks. That’s why the paper just says „longest“. The idea of „chain work“ was added a little later.

4 „Gefällt mir“