Warum hat Satoshi den Nonce-Raum nicht größer gemacht?

Ich weiß, dass Satoshi nicht mehr da ist, um zu fragen, also könnte es sinnlos sein, zu fragen, aber ich hoffe, dass jemand etwas darüber wissen könnte.

Bitcoin-Mining verwendet typischerweise ein extraNonce ( bnExtraNoncein der scriptSig der Coinbase tx) und ein Nonce-Feld (32 Bit). Warum hat Satoshi das Nonce-Feld nicht einfach größer gemacht, und dann wäre das nicht einmal nötig bnExtraNonce? Gibt es einen Grund, warum das Nonce-Feld auf 32 Bit gehalten werden musste? Es scheint einfacher gewesen zu sein, eine 64-Bit-Ganzzahl im Blockheader zu haben. Selbst wenn er Bedenken hatte, eine Ganzzahl mit mehr als 32 Bit zu haben, hätte der Header einfach als zwei 32-Bit-Ganzzahlen nonce1und interpretiert werden können nonce2.

Antworten (5)

Auf diese Frage gab es viele gute Antworten. Nachdem ich sie durchgelesen habe, werde ich mich auch mit der Antwort befassen.

Das Coinbase-Feld der Coinbase-Transaktion (wie es genannt wird) ist wirklich nur ein scriptSig, das keine Überprüfung seines Inhalts durchlaufen muss (außer dass es weniger als 100 Bytes beträgt und die neueren BIP34-Anforderungen). Satoshi wusste, dass man hier beliebige Inhalte einfügen konnte, und so fügte er eine aktuelle Schlagzeile in die ScriptSig des Genesis-Blocks ein: „The Times 03/Jan/2009, Kanzler am Rande der zweiten Rettungsaktion für Banken“. Eine Nachricht wie diese hilft auch zu bestätigen, dass kein Pre-Mining durchgeführt wurde, da die Nachricht nicht vor dem Datum der Veröffentlichung des Artikels in den Block eingefügt werden konnte.

Ich denke, dass Satoshi dachte, dass ein 32-Bit-Nonce-Space übertrieben wäre. Ein Standardcomputer, wie der, auf dem ich dies schreibe, kann ungefähr 3 MH/s erreichen, was ungefähr 0,07 % des Weges durch einen einzelnen Nonce-Bereich entspricht, bevor Sie nTime erhöhen und einen ganz neuen Bereich von Nonces erhalten können. Das soll nicht heißen, dass Satoshi dachte, dass es immer nur einzelne Computer-CPUs geben würde ( dieser Beitrag zeigt, dass er es nicht tat), aber ich wette, er dachte, dass jeder Miner in diesem Fall seine eigene Adresse haben würde.

Ich glaube nicht, dass Satoshi sich Pools vorstellte, insbesondere in der ziemlich zentralisierten Art und Weise, wie sie heute existieren, und die Flexibilität des Coinbase-Felds wurde nur von Mining-Pools (als eine Art Hack) genutzt, als die Hash-Power groß genug wurde, um durchzukommen mehr als ein einzelner Nonce-Bereich pro Sekunde.

Aus den Protokollregeln geht hervor, dass es so etwas wie eine zusätzliche Nonce nicht gibt.

Es gibt nur eine 32-Bit-Nonce im Blockheader (über die sehr schnell iteriert werden kann) und bis zu 100 beliebige Bytes in der Coinbase-Eingabe. Der Blockgenerierungscode im Referenzclient hat traditionell eine „zusätzliche Nonce“ in diese willkürlichen Bytes eingefügt, aber der Inhalt kann beliebig sein.

Warum hat er Ihrer Meinung nach das Coinbase-Feld anfangs dort platziert? Tyler schlug vor, dass es da sein könnte, um willkürliche Änderungen an einem Block zuzulassen, selbst in einer Situation, in der es keine Änderungen in Bezug auf Transaktionen gibt. Ich bin mir jedoch nicht sicher, warum das Ändern der Merkle-Wurzel besser wäre, als nur ein zweites Nonce-Feld zu ändern. David schlug vor, dass es wahrscheinlich zum Debuggen verwendet wurde. Scheint jedoch etwas zu sein, das einfach in eine Debug-Datei hätte gedruckt werden können.
Vielleicht wollte er dort gar nichts ablegen, es ist nur eine Transaktion mit einer scriptSig, die Sie nicht validieren müssen, also können Sie dort alles einfügen, was Sie wollen, und es wird keine Fehler verursachen ...
Aber er hat die Nachricht in die Coinbase-Transaktion des Genesis-Blocks eingefügt, also wusste er offensichtlich, dass sie geändert werden konnte. Ich denke, Miner haben einfach Glück, dass es etwas gab, das so einfach geändert werden konnte, da Satoshi nicht genug Nonce-Platz einräumte.
Die 32-Bit-Nonce in einem Block-Header ist gut für 4 Ghash. Der Zeitstempel im Header macht das 4 Ghash/s. Eine 32-Bit-Extranonce (was jedoch eine Neuberechnung des Merkle-Baums bedeutet) reicht für 16 Exahash/s aus. Was redest du davon, dass es nicht genug ist?
Ich meinte, dass nNonce allein für aktuelle Zwecke nicht ausreicht, also greifen Pools auf die Änderung der Coinbase zurück.

