Was verhindert DoS basierend auf nahezu gültigen Blockzeitstempeln?

Nach Erhalt eines neu geschürften Blocks wird die Block-Zeitstempel-Validierung hier durchgeführt:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3263-L3270

F1: Was die zweite Prüfung betrifft (Zeitstempel des Blocks zu weit in der Zukunft), was hindert einen Miner daran, einen Block zu senden, der sich in der Zukunft dem Limit nähert, und einige der Knoten den Block akzeptieren, während einige andere Knoten den Block ablehnen?

F2: Wenn ein Teil des Netzwerks einen Block akzeptiert und der andere Teil des Netzwerks einen Block ablehnt (dh den Block aufgrund eines ungültigen Zeitstempels nicht in seinem Blockbaum aufzeichnet), kann sich das Netzwerk in irgendeiner Weise davon erholen?

Antworten (3)

Ich beantworte beide Fragen gleichzeitig. Es ist nicht ungewöhnlich, dass sich das Netzwerk aufspaltet, dh verschiedene Knoten akzeptieren verschiedene Blöcke als Kettenspitze. Tatsächlich passiert dies von Zeit zu Zeit, wenn zwei oder mehr Blöcke gleichzeitig von verschiedenen Bergleuten gefunden werden. Dies wird behoben, wenn der nächste Block über einem der vorherigen Blöcke gefunden wird. Die längste Kette ist gültig.

Und ein Miner kann nicht einfach den Zeitstempel beim Senden setzen. Der Zeitstempel muss gesetzt werden, bevor ein gültiger Nonce gefunden wird. Somit wird ein Miner dazu angeregt, mit einem gültigen Zeitstempel zu schürfen. Wenn der Block vom Netzwerk nicht akzeptiert wird, wird die verwendete Hashrate (und der Stromverbrauch) nicht kompensiert.

Danke, dass Sie sich damit befasst haben, aber es geht nicht wirklich auf die Fragen ein, hier ist der Grund: Im Fall einer "normalen" Gabelung, auf die Sie sich beziehen, enthalten die Blockbäume unterschiedlicher Knoten beide Blöcke, während in diesem Fall die Blockbäume sind im Wesentlichen unterschiedlich und können daher nicht mit mehr Arbeitsnachweisen zu einem Zweig synchronisieren/wechseln. Was den Anreiz des Miners betrifft, wenn es um die Manipulation von Zeitstempeln geht, sicher, der Miner hat keinen Anreiz, aber die Frage ist, ob dies theoretisch möglich ist oder nicht.

Es stimmt, dass dieser Randfall ein Problem darzustellen scheint, aber der Zeitstempel des Blocks ist entweder gültig oder nicht, da es sich um die Zeit seit der Einbettung in den letzten gültigen Block mit den meisten PoW handelt und nicht um die fragliche Ortszeit.

In dem beschriebenen Fall, was nicht der Fall ist, aber falls es irgendwie anders sein sollte, können einige Knoten weiter auf dem Block aufbauen, den die anderen Knoten ablehnen. Wie dies gelöst werden würde, hängt vom Prozentsatz der Netzwerkaufteilung ab. Wenn 51 % oder mehr der Mining-Power den spekulativen Block ablehnen, wird sich das Problem rechtzeitig von selbst lösen, da die gültige Kette weiter verlängert wird als und das meiste PoW hat. Wenn andererseits 51 % oder mehr der Mining-Macht den spekulativen Block akzeptieren, um darauf aufzubauen, wäre ein Eingriff erforderlich, um die noch ablehnenden Knoten aufzunehmen oder die ungültige Kette zu verwerfen.

Wenn ein Block den Konsensregeln (den Regeln des Referenzkunden) entspricht, ist er im Wesentlichen gültig.

Andere haben bereits festgestellt, dass es wirtschaftlich nicht sinnvoll ist, den Zeitrahmen beim Mining zu überschreiten, da dies im Voraus entschieden werden muss, sodass ein wirtschaftlicher Negativanreiz besteht.

Vielen Dank für den 2. Absatz, der 1. Absatz ist jedoch falsch: In diesem Fall wird die Obergrenze für die Gültigkeit des Zeitstempels als Zeit des lokalen Knotens + Zeitversatz des Netzwerks bestimmt (im Grunde Schätzung des lokalen Zeitfehlers basierend auf den Peers des Knotens). Als solches ist es vorstellbar, dass ein Miner einen Block mit einem Zeitstempel nahe der Obergrenze schürft und der Block von einigen Knoten abgelehnt und von anderen Knoten akzeptiert wird. ref: GetAdjustedTime() in github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3398
Okay, ich akzeptiere, dass dieses Detail meiner Erinnerung entgangen ist. Ich werde die Schreibweise des ersten Absatzes noch einmal überdenken.
@bgd223 Wäre es dann nicht so, dass der Blockzeitstempel in wenigen Minuten tatsächlich gültig wäre? Im schlimmsten Fall erfordert es eine erneute Überprüfung des Blocks oder noch weniger, nichts gemäß G Maxwells Erklärung.
Einverstanden, vorausgesetzt, es gibt keinen Mechanismus, der bereits abgelehnte Blöcke in jedem Szenario erneut ablehnt. und DoS basierend auf der Untergrenze scheint in diesem Fall nicht zu gelten.

Es ist normal und kein Problem, dass sich ein Teil des Netzwerks auf einem Spitzenblock befindet, während sich der Rest auf einem anderen befindet. Wenn es eine Aufteilung wie diese gibt, wird sie schließlich durch nachfolgende Blöcke entschieden.

Wenn ein Block von einem Knoten nicht akzeptiert wird, weil sein Zeitstempel zu weit in der Zukunft liegt, ist die Situation nicht viel anders: Nachdem der Zeitstempel zulässig wird, wird ein zukünftiger Block auf diesem Fork, der diesen Fork zur längsten Kette machen würde, eine Reorg verursachen darauf. Der einzige Unterschied zwischen dieser und einer durch ein gewöhnliches Block Race verursachten Aufteilung besteht also darin, dass die Nodes, die den Block abgelehnt haben, länger brauchen, um ihn zu akzeptieren – nicht bis sowohl die Zeit gültig ist als auch ein neuer Block auf diesem Fork erscheint.

Es ist kein Eingreifen erforderlich.