Wo genau ist der "off-by-one" Schwierigkeitsfehler?

Ich habe gelesen Wie wird der Schwierigkeitsgrad berechnet? und verstehen möchten, wo der "off-by-one"-Fehler bei der Berechnung der Schwierigkeit liegt. Hier ist ein Matlab-Snipet, das ich geschrieben habe, um die Schwierigkeit zu berechnen. Was sind die korrekten Blockschrittintervalle, die ich verwenden sollte? Hinweis: minvund maxvsind die Blockhöhen (plus 1) des Intervalls. Somit werden Zeitstempel von den Blockhöhen 0 und 2015 in der ersten Schwierigkeitsberechnung verwendet.

% Calculate difficulty
num = floor(length(block_chain)/2016);
minv = 1;
maxv = 2016;
target = 1209600;
difficulty = ones(num,4);
delta = zeros(num,1);
timedif = delta;

for i = 1:num
    if i == 1
        difficulty(1,3) = 1;
        timedif(i) = block_chain(maxv,2) - block_chain(minv,2);
    else
        timedif(i) = block_chain(maxv,2) - block_chain(minv,2);
        delta(i) = max(0.25,min(target/timedif(i),4));
        difficulty(i,3) = max(1,difficulty(i-1,3)*delta(i));
    end
    difficulty(i,:) = [block_chain(minv,1), block_chain(maxv,1),...
        difficulty(i,3), timedif(i)];
    minv = maxv + 1;
    maxv = maxv + 2016;
end

Antworten (1)

Aus dem Litecoin-Wiki :

Zeitverzerrungsfehler[14]: Die Bitcoin-Schwierigkeitsberechnung ist um einen Block verschoben, sodass ein Angreifer wiederholt versuchen kann, den letzten Block jedes Retargeting-Fensters zu generieren, und einen fabrizierten Zeitstempel von 2 Stunden in die Zukunft verwendet, um die Zeit zu bestimmen Unterschied zum ersten Block im Retarget-Fenster hoch, wodurch die Schwierigkeit um 0,5 % gesenkt wird. Aufgrund des Fehlers wird der falsche Zeitstempel nicht als erster Block im nächsten Retargeting-Fenster verwendet, und daher werden die 2 zusätzlichen Stunden nicht in der nächsten Schwierigkeitsberechnung kompensiert. Sobald die Schwierigkeit niedrig ist, kann der Angreifer viele schnelle Münzen schürfen, oder im Falle einer kleinen Kette könnte ein Angreifer mit 51% Hash-Power die Schwierigkeit auf 1 reduzieren und einen neuen Fork aus dem Genesis-Block schürfen. Dies ist kein durchführbarer Angriff auf Bitcoin, weil die Wahrscheinlichkeit, bei so hohen Schwierigkeiten wiederholt alle 2 Wochen den letzten Block zu generieren, vernachlässigbar ist. Obwohl das Beheben dieses Problems in Bitcoin möglich ist, sollte es sorgfältig durchgeführt werden (indem Regeln hinzugefügt werden, die Knoten dazu ermutigen, im Laufe der Zeit zu aktualisieren), um eine Kettenverzweigung zu vermeiden, dh alte Clients, die kein Upgrade durchgeführt haben, könnten mit anderen Schwierigkeiten arbeiten und daher nicht einverstanden sein welche Blöcke gültig sind. In Litecoin ist dieser Fehler behoben

Der "off-by-one" oder Time Warp Bug wird verursacht, weil der Schwierigkeitsberechnungsalgorithmus keine überlappenden Zeiträume verwendet, für die erste Neuberechnung verwendet er die Blöcke 1 bis 2016 und für die zweite die Blöcke 2017 bis 4032.

Dies allein ist überhaupt kein Problem, aber da das Protokoll Zeitunterschiede zwischen den Knoten zulässt, ermöglicht dies, die Schwierigkeit beim Schmieden von Blöcken mit Auflösungszeit in der Zukunft zu verringern.

Der Algorithmus verwendet T(2016) - T(1), um die Geschwindigkeit des Netzwerks zu berechnen, wenn Block 2016 mit einem Zeitstempel 2 Stunden in der Zukunft erstellt wird (maximal vom Protokoll erlaubt), dann ist die Schwierigkeit 0,5 % niedriger als was es sollte sein.

Wenn dann Block 2017 gefunden wird und die Zeit echt ist (T(2017) kann kleiner als T(2016) sein), wird die zu Block 2016 hinzugefügte zusätzliche Zeit bei der nächsten Neuberechnung nicht kompensiert, wie es der Fall wäre, wenn Block 2 verwendet würde T(4032) - T(2016), um die Geschwindigkeit zu finden.

Ein detaillierteres Angriffsschema finden Sie unter: https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772

Interessant. Mir ist immer noch nicht klar, wie dies unbedingt ein Problem sein muss, selbst nachdem ich Bitcointalk gelesen habe. Dies ist eine lokale Zeitstörung und erzwingt eine noch höhere Schwierigkeit des nächsten Blocks, da die Konkurrenz um diese einfacheren Blöcke höher sein wird. Klingt so, als ob meine Berechnung korrekt ist, aber ich habe immer noch 0,4% Fehler in meiner Schwierigkeit.
Das Ziel sollte 1209000 sein, da es nur 2015-Zeitintervalle bei der Generierung einer 2016-Blockchain gibt.
Das Hauptproblem besteht darin, dass Bergleute zusammenarbeiten könnten, um eine niedrigere Schwierigkeit zu erreichen. Das große Problem ist, dass ein Angreifer mit einer wirklich hohen Hashing-Leistung einen Fork erstellen kann, der größer als der Hauptfork ist, ohne die Blöcke zu veröffentlichen, und dann den Hauptfork ersetzt, alle vorherigen Transaktionen „löscht“ und alle Mininig-Belohnungen erhält. Wenn Sie die Nachricht von ArtForz überprüfen, können Sie sehen, dass Sie, da die Grenzen für das Zurückreisen in die Zeit nicht festgelegt sind, eine Kette schmieden können, die den Schwierigkeitsgrad verringert (die 2. Periode verringert den Unterschied um die Hälfte), die Hauptkette überholt und dann veröffentlichen kann und ersetzen Sie die Haupt.
Es sah so aus, als ob es einen solchen Angriff in der Blockkette um eine Block-ID von etwa 200.000 gegeben hätte. Es sah so aus, als würden sich zwei parallele Ketten entwickeln, und dann würden die gegabelten Ketten am Ende verwaist. Aber da die anderen Bergleute die gegabelte Kette (ungefähr 60 Blöcke oder so) nicht akzeptierten, starb die Gabel. Danke für die Nachverfolgung.
Ich habe es ausgeführt, die für die Blöcke 278318-280223 berechnete Schwierigkeit war 1,7023E9, was viel zu niedrig ist.
Wo genau ist der "off-by-one" Schwierigkeitsfehler?
AntwortenHierDatenschutz-Bestimmungen1y, 0v