Müssen Blöcke den nBits-Schwierigkeitsparameter aufzeichnen?

Die nächste Schwierigkeit, einen Block zu lösen, wird davon bestimmt, wie schnell Blöcke davor gelöst wurden. Außerdem ändert sich der Schwierigkeitsgrad nur etwa alle zwei Wochen.

Könnte also nicht jeder Knoten die erwartete Schwierigkeit verfolgen und muss sie nicht in jedem Blockheader haben? Oder gibt es einen Grund, warum Knoten die aktuelle Schwierigkeit in jedem Block mitteilen müssen? Nicht, dass es eine große Einsparung wäre oder so, es scheint nur seltsam, dass dies enthalten ist, wenn es nur eine Funktion aller anderen Teile einer Kette ist.

Vielleicht liegt es daran, dass die Berechnung von nBits irgendwann lange dauern würde, wenn Sie jedes Mal, wenn Sie die nächste Schwierigkeit berechnen wollten, alle Blockheader durchgehen müssten?

Antworten (1)

Erinnern Sie sich an das Whitepaper von Nakamoto , dass die Sicherheit für SPV-Kunden (Simplified Payment Verification) hauptsächlich am Arbeitsaufwand gemessen wird, der zur Sicherung einer bestimmten Transaktion aufgewendet wird. SPV-Knoten können vergangene Header nicht allein verwenden, um zu überprüfen, ob eine eingehende Zahlung gültig ist, daher besteht technisch gesehen keine große Notwendigkeit, vergangene Header zu speichern[1].

Wenn Sie nicht alle Header speichern möchten, benötigen Sie natürlich eine Möglichkeit, die Schwierigkeit für die Header zu messen, die Sie haben – und nBits bietet dies.

Beachten Sie, dass das Speichern aktueller Header die Sicherheit eines SPV-Clients erhöhen kann, indem es ihm ermöglicht wird, die richtige Schwierigkeit für spätere Header zu berechnen. Dies stellt sicher, dass ein Angreifer, der versucht, den Client anzulügen, Blöcke mit der richtigen Schwierigkeit erstellen muss. Dennoch wird hier keine vollständige Header-Kette benötigt, sodass nBits als Startwert immer noch nützlich ist.

[1] Aber BitcoinJ und alle anderen SPV-Clients, die ich kenne, speichern immer noch vollständige Header. Vermutlich besteht der Grund dafür darin, dass sie ihnen helfen, Kettenreorganisationen (Reorgs) zu erkennen, die eine zuvor erhaltene Zahlung ungültig machen würden.

so there's technically not much need to store past headersWas ist mit unbestätigten Transaktionen? Sie müssen sich vergangene Blöcke ansehen, um zu bestätigen, dass ihre Eingaben gültig sind.
Ein wesentlicher Teil der Überprüfung der Gültigkeit von Eingaben besteht darin, sicherzustellen, dass die Eingabe (vorherige Ausgabe) noch nicht für die Blockchain ausgegeben wurde. SPV-Clients sind dazu nicht in der Lage, da sie nicht die vollständige Blockchain verarbeiten. SPV-Clients können nur die Unverbrauchtheit von Eingaben überprüfen, für die sie die privaten Schlüssel (Wallet-Transaktionen) kontrollieren, sodass sie für Informationen über unbestätigte Nicht-Wallet-Transaktionen vollständig von ihren Full-Node-Peers abhängig sind – wenn alle ihre Peers lügen, die SPV-Client kann getäuscht werden.
Meiner Antwort wurde ein neuer Absatz hinzugefügt, in dem beschrieben wird, wie eine teilweise Header-Kette eine überlegene Sicherheit gegenüber dem Nichtspeichern einer Header-Kette sein kann und warum dies immer noch bedeutet, dass nBits nützlich ist.
doc sagt, dass ein SPV-Client die Header von Blöcken herunterlädt , aber keine vollständigen Blöcke; Wenn sie Blockheader herunterladen, können sie die Schwierigkeit selbst berechnen. Ich verstehe immer noch nicht, warum es als Block-Header-Feld enthalten sein sollte; und nichts erwähnt, wie man dieses Feld validiert;
Ein kleines Update: Für Clients, die der Header-First-Synchronisation folgen (eingeführt in Bitcoin Core 0.10), ist der nBitsWert in Headern nicht mehr wirklich nützlich (er ist immer bekannt, bevor ein Header oder Block bereits empfangen wird).
Müssen Blöcke den nBits-Schwierigkeitsparameter aufzeichnen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v