225 / 736TARGET

Mining Target

Die Zahl, die ein Mining-Ergebnis nicht überschreiten darf

Jana weiß, dass Miner ständig Berechnungen wiederholen. Aber worauf warten sie eigentlich? Jeder Versuch erzeugt einen Hash, ein Ergebnis, das sich als sehr große Zahl verstehen lässt. Nicht jedes Ergebnis genügt: Es muss unter einer festgelegten Grenze liegen, wobei Gleichheit ebenfalls erlaubt ist. Diese Grenze heißt Mining Target. Je niedriger sie liegt, desto seltener gelingt ein Treffer. Andere Netzwerkteilnehmer können anschließend leicht prüfen, ob das Ergebnis die Bedingung erfüllt.

Das Mining Target ist der Zahlenwert, mit dem der Hash des Block-Headers verglichen wird, der kompakten Datenzusammenfassung eines Blocks. Für einen gültigen Arbeitsnachweis darf der Hash das richtige Ziel nicht überschreiten. Im Bitcoin-Netzwerk muss dieses Ziel positiv sein und den Regeln für den jeweiligen Block entsprechen; Miner können es nicht frei wählen.

Stell dir zur Veranschaulichung eine Grenze von 20 vor: 19 und 20 würden passen, 21 nicht. Beim echten Mining sind die Zahlen viel größer, doch die Beziehung bleibt gleich: hash ≤ target. Das Zeichen bedeutet kleiner oder gleich, nicht ausschließlich kleiner. Bitcoin Core ist Software, mit der Netzwerkteilnehmer Blöcke und Transaktionen prüfen. Die hier verlinkte Version v29.0 vergleicht so den Hash des gesamten Headers. Die nonce, ein Wert, den Miner bei der Suche verändern, ist einer der Eingabewerte. Mit dem Zielwert wird der daraus berechnete Hash verglichen. [1]

Jana sieht einen erfolgreichen Hash mit einer langen Reihe führender Nullen. Das ist eine hilfreiche Vorstellung: Bei gleich langer Darstellung bedeuten mehr Nullen am Anfang eine kleinere Zahl. Zwei Hashes mit gleich vielen führenden Nullen können aber auf unterschiedlichen Seiten des Zielwerts liegen. Auch die übrigen Ziffern zählen. Die Nullen ersetzen deshalb nicht den vollständigen Vergleich hash ≤ target. Gesucht ist kein schönes Zeichenmuster, sondern die Erfüllung einer exakten Zahlenbedingung. [1]

Ein Bit speichert eine Null oder eine Eins; acht Bits bilden ein Byte. Statt die gesamte lange Zahl im Header zu speichern, verwendet Bitcoin das 32 Bit lange Feld nBits. Es kodiert ein Ziel im Raum der 256-Bit-Zahlen mit einem Koeffizienten, einem Exponenten für die Verschiebung und einem Vorzeichenbit. Beispielsweise wird 0x04123456 zu 0x12345600 dekodiert. Das Präfix 0x kennzeichnet die hexadezimale Schreibweise, die auch Buchstaben verwendet. Das ist ein Kodierungsbeispiel, nicht das aktuelle Netzwerkziel. Für das Grundverständnis genügt die Unterscheidung zwischen der Zahl und ihrer Kurzschreibweise. [3] [5]

In Rohdaten kann dieselbe Zahl scheinbar umgekehrt aussehen. Im 80 Byte langen Header belegt nBits vier Bytes in little-endian-Reihenfolge: Das niederwertigste Byte steht zuerst. Der Zahlenwert 0x1d00ffff erscheint daher in den Daten als ff ff 00 1d. Die Byte-Reihenfolge verändert nicht das Ziel, sondern beschreibt die Speicherung. Das ist für die Arbeit mit Rohdaten relevant; beim normalen Lesen eines Blockexplorers muss man die angezeigten Zahlen nicht umdrehen. [2]

Jana könnte vorschlagen, eine größere Zahl zu speichern, um die Suche zu erleichtern. Doch die Software prüft nicht nur, ob sie nBits lesen kann. DeriveTarget in Bitcoin Core v29.0 verwirft negative Ziele, null, einen Überlauf des Zahlenbereichs und Werte oberhalb von powLimit, dem höchsten für dieses Netzwerk erlaubten Ziel. Erfolgreiches Dekodieren sagt also nur, welche Zahl eine Darstellung bedeutet. Es erlaubt noch nicht, diese Zahl zu verwenden. [1]

Auch ein Ziel innerhalb des erlaubten Bereichs kann für einen bestimmten Block falsch sein. Bitcoin Core vergleicht nBits mit GetNextWorkRequired, einer Berechnung aus dem vorherigen Block und den Netzwerkregeln. Bei einer Abweichung folgt bad-diffbits. Ein niedriger Hash unter einem selbst gewählten leichteren Ziel entschuldigt keinen falschen Header-Wert. Jana kann keinen akzeptierten Block erzeugen, indem sie die Anforderungen senkt: Andere Nodes, also Computer, die die Regeln prüfen, lehnen diesen Versuch ab. [4]

Im Modell gleichverteilter 256-Bit-Hashes ist jedes mögliche Ergebnis gleich wahrscheinlich. Bei einem erlaubten Ziel T werden alle Werte von null bis einschließlich T akzeptiert. Daraus folgt p = (T + 1) / 2^256 pro Versuch; p steht für die Erfolgswahrscheinlichkeit. Die zusätzliche Eins berücksichtigt die null. Die Beziehung erklärt, warum ein niedrigeres Ziel die Suche erschwert. Sie sagt weder, wie viele Versuche eine Maschine pro Sekunde schafft, noch wann genau der nächste Block kommt. [1]

Erfüllt Jana die Bedingung, hat sie die erforderliche Rechenarbeit nachgewiesen, nicht die Richtigkeit des gesamten Blockinhalts. Bitcoin Core prüft zusätzlich den gemeinsamen Fingerabdruck der Transaktionen, die spezielle Belohnungstransaktion coinbase, die Blockgrenzen und die Gültigkeit der Transaktionen. coinbase meint hier die erste Transaktion im Block, nicht die Börse. Ein niedriger Hash repariert keinen ungültigen Inhalt. Das Ziel ist ein wichtiger Teil der Regeln, keine Erlaubnis, den Rest zu umgehen. [4]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Share Difficulty, Proof of Work, Nonce, Block Header, Bitcoin. Auf diesen Eintrag verweisen außerdem ASIC Miner, Nonce, Mining Share, Share Difficulty.

DOC · 001Bitcoin Core v29.0 — Proof-of-work checksPrimärquelle DOC · 002Bitcoin Developer Reference — Block headers and nBitsDokumentation DOC · 003Bitcoin Core v29.0 — Compact arithmeticPrimärquelle DOC · 004Bitcoin Core v29.0 — Contextual and block validationPrimärquelle DOC · 005NIST — Binary data unitsDokumentation
Überarbeitet: Quellenbasiert · Keine Anlageberatung