Meine Vermutung: Es scheint klar, dass Satoshi kein gepooltes Mining erwartet hat.

In einer Welt ohne gepooltes Mining würden Sie einfach jedes Stück Mining-Hardware, das bis zu 4 Gigahashes pro Sekunde (GH/s) erreichen kann, seinen eigenen öffentlichen Schlüssel verwenden lassen, was garantiert, dass es eine einzigartige Coinbase-Transaktionsausgabe erzeugt. Das Zeitfeld kann jede Sekunde aktualisiert werden, sodass die Nonce jedes Mal auf 0 zurückgesetzt werden kann, wenn die Zeit aktualisiert wird.

In einer Welt mit gepooltem Mining erstellen mehrere Personen alle identische Coinbase-Transaktionsergebnisse (zahlen, wen auch immer der Pool-Betreiber sagt, dass er zahlen soll) und sie hashen gemeinsam viel schneller als 4 GH/s, wodurch die Nonce-Reichweite erschöpft ist, bevor die Zeit angenommen wird aktualisiert werden. Dies macht die zusätzliche Nonce erforderlich, um zu vermeiden, dass mehrere Miner dieselben Header-Hashes überprüfen.

Warum also hat Satoshi überhaupt die Extra-Nonce geschaffen? Es sieht so aus, als wäre es eine einfache Möglichkeit gewesen, zu sehen, wie viele Hashes der Miner seit seinem Start verwendet hat. Wenn Sie sich die Coinbase von Block 1 (dem ersten Block nach dem Genesis-Block) ansehen, sehen Sie, dass es sich um Folgendes handelt:

 04 ......... Push 4 bytes to stack
 ffff011d ... The same as the nBits field
 01 ......... Push 1 byte to the stack
 04 ......... Number of times nonce was reset so far: 4  <= 20 GH

Bei Block 10 ist es 0x36 (54 <= 220 GH). Kurz gesagt, die ursprüngliche zusätzliche Nonce kann nur ein zusätzliches Debugging-Tool sein. Sie können nBits und die zusätzliche Nonce verwenden, um zu berechnen, wie viele Blöcke der Miner im Durchschnitt hätte produzieren sollen, und wenn das stark von der Anzahl der produzierten Blöcke abweicht, haben Sie möglicherweise ein Problem.

Danke, das ist hilfreich! Sie denken also, dass er dachte, der 32-Bit-Nonce-Speicherplatz wäre genug, und dann wurde das Coinbase-Feld in der Coinbase-Transaktion später hinzugefügt, um sowohl eine Änderung des Block-Headers zu vermeiden als auch den Bergleuten einen größeren Nonce-Speicherplatz zu geben? Oder, wenn es von Anfang an zum Debuggen da war, erklärt das nicht, dass er es überhaupt in die Blockkette einfügen musste. Es scheint, als könnten Sie jedes Mal, wenn die Nonce überläuft, einfach in eine Debug-Datei schreiben, und es wäre einfacher.
Vielleicht wollte er, wie viele Hashes der Miner in der Blockchain öffentlich zugänglich machen musste. Bedeutet das auch, dass wir einfach Glück hatten, dass Satoshi sogar das Coinbase-Feld in die Coinbase-Transaktion eingefügt hat, und so ist gepooltes Mining möglich? (Mit zwei Nonces im Header wäre es noch möglich gewesen)
Das Coinbase-Feld war immer da. Änderungen am Coinbase-Feld ändern den Header (die Merkle-Wurzel). Ich glaube nicht, dass die ursprüngliche zusätzliche Nonce-Implementierung verwendet wurde, um Bergleuten einen größeren Nonce-Raum zu geben – ich denke, sie wurde zum Debuggen verwendet. Bergleute begannen, es für andere Dinge zu verwenden, als sie anfingen, sich zu bündeln, und die aktuelle zusätzliche Nonce-Nutzung begann, als ASIC-Hardware verfügbar wurde, die viel schneller als 4 GH/s hashen konnte. (Davor verwendeten Miner Hacks wie nRollTime.)
Wenn das Coinbase-Feld nicht vorhanden wäre, könnten Miner einfach ein Nullwert-Ausgabeskript hinzufügen, beginnend mit OP_RETURN, um ein zusätzliches Nonce-Feld zu erstellen.
Daran habe ich auch gedacht, aber es wäre kein Standard-Transaktionstyp gewesen (oder gab es damals vielleicht keine Standard-Transaktionstypen?). Was meinst du mit "debuggen"? Was hat er debuggt? Ich verstehe nur nicht, warum irgendetwas davon im Coinbase-Feld stehen und die Merkle-Wurzel ändern muss, anstatt nur einen größeren Nonce-Platz im Header zu haben.
Es wäre bequemer für das aktuelle Mining, wenn die Header-Nonce größer wäre. Ihre Frage war, warum Satoshi das nicht vorausgesehen hat, da er anscheinend die Notwendigkeit eines zusätzlichen Nonce-Feldes zur Aktualisierung der Merkle-Wurzel vorausgesehen hat. Ich vermute, dass der Zweck des ursprünglichen Extra-Nonce-Felds nicht darin bestand, die Merkle-Root zu aktualisieren (obwohl es das tat), sondern Statistiken darüber zu verfolgen, wie viele Hashes überprüft wurden. Bergleute, die zusätzliche Nonce als zusätzliche Header-Nonce verwenden müssen, schürfen nicht so, wie Satoshi es beabsichtigt hat, mit einem eindeutigen öffentlichen Schlüssel pro Mining-Ausrüstung.
Die Extra-Nonce war schon immer da. Sogar der Genesis-Block selbst hat eine Extranonce (mit Wert 4). Und dass OP_RETURN nicht Standard ist, ist für Miner irrelevant, da sie entscheiden, was in einen Block eingefügt wird.

