Wie wird die Schwierigkeit berechnet?

Kann mir jemand in einfachem Englisch erklären, wie die Schwierigkeit berechnet wird? Ich habe ein sehr ungefähres Verständnis, dass es auf der Grundlage der Menge an Hash-Power in der gesamten Bitcoin-Community über einen bestimmten Zeitraum berechnet wird. Aber das ist sehr vage.

Ich verstehe auch, dass es sich sehr schnell ändern kann. Kann es nur zunehmen? Gibt es eine Formel, wie man es berechnet oder vorhersagt?

Danke für die ausführliche Antwort, Meni Rosenfeld. Nur um sicherzugehen, dass ich alles richtig gemacht habe. Ich fasse die ganze Zeit zusammen, die es gedauert hat, die letzten 2016-Blöcke zu generieren. Und dann die Formel anwenden.

Ich denke, Folgefragen sind besser als Kommentare zur Antwort. Grundsätzlich ja, aber eigentlich ist keine Summierung erforderlich - Sie können einfach die Zeitstempel des letzten Blocks und des einen 2016-Blocks davor nehmen und subtrahieren.

Antworten (3)

Die Bitcoin-Schwierigkeit begann bei 1 (und kann nie darunter fallen). Dann werden für alle gefundenen 2016-Blöcke die Zeitstempel der Blöcke verglichen, um herauszufinden, wie viel Zeit es gedauert hat, 2016-Blöcke zu finden, nennen wir es T. Wir wollen, dass 2016-Blöcke 2 Wochen dauern, also multiplizieren wir, wenn T unterschiedlich ist die Schwierigkeit um (2 Wochen / T) - auf diese Weise dauert es, wenn die Hashrate so bleibt, wie sie war, jetzt 2 Wochen, um 2016-Blöcke zu finden.

Wenn es beispielsweise nur 10 Tage gedauert hat, bedeutet dies, dass der Schwierigkeitsgrad zu niedrig ist und daher um 40 % erhöht wird.

Die Schwierigkeit kann sich erhöhen oder verringern, je nachdem, ob es weniger oder mehr als 2 Wochen gedauert hat, 2016-Blöcke zu finden. Im Allgemeinen nimmt die Schwierigkeit ab, nachdem die Netzwerk-Hashrate gesunken ist.

Wenn der Korrekturfaktor größer als 4 (oder kleiner als 1/4) ist, werden stattdessen 4 oder 1/4 verwendet, um zu verhindern, dass die Änderung zu abrupt ist.

Es gibt einen Fehler in der Implementierung, aufgrund dessen die Berechnung auf der Zeit basiert, um die letzten 2015-Blöcke zu finden, anstatt auf 2016. Die Behebung würde einen Hard Fork erfordern und wird daher vorerst zurückgestellt.

Es ist möglich, basierend auf der Zeit, um die letzten Blöcke zu finden, eine grobe Schätzung für die nächste Schwierigkeitsänderung abzugeben. Niemand kann längerfristige Vorhersagen für die zukünftige Schwierigkeit treffen, aber jeder kann auf der Grundlage von Wechselkurstrends, dem Mooreschen Gesetz und anderen Hardware-Fortschritten spekulieren.

