Was einen Miner daran hindert, Nonce-Hash zu fälschen

Was genau hindert einen Miner daran, einem zufälligen nonce hashBlock zeroesam Anfang genug zu präsentieren, um ausgewählt zu werden?

Wie wird das new hashvon den anderen Knoten verifiziert? Da es meines Wissens nach kein gültiges Hash-Ergebnis gibt, sondern mehrere? Was sind die Bedingungen außer einem number of zeroesam Start?

Anstatt das zu erhöhen nonce, könnten Sie intelligenterweise ein zufälliges höheres auswählen nonceund sehen, wie die Anzahl der führenden Nullen zunimmt? Oder besteht nie eine direkte Beziehung zwischen dem Nonce-Wert und dem resultierenden Hash? (Wahrscheinlich, aber ich muss das bestätigen lassen)

Was hindert vor allem einen Miner daran, eine vorberechnete Datenbank mit ausreichend schwierigen, aber zufälligen Nonces/Hashes zu haben, die sofort präsentiert und akzeptiert werden könnten ?

Wenn der neue Hash nur sein muss equal or lowerals das target? Wie überprüfen Sie, ob Arbeit geleistet wurde, ohne die gleiche Arbeit selbst zu erledigen?

Vielleicht finden Sie heraus, was Bitcoin-Miner wirklich lösen? eine interessante Lektüre.

Antworten (1)

Keine Korrelation zwischen einem Eingabebit oder einer Kombination von Bits und einem Ausgabebit oder einer Kombination ist für einen kryptografischen Hash akzeptabel. SHA256 ist ein akzeptierter kryptografischer Hash.

Jeder kann (und viele tun es auch) einen gültigen Block verifizieren , indem er eine Hash-Operation durchführt, anstatt der riesigen Zahl, die nötig ist, um sie per Brute-Force zu finden, derzeit in der Größenordnung von 1.000.000.000.000.000.000.000.

BEARBEITEN: Ich habe irgendwie 4 Bits pro Byte berechnet, nicht 8 (großer Unterschied), und das Prevhash-Präfix vergessen. Einiges korrigiert und auch präzisiert.

Zusätzlich zu Nonce können Miner ein paar Bits rechtzeitig optimieren und in der verfügbaren Zeit vielleicht 20-40 Bits im Wert von 20-40 Bits nach Wahl in der Merkle-Root verwenden (durch Ändern von Extranonce und/oder Transaktionen). Außerdem ist ein Teil von Prevhash immer gleich (nämlich Nullen) - zumindest solange die Datenbank-Verknüpfung nicht funktioniert, und das funktioniert nicht. Nennen wir es insgesamt 80 160 Bit, was bedeutet, dass eine vollständige Datenbank etwa 2^{240} 2^{480} Einträge umfassen würde . Aber wir können nicht so viel speichern, vor allem nicht, da es in deutlich weniger als der normalen Mining-Zeit von 10 Minuten abgerufen werden muss. Und da wir vorher nicht wissen können, welcheEinträge benötigt werden, egal welche Teilmenge der Datenbank wir speichern, es ist ein "Würfelwurf" für jeden Block-Header, ob er in der Datenbank ist und somit "vorher abgebaut" ist.

Wenn Sie alle ungefähr 2^{190} Atome im Sonnensystem verwenden (und sie nahe genug bewegen) und einen Header pro Atom speichern können, der viele tausend Mal dichter ist als jede bekannte Speichertechnologie, wird Ihre Datenbank "treffen". (Enthält die gewünschte Lösung) mit Wahrscheinlichkeit eins von 2^{290}, die (da die Versuche unabhängig sind) für (Rundung leicht) alle 20.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000 Jahre auftreten, die wahrscheinlich mit Sicherheit länger ist, als das Universum existieren wird . (Und sicherlich nicht oft genug, um daraus Profit zu schlagen.)

Siehe auch https://crypto.stackexchange.com/questions/1013/is-it-feasible-to-build-an-index-of-prime-factors für mehrere Diskussionen, warum ein ähnlicher Ansatz zum Brechen von RSA auch ohne lächerlich undurchführbar ist das kurze Zeitlimit, das für Bitcoin benötigt wird.

Da wärest du am Ende fast ein bisschen Douglas Adams geworden. Was meinst du mit will 'hit' about one block per.... Du meinst, wenn du versuchen würdest, es brutal zu erzwingen?
@BlockChange danke, dass du mich darauf zurückgeführt hast - mir wurde klar, dass meine Zahlen viel zu optimistisch waren. Etwas korrigiert und erweitert, um zu erklären, was ich mit Treffer meine.