Tatsächlich ist die zusätzliche Nonce eine beliebige Präzisionszahl ( http://satoshi.nakamotoinstitute.org/posts/bitcointalk/115/ )

Ich vermute, dass es dazu da ist, willkürliche Änderungen an einem Block zuzulassen, selbst in einer Situation, in der es keine Änderungen in Bezug auf Transaktionen gibt. Dies würde es noch unwahrscheinlicher machen, dass es in einem transaktionslosen Zeitraum einen unlösbaren leeren Block geben könnte. (Schon fast unmöglich. Aber Hashes sind von Natur aus unvorhersehbar, also war Satoshi vielleicht nur besonders paranoid, als er es hinzufügte.)

Tatsächlich brauchen wir überhaupt keine 32-Bit-Nonce im Blockheader. Alles kann in das Coinbase-Eingabeskript eingefügt werden. Die Frage sollte also lauten: Können wir mit einem 76-Byte-Blockheader statt mit 80 Byte umgehen?

Wenn der Block-Header kein Nonce-Feld enthält, benötigen Sie für jeden Hash, den Sie ausführen, log(N) SHA256d-Hashes, wobei N die Anzahl der Transaktionen ist. Somit wären Personen, die keine Transaktionen einbeziehen, klar im Vorteil.
Ahh, weil das Nonce-Feld dafür sorgt, dass Sie die Merkle-Wurzel nicht jedes Mal neu berechnen müssen. Ich verstehe immer noch nicht, warum Satoshi möchte, dass Sie sich so sehr mit der Merkle-Wurzel herumschlagen müssen, wenn wir einfach einen größeren Nonce-Raum haben könnten.
Danke, Nick ODell für die Klärung. Vielleicht dachte Satoshi, dass 32-Bit-Nonce ausreicht. 80 Byte für Header - ist eine runde Zahl. Die Neuberechnung des Merkle-Hash nach 4 Milliarden Versuchen ist kein großes Problem
Wäre es nicht tatsächlich 2 * N Hashes für jeden Block-Header-Hash? Die Höhe des Merkle-Baums wäre log (N), aber die Anzahl der Hashes, die zur Berechnung der Merkle-Wurzel benötigt werden, beträgt ungefähr 2 * N, denke ich.
@ StephenM347 Ja, aber Sie ändern nur die Coinbase, also müssen Sie nur einen Teil des Merkle-Baums neu berechnen.
Aha, macht Sinn. Das erklärt also, warum der Nonce-Bereich nicht vollständig in der Coinbase enthalten ist, aber nicht, warum nicht alles in den Block-Header aufgenommen wurde ... Welchen Vorteil hat es, irgendetwas in der Coinbase zu haben? Es scheint nur eine Umgehung zu sein.
@StephenM347: Kürzere Blockheader, die unter anderem zu einer Reduzierung des SPV-Client-Ressourcenverbrauchs um 5 % führen.
@MeniRosenfeld, das ist interessant, aber scheint es kaum wert oder geplant zu sein. Siehe meine Antwort oben, wie ich zumindest den begrenzten Nonce-Raum rationalisiere.
Warum hat Satoshi den Nonce-Raum nicht größer gemacht?
AntwortenHierDatenschutz-Bestimmungen1y, 0v