Ist der Fehler immer noch da? Sollte es dafür nicht ein GitHub-Problem geben, damit die Leute den Status verfolgen können ... Mit solchen Fehlern im Protokoll wird es für das Bitcoin-Ökosystem schwierig sein, sich von der Situation zu entfernen, in die sich die Satoshi-Client-Entwickler begeben haben Alle Regeln.
@StevenRoose: AFAIK ist es, aber ich überlasse es Leuten, die mehr mit dem Kerncode zu tun haben, Kommentare abzugeben ... Dies ist ausreichend für eine separate SE-Frage.
Gute Antwort, aber ein kleiner, aber wichtiger Punkt wird umgangen: Wie einigen sich die Knoten im Netzwerk darauf, was die Schwierigkeit ist?
@deadalnix: Die Schwierigkeit eines Blocks ist eine deterministische Berechnung basierend auf den Daten der vorherigen Blöcke. Alle Knoten führen unabhängig voneinander die gleiche Berechnung durch und erhalten das gleiche Ergebnis.
@MeniRosenfeld danke für diese Antwort. Aber für mich verschiebt es nur das Problem. Wie ich Ihre Antwort verstehe, erfolgt die Berechnung anhand des in den Blöcken verfügbaren Zeitstempels. Aber wie einigt sich ein P2P-Netzwerk dann auf den Zeitstempel?
@deadalnix: Der Zeitstempel ist ein Teil des Blocks, was bedeutet, dass derjenige, der den Block gefunden hat, entscheidet, was darin eingefügt wird. Der Zeitstempel darf nicht früher als der Median der letzten 11 Blöcke sein. Wenn ein Knoten einen Block mit einem Zeitstempel empfängt, der mehr als 2 Stunden in der Zukunft liegt, wird er ihn ablehnen und nicht weitergeben.
Verweise auf die Bitcoin-Spezifikationen oder die Codebasis wären sehr willkommen. Das Überarbeiten Ihrer Antwort wird dringend bevorzugt, anstatt Dinge in die Kommentare zu schieben.
@Indolering: Das Zeug in den Kommentaren ist nicht Teil der Kernantwort. Sie sind Antworten auf spezifische Folgefragen.
@Meni, wenn ich also den Rundenabschluss berechnen möchte, soll ich CURRENT_BLOCK_COUNT_IN_THIS_ROUND/2015 statt CURRENT_BLOCK_COUNT_IN_THIS_ROUND/2016 machen ???
@mixdev: Die "Runde" (Schwierigkeits-Retargeting) wird alle 2016 Blöcke durchgeführt. Aber die Neuberechnung ist derzeit nicht prev_target TIME_FOR_LAST_2016_Blocks/1209600, sondern prev_target TIME_FOR_LAST_2015_Blocks/1209600.
Das bedeutet also im Grunde, dass sich Fehler summieren, da jedes Mal nur die letzte Epochenzeit berücksichtigt wird? Dies würde bedeuten, dass die Aussage, dass im Jahr 2140 die letzten Bitcoins geschürft werden, falsch ist, da es Jahre oder sogar Jahrzehnte davor liegen könnte.
@tobi: Der Off-by-One-Bug ist dafür verantwortlich, dass Blöcke alle zwei Wochen durchschnittlich 0,05 % langsamer gefunden werden als das "offizielle" 2016. Es gibt ein separates Problem, das eine weitere Verlangsamung um 0,05 % verursacht. Zusammen belaufen sie sich auf nur 1 Monat Verlangsamung über ein Jahrhundert. Es gibt jedoch einen separaten Effekt, der dazu führt, dass Blöcke aufgrund der Erhöhung der Hashrate schneller gefunden werden. Dies ist von größerer Bedeutung und die letzte Münze wird wahrscheinlich 1-2 Jahre zu früh aus diesem Grund geschürft.
@tobi: Die Gesamtbeschleunigung aufgrund der Erhöhung der Hashrate kann ungefähr als log (Schwierigkeit) * 2 Wochen berechnet werden. Dies ist der Hauptgrund, warum Blockhalbierungspartys jedes Mal an einem anderen Datum stattfinden – November 2012, Juli 2016 usw.
Ja, ich bezog mich auf die Beschleunigung aufgrund der zunehmenden Hashrate und nicht auf den Blockierungsfehler von 2015
@tobi: Ah okay. Frühere Kommentare betrafen den Fehler, und „Fehler“ deuteten darauf hin, dass es sich um den Fehler handelt, also nahm ich an, dass wir darüber sprechen. Also ja. Wenn wir davon ausgehen, dass die Hashrate um 2140 etwa *1B betragen wird, was sie jetzt ist, wird der Zeitplan um 96 Wochen oder fast zwei Jahre voraus sein. Aber es gibt noch einen weiteren Effekt – eine Verzögerung, die dadurch verursacht wird, dass die Schwierigkeit am Anfang 1 war, obwohl die Hashrate nicht ausreichte, um dies zu rechtfertigen.

