Was verhindert ähnliche Time-Warp-Angriffe in Bitcoin wie bei Verge?

Gerade jetzt (Mai 2018) wurde Verge (ein Altcoin mit Arbeitsnachweis) durch einen Time-Warp-Angriff angegriffen. Mehr kann hier gelesen werden

https://blog.theabacus.io/the-verge-hack-explained-7942f63a3017

Was genau verhindert einen ähnlichen Angriff auf Bitcoin?

Verge hat eine andere Hash-Logik (häufigeres Retargeting, mehr gleichzeitige Hash-Algorithmen), aber die Logik des Angriffs sollte meiner Meinung nach auch für Bitcoin gelten.

Da es bei Bitcoin nie passiert ist, habe ich wahrscheinlich etwas verpasst. Wie unterscheidet sich Verge von Bitcoin, dass dies in Verge passiert ist, aber nicht in Bitcoin?

Antworten (1)

Nichts verhindert dies direkt in Bitcoin, und tatsächlich wurde der Angriff auf testnet3 viele Male demonstriert – es ist der Hauptgrund, dass testnet3 derzeit fast dreimal so viele Blöcke wie Bitcoin hat, obwohl es mehrere Jahre nach dem Bitcoin-Mainnet und mit einem Etwas gestartet wurde ähnlich[1] dem durchschnittlichen 10-Minuten-Blockintervall von Bitcoin.

Indirekt gibt es mehrere Gründe, warum der Time-Warp-Angriff auf das Bitcoin-Mainnet weniger praktisch ist als auf Testnet3 oder Altcoins wie Verge:

  1. Offensichtlich: Sobald Blöcke, die in einem Time-Warp-Angriff verwendet werden, gesendet werden, kann jeder sehen, dass die Median-Time-Past (die monotone Uhr in Bitcoin) weit hinter der Echtzeit zurückbleibt.

  2. Langsam: Der Time Warp-Angriff nutzt die für das Retargeting verwendete Formel aus, aber das Retargeting wird nur einmal alle 2.016 Blöcke (zwei Wochen bei normaler Rate) ausgeführt und kann die Schwierigkeit nur um maximal 75 % pro Periode reduzieren. Nun, 75 % sind eine Menge, aber auch zwei Wochen damit verbringen, einen öffentlich sichtbaren Angriff auszuführen. Weitere Schwierigkeitsreduzierungen können aufgrund der geänderten Schwierigkeit schneller ausgeführt werden, aber sie sind immer noch ziemlich langsam: 3,5 Tage für das zweite Retarget; etwa 1 Tag für den dritten; etwa 6 Stunden für die vierte; etc...

  3. Von Bergleuten leicht zu beheben: Wenn ehrliche Bergleute den Großteil der Hashrate kontrollieren, können sie sich einfach weigern, auf Blöcken aufzubauen, deren Zeitstempel zu weit in der Vergangenheit liegen. Wenn die Median-Time-Past vor dem Ende der anfänglichen Retargeting-Periode von 2.016 Blöcken auf ihren normalen nachlaufenden Durchschnitt zurückgesetzt wird, ändert sich die Schwierigkeit nicht mehr als normal.

Wenn all diese Gründe tatsächlich indirekt Abhilfe schaffen, warum sehen wir dann alle paar Monate den Angriff auf testnet3? Hauptsächlich, weil testnet3 die gleiche SHA256d-Proof-of-Work-Funktion wie Bitcoin verwendet und jeder, der Blöcke wirklich schnell abbauen möchte, einige moderne ASIC-Miner anschließen kann, um schnell eine Reihe von Testnet-Blöcken zu erstellen. Dies würde normalerweise die Schwierigkeit schnell erhöhen, aber die Erhöhung wird durch den Time Warp-Angriff verhindert. In mindestens einem Fall in der Vergangenheit, in dem ein Time Warp-Angreifer testnet3 für längere Zeit unbrauchbar machte, richtete eine großzügige Person ihr eigenes riesiges Mining-Rig auf testnet3, um den Angreifer zu überwältigen und die Schwierigkeiten wieder herzustellen.

Wenn der Angriff im Bitcoin-Mainnet jemals ausgeführt würde, wäre die Geschichte meiner Meinung nach anders. Innerhalb weniger Tage würde ein großer Prozentsatz der Benutzerbasis wissen, dass der Angriff zunimmt, und anfangen, ehrliche Miner unter Druck zu setzen, die Blöcke des Angreifers abzulehnen. Ich persönlich gehe davon aus, dass Miner sich daran halten würden (denn der nächste Schritt wäre, dass die Leute anfangen würden, Phrasen wie „PoW-Funktionsänderung“ herumzuwerfen), was den Angreifer besiegen und ihn die erwarteten Einnahmen für jeden abgelehnten Block kosten würde.

Wenn Angreifer erwarten, dass sich das Szenario im Grunde so abspielen würde, wie ich es mir vorstelle, dann macht es keinen Sinn, dass sie den Angriff überhaupt starten – was meiner Meinung nach letztendlich Time-Warp-Angriffe auf Bitcoin verhindert.

[1] Testnet3 hat im Gegensatz zu Bitcoin die Regel, dass, wenn innerhalb von 20 Minuten kein Block abgebaut wurde (entsprechend der Blockheaderzeit), ein Miner einen Schwierigkeits-1-Block (die niedrigste Schwierigkeit) erstellen kann. Das bedeutet, dass selbst völlig ehrliches Mining auf Testnet3 schneller ist als auf Mainnet, da auf Mainnet etwa 20 % der Blöcke länger als 20 Minuten brauchen, um gefunden zu werden.


Einige zusätzliche Anmerkungen:

  1. Ein Fork könnte die Retarget-Berechnung so ändern, dass Median-Time-Past anstelle der Raw-Block-Header-Zeit verwendet wird. Dies könnte den Time Warp-Angriff auf Bitcoin beheben, aber es müsste wahrscheinlich ein Hard Fork sein.

  2. Seit dem BIP113 Soft Fork wird Median-Time-Past verwendet, um einzuschränken, welche nLockTime-Transaktionen Miner in ihre Blöcke aufnehmen können. Derzeit verwenden nicht viele Transaktionen nLockTime mit einer Zeit, aber wenn es einen Time Warp-Angriff gäbe, könnten Benutzer damit beginnen, um einen großen Gebührenanreiz für Miner zu schaffen, um die mittlere vergangene Zeit näher an die Echtzeit zu bringen.

Es ist interessant, dass die meisten dieser Abwehrmechanismen eher sozialer als technischer Natur sind. Es hängt davon ab, ob die Mehrheit der Miner keine Absprachen trifft.
@KarelBílek: Wenn eine Mehrheit (>50%) der Miner konspiriert, dann haben Sie bereits verloren.
Außerdem wird auf testnet3 aufgrund einer Eigenart, wie die schwierige Neuanpassung funktioniert, wenn der letzte Block in einer Retargeting-Periode länger als 20 Minuten braucht, um gefunden zu werden, nicht nur die Schwierigkeit dieses Blocks auf 1 zurückgesetzt, sondern alle Blöcke für die nächste Retargeting-Periode wird auch eine Schwierigkeit von 1 haben. Das macht testnet3 leicht spielbar, um eine sehr niedrige Schwierigkeit zu haben.
@ David A. Harding. In diesem Satz: "Weitere Schwierigkeitssteigerungen können aufgrund der geänderten Schwierigkeit schneller ausgeführt werden", meinst du "Verringerung" oder allgemein "Änderungen" und nicht "Erhöhungen" ?
@dbkeys behoben, ich meinte "verringert". Vielen Dank.