Warum ist der Blockheader 80 Bytes groß, nicht 128 Bytes (= zwei SHA-256-Blöcke)?

Laut der Bitcoin Developer Reference ist der Block-Header insgesamt 80 Bytes groß:

BYTENAME
4-Version
32 Header-Hash des vorherigen Blocks
32 Merkle-Root-Hash
4 Mal
4 einmal

So wie ich es verstehe, enthält der Midstate (1. SHA-Block) 64 Bytes des Block-Headers (welche Felder im Besonderen ich nicht kenne, aber ich weiß, dass es die Nonce nicht enthält), und der 2. SHA-Block enthält den Rest , nur 80-64 = 16 Bytes. Bedeutet dies, dass der 2. SHA-Block mit 64 - 16 = 48 Bytes aufgefüllt wird? Wenn ja, warum nicht das Nonce-Feld zum Beispiel 48 - 4 = 42 Bytes größer machen (dh 52 Bytes statt 4 Bytes)?

Auf diese Weise muss Extranonce nicht in der Generierungstransaktion enthalten sein, wodurch das Hashing beschleunigt wird, oder?

Was Sie vorschlagen, wurde auf Bitcointalk vorgeschlagen (ich kann den Link anscheinend nicht finden). Ich denke, das Problem dabei ist, dass es zu einem leichten Rücktritt von ASICS führen würde, eine Hard Fork wäre und die Aktualisierung der Extranonce einmal alle 2 ^ 32 Hashes ohnehin äußerst vernachlässigbar ist.
@StephenM347 Das Hashing muss schnell genug werden, dass die Neuberechnung der Merkle-Wurzel für eine Änderung der Extranonce ein Engpass wäre. Warum also nicht zum Beispiel die Extranonce gleich in den Midstate-SHA-Block stellen?
Die Neuberechnung der Merkle-Wurzel wird niemals der Flaschenhals sein. Knirschen Sie die Zahlen, ich habe es schon einmal gemacht. Denken Sie daran, dass die Neuberechnung des Merkle-Roots Log(N)-Hashes (N = Anzahl der Transaktionen im Block) benötigt, nicht N. Selbst wenn eine CPU nicht genug Arbeit für eine ASIC-Farm generieren könnte, müssten Sie einfach zugreifen ein Prozessor mit mehr Kernen. Sie müssen die Merkle-Wurzel ohnehin regelmäßig für neue Transaktionen neu berechnen.
@StephenM347 Warum wird Extranonce alle 2³² Hashes aktualisiert?
Die Nonce ist eine 32-Bit-Ganzzahl, also gibt es 2^32 Werte, die Sie ausprobieren können, bevor Sie ausgehen und etwas anderes ändern müssen.
@StephenM347 Oh ja, natürlich. Aus irgendeinem Grund dachte ich an Extranonce, nicht an Nonce. Danke
@Geremia In Ihrem Blockheader fehlt das Feld <nBits> 4-bytes denoting the target threshold.

Antworten (1)

Dies hätte auf diese Weise geschehen können, auf Kosten der Erhöhung des Speicherplatzes, der zum Speichern und Senden von Blockheadern benötigt wird. Es scheint, als ob die Block-Header-Speicherung ein großes Problem für Satoshi war (es gibt sogar einen Abschnitt im Whitepaper darüber), aber es hat sich herausgestellt, dass es nicht sehr wichtig ist.

Bedeutet dies, dass der 2. SHA-Block mit 64 - 16 = 48 Bytes aufgefüllt wird?

Ja, (Quelle) , aber Ihre Argumentation ist fehlerhaft. Selbst wenn der Nonce-Raum so groß wäre, dass er sich in einen anderen Block erstreckte, würde das nur bedeuten, dass Midstate den Zustand darstellen würde, nachdem alle bis auf den letzten Block gehasht wurden (Block im Sinne der Kryptografie, nicht im Sinne von Bitcoin).

Wenn der Block-Header genau 128 Bytes wäre, würde das Auffüllen ihn auf einen dritten Block erweitern. Sie haben nur 119 Bytes, bevor das passiert.

Auf diese Weise muss Extranonce nicht in der Generierungstransaktion enthalten sein, wodurch das Hashing beschleunigt wird, oder?

Nicht wirklich. Sie können 2^32 Hashes überprüfen, bevor Sie die Extranonce erhöhen. Danach müssen Sie nur noch etwa zehn Hashes ausführen, bevor Sie zum Mining zurückkehren.

Im Allgemeinen wurde in modernen ASICs sogar dieser Teil ausgelagert. Innerhalb des ASIC wird es eine Art kleinen Prozessor geben, wie einen ARM-Kern, der eine Blockvorlage als Eingabe verwendet und Blockheader ausgibt, an denen die SHA256-Kerne arbeiten können.

Die Kosten liegen also nicht in der Geschwindigkeit, sondern in der Komplexität.

Wie viele Dinge bei Bitcoin denke ich, dass dies eine technische Entscheidung ist, die damals sinnvoll war, aber schlecht gealtert ist.

Die Größe der Blockheader wird wichtiger, wenn wir die Zeit zwischen den Blöcken verkürzen.
@MeniRosenfeld Tut es? Ich meine, wir reden hier von zusätzlichen 4-8 Bytes pro 80 Bytes. Das scheint kein signifikanter Unterschied zu sein.
Richtig, wenn es nur eine kleine Änderung ist, wird es nicht viel ausmachen. Aber wenn Sie beispielsweise die Header-Größe verdoppeln würden, würden Sie den Ressourcenbedarf für SPV-Clients verdoppeln, was erheblich sein kann, wenn Sie GHOST-beschleunigte Blöcke und SPV auf Mobiltelefonen oder sogar kleineren Geräten haben. Wahrscheinlichkeitsverifikationsschemata könnten dies jedoch lösen.
@MeniRosenfeld, du denkst, die Zielblockzeit wird geändert? Angesichts der Tatsache, wie schwierig es ist, alle dazu zu bringen, einer Änderung eines einfachen Parameters für die maximale Blockgröße zuzustimmen, bin ich skeptisch. Es sei denn, jeder wechselt zu einer Sidechain oder so.
@StephenM347: Ich hoffe es sehr. Es ist nur eines von vielen Dingen, die irgendwann geklärt werden müssen.
Warum ist der Blockheader 80 Bytes groß, nicht 128 Bytes (= zwei SHA-256-Blöcke)?
AntwortenHierDatenschutz-Bestimmungen1y, 0v