Menis Antwort ist gut. Ich möchte nur eine praktische Detailmethode zur Berechnung der Schwierigkeit angeben, die möglicherweise für zukünftige Ansichten der Antwort auf diese Frage hilfreich ist.

Werfen wir einen Blick auf den Header des Genesis-Blocks von Satoshi (Teil der zugehörigen Informationen):

$ bitcoin-cli getblockhash 0
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

$ bitcoin-cli getblockheader 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
{
  ...
  "height": 0,
  ...
  "bits": "1d00ffff",
  "difficulty": 1,
  ...
}

Wie wir oben sehen können, hat der Genesis-Block eine „1“-Schwierigkeit und „1d00ffff“-Bits. Die Bitcoin-Bits bedeuten den „Ziel“-Hash-Wert, der neu generierte Block muss eine Bedingung erfüllen: Der doppelte SHA-256-Hash-Wert des Block-Headers muss kleiner als dieser „Ziel“-Wert sein.

Der Bitwert '1d00ffff' im Genesis-Block bedeutet den 'Ziel'-Wert:

[0x00000000,0xffff,{0x00..0x00}]
                   {0x00..0x00} at above has 26 bytes 0x00.

Um dann einen neuen Block zu finden, müssen Sie diesen 32-Bit-nNonce-Wert (und auch nTimes und den HashMerkleRoot) durchsuchen, bis der Block-Hash-Wert 4 Bytes führende Nullen aufweist. Übrigens ist nNonce eines der Felder in der Block-Header-Struktur:

 struct header_structure{            // BYTES   NAME
     uint32_t nVersion;              // 4       version
     uint8_t hashPrevBlock[32];      // 32      previous block header hash
     uint8_t hashMerkleRoot[32];     // 32      merkle root hash
     uint32_t nTime;                 // 4       time
     uint32_t nBits;                 // 4       target
     uint32_t nNonce;                // 4       nonce
 };

Da der SHA-256-Algorithmus (sowie jeder kryptografisch sichere Hash-Algorithmus) eine Ausgabe erzeugt, die wie eine gleichmäßig zufällige Sequenz erscheint , ist die praktische „Trial-and-Error“-Methode die einzige Möglichkeit, einen neuen Block zu finden, der die Bedingung erfüllt. Die Wahrscheinlichkeit, einen Block mit dem 4-Byte-Null-führenden Hash-Wert zu finden, beträgt 1/(2^32), was bedeutet, dass die durchschnittlichen Trial-and-Error-Zahlen genau 2^32 (dh 4G) betragen.

Für ein einfaches menschliches Verständnis dieses „Ziel“-Hashwerts definieren wir den Begriff „Schwierigkeit“, was die durchschnittlichen „Trial-and-Error“-Zahlen bedeutet, um einen Block zu finden, der die „Ziel“-Bedingung erfüllt. Und wir definieren die „Schwierigkeit“-Einheit : 1 'Schwierigkeit' = 4G-Hashes

Dann, bis heute, erreicht die Bitcoin-Blockchain-Höhe 501509, werfen wir einen Blick auf die Kopfzeile:

$ bitcoin-cli getblockheader 0000000000000000006c5532f4fd9ee03e07f94df165c556b89c495e97680147
{
  ...
  "height": 501509,
  ...
  "bits": "18009645",
  "difficulty": 1873105475221.611,
  ...
}

Die Bits des Blocks 501509 = 0x18009645, es ist das kompakte Format von 256-Bit-Ganzzahlen, sein 256-Bit-Format ist:

[0x00000000,0x00000000,0x009645,{0x00..0x00}]
                                {0x00..0x00} at above has 21 bytes 0x00.
that is  0x009645 * (256 ^ 21) 
The genesis block's target is  ( 0x00ffff * 256 ^ 26 )which is the difficulty unit '1.0'.
So, the difficulty 
= (0x00ffff * 256 ^ 26)/ (0x009645 * 256 ^ 21)
= 65535/38469 * (256^5)
= 1.703579505575918 * 2^40
= 1873105475221.611

Bisher haben Sie alle Details zur Berechnung der „Schwierigkeit“ kennengelernt. In einigen Fällen verwenden wir auch das einfache Format 1.7T , um die Schwierigkeit anzugeben, im obigen Beispiel:

 (1.703579505575918 * 2^40) = 1.703579505575918T
 1T = 2^40 = 1024^4
1d ist 29 im Dezember (nicht 26). SHS ist SHA
danke @BorisIvanov, der Tippfehler SHSwurde behoben. Aber 1din der Tat bedeutet 26 Bytes Zero Tail statt 29, bitte lesen Sie das oben gezeigte Beispieldetail.
Oh ja. Signifikant

Ich möchte hier meine 2 Cent geben, indem ich die Beziehung zwischen der Wahrscheinlichkeit, einen Block zu minen, wenn das aktuelle Ziel gegeben ist, tund der entsprechenden Schwierigkeit d, wie sie in Bitcoin Core berechnet wird, explizit macht.

Kryptografische Hash-Funktionen werden also durch die zufällige Orakel-Abstraktion [ https://en.wikipedia.org/wiki/Random_oracle] idealisiert . Wir können daher die Ausgabe der doubleSHA256in PoW verwendeten Hash-Funktion als einheitliche Variable im Raum modellieren {0,1}^256, dh Arrays von 256 Bit. Somit ist die Wahrscheinlichkeit, dass ein einzelner Hash hein gültiger Hash ist:

p = P(h < t) = t /( 2^{256} - 1 )

Auf der anderen Seite dwird wie folgt berechnet, so wie @gary vorher erklärt hat, nur in Dezimalzahlen umgewandelt:

d = ( (2^{16} - 1) * 2^{8*26} ) / t = ( (2^{16} -1) * 2^{208} ) / t

Die Implementierung befindet sich in [ https://github.com/bitcoin/bitcoin/blob/master/src/rpc/blockchain.cpp] , Zeile 60, Funktion GetDifficulty. Wenn jemand erklären kann, wie genau der Code der obigen Formel zugeordnet ist, wäre das hilfreich. Wenn wir diese beiden Formeln kombinieren, erhalten wir:

d = ( (2^{16} -1) * 2^{208} ) / ( p * (2^{256} - 1) ) ~ 2^{-32} / p

Bei der Analyse dieses letzten Ausdrucks ist die Schwierigkeit das Verhältnis zwischen der Wahrscheinlichkeit, einen Hash zu erhalten, der kleiner ist als 2^{224}(das ist die niedrigste Dezimalzahl, die eine binäre Darstellung mit 256 Bits hat, beginnend mit 32 Nullbits) und der Wahrscheinlichkeit, einen gültigen Hash basierend auf zu erhalten aktuelles Ziel t. Dies ist eine direkte Auswirkung der Definition im Genesis-Block als Schwierigkeit 1 , die mit dem hexadezimalen Ziel 0x1d00ffff verbunden ist, ausgedrückt in dem, was meiner Meinung nach die 32-Bit-Kompaktform für 256-Bit-Zahlen genannt wird.

Eine nette Frage, wie ich finde, ist, warum gerade diese kompakte Form zur Darstellung des Targets gewählt wurde.

Upvoted! Die kompakte Form liefert 3 höchstwertige Bytes für das Ziel, in der Min-Schwierigkeit sind die 3 höchstwertigen Bytes 00ffff.