Zum Inhalt springen
Financial Context Wiki

Bitcoins Schwierigkeitsanpassung: Zielwerte, Retargeting und Grenzen

Bitcoin passt seinen Proof-of-Work-Schwellenwert alle 2.016 Blöcke an, um das langfristige mittlere Blockintervall in Richtung zehn Minuten zu steuern. Zielwert, Kompaktkodierung, Zeitstempelfenster, Begrenzung, Netzwerkregeln und Wahrscheinlichkeitsaussagen sind getrennt zu prüfen.

Aktualisiert

Nur zur protokollanalytischen Bildung. Ein angezeigter Schwierigkeitsgrad, eine Hashrate-Schätzung oder eine Retargeting-Prognose belegt für sich weder Rentabilität noch Bestätigungssicherheit, Dezentralisierung oder künftige Netzwerkbedingungen.

Direkte Antwort

Bitcoins Schwierigkeitsanpassung ist eine deterministische Konsensregel, die den größten zulässigen Proof-of-Work-Hash, den target oder Zielwert, periodisch ändert. So soll das langfristige mittlere Blockintervall bei veränderter aktiver Hashrate gegen zehn Minuten gesteuert werden. Im Mainnet bleibt der Zielwert gewöhnlich 2.016 Blöcke lang fest und wird für die nächste Periode neu berechnet. Jeder validierende Knoten leitet denselben vorgeschriebenen Wert aus früheren Headern ab; Miner stimmen nicht darüber ab und ein Explorer setzt ihn nicht.

Der Proof of Work eines Blockheaders ist nur gültig, wenn sein als Ganzzahl interpretierter Hash kleiner oder gleich dem im 32-Bit-Feld nBits kodierten Zielwert ist. Ein kleinerer Zielwert lässt weniger Hashes zu und verlangt mehr erwartete Versuche. Üblicherweise ist Schwierigkeit eine zum Zielwert umgekehrt proportionale relative Zahl:

D = T₁ / T

Dabei ist T der aktuelle Zielwert und T₁ der Referenzwert für Schwierigkeit 1. Zielwert und Schwierigkeit bewegen sich daher gegenläufig. Keiner von beiden misst Maschinen, Energieverbrauch, Mineridentitäten oder beobachtete Hashrate direkt.

Zehn Minuten sind ein Erwartungswert, kein Zeitplan. Hashversuche und Blockankünfte sind zufällig; selbst bei stabiler Hashrate und stabilem Ziel können zwei Blöcke Sekunden auseinanderliegen oder eine Stunde lang kein Block erscheinen. Retargeting ist verzögerte Rückkopplung über eine Periode: Es reduziert anhaltende Abweichungen der Blockfrequenz, beseitigt aber keine kurzfristige Streuung und reagiert nicht sofort auf einen Hashrate-Schock.

Die Anpassung beeinflusst den zeitlichen Takt höhenbasierter Ereignisse wie Subventionshalbierungen, definiert aber weder Subventionsbeträge noch das Intervall von 210.000 Blöcken oder die endgültige Angebotsregel. Sie wählt auch nicht allein die kanonische Kette. Bitcoins Fork Choice vergleicht nach Validierung von Headern und Blöcken die kumulierte Chainwork; der Schwierigkeitswert eines einzelnen Blocks ist keine kumulierte Arbeit.

Retargeting analysieren

  1. Netzwerk und Regeln festlegen. Mainnet, altes Testnet, Testnet4, Signet und Regtest teilen nicht alle Ausnahmen. Erfassen Sie Kette, Software-Regelwerk, Kandidatenhöhe sowie die Aktivierung von Retargeting oder besonderen Mindestschwierigkeitsblöcken.
  2. Behaupteten Zielwert dekodieren. Entfalten Sie das kompakte nBits des Kandidatenheaders zum Zielwert T. Negative, nullwertige, überlaufende oder über powLimit liegende Ziele sind abzulehnen; der Headerhash muss ≤ T sein.
  3. Periodengrenze bestimmen. Im Mainnet ist ein neuer Zielwert erforderlich, wenn die Kandidatenhöhe durch 2.016 teilbar ist. An anderen Höhen muss das nBits des vorherigen Blocks unverändert fortgeführt werden.
  4. Zeitstempelfenster wählen. An einer Mainnet-Grenze zieht Bitcoin Core den Zeitstempel des ersten Blocks der vorigen 2.016-Block-Periode von dem des letzten ab. Die Endpunkte umfassen 2.016 Blöcke, aber nur 2.015 Zwischenräume. Die nominelle Zielspanne bleibt dennoch 2,016 × 600 = 1,209,600 Sekunden.
  5. Verstrichene Zeit begrenzen. Setzen Sie t = clamp(t_actual, 302,400, 4,838,400) Sekunden, also ein Viertel bis das Vierfache der nominellen 14 Tage. Header-Zeitstempel sind von Minern gelieferte Konsensfelder mit weiteren Gültigkeitsregeln, nicht die exakten Empfangszeiten eines Knotens.
  6. Neuen Zielwert berechnen und kodieren. Nach aktuellen Mainnet-Regeln wird ganzzahlig T_new = min(powLimit, T_old × t / 1,209,600) berechnet und kompakt als nBits kodiert. Ganzzahldivision und Kompaktrundung können angezeigte Verhältnisse leicht von idealer Dezimalrechnung abweichen lassen.
  7. Ergebnis probabilistisch deuten. Näherungsweise gilt D_new / D_old = T_old / T_new. Vergleichen Sie das Retarget mit Blockzeitverteilungen und einer klar als Schätzung bezeichneten Hashrate; trennen Sie es von Aussagen zu Ertrag, Chainwork, Konzentration und Bestätigungsrisiko.

Die Mainnet-Formel nutzt den Zielwert des letzten Blocks als T_old. Testnet4 ist absichtlich anders: BIP 94 erlaubt nach einem ausreichend späten Zeitstempel einen besonderen Mindestschwierigkeitsblock, verbietet die Ausnahme für den ersten Block einer Periode und stützt das Retarget auf dessen echte Schwierigkeit, damit eine temporäre Ausnahme die nächste Periode nicht verunreinigt. Regtest deaktiviert Retargeting gewöhnlich. Eine Regelbeschreibung ohne Netzwerkangabe ist unvollständig.

Rechenbeispiele

1. Unveränderte nominelle Periode

Angenommen, T_old = 10 in beliebigen Zieleinheiten und die gemessene Spanne beträgt genau 1,209,600 Sekunden. Die Begrenzung ändert nichts:

T_new = 10 × 1,209,600 / 1,209,600 = 10

Das Schwierigkeitsverhältnis ist 10 / 10 = 1; die idealisierte Schwierigkeit bleibt gleich. Das bedeutet nicht, dass jeder Block zehn Minuten dauerte: zufällige schnelle und langsame Intervalle können sich ausgleichen.

2. Schnelle Zwölf-Tage-Periode

Die Endzeitstempel seien zwölf Tage auseinander. Zwölf Tage liegen innerhalb der Grenzen, daher beträgt das Zielverhältnis 12 / 14 = 6/7. Der neue Zielwert entspricht etwa 85,7143 % des alten, während:

D_new / D_old ≈ 14 / 12 = 1.166667

Die idealisierte Schwierigkeit steigt also um etwa 16,67 %, nicht um 14,29 %. Prozentuale Zielsenkung und Schwierigkeitserhöhung unterscheiden sich, weil die Größen reziprok sind.

3. Vierfache Begrenzung

Liegen die Zeitstempel nur 1,75 Tage auseinander, nutzt die Rechnung das Minimum von 3,5 Tagen. Der Zielwert kann ungefähr auf ein Viertel fallen und die Schwierigkeit in einem Mainnet-Retarget ungefähr auf das Vierfache steigen.

Umspannen die Zeitstempel 70 Tage, wird das Maximum von 56 Tagen benutzt. Das Ziel kann ungefähr auf das Vierfache steigen und die Schwierigkeit auf ein Viertel fallen, sofern powLimit das Ziel nicht früher deckelt. „Vierfache Grenze“ muss Ziel oder Schwierigkeit sowie die Richtung benennen.

4. Hashrate-Schock in der Periodenmitte

Nehmen wir vereinfacht an, dass die ersten 1.008 Blöcke mit einer zu zehn Minuten passenden Rate in etwa sieben Tagen entstehen. Dann verschwinden bei festem Ziel 30 % der Hashrate. Die verbleibenden 70 % hätten ein erwartetes Intervall von 10 / 0.70 ≈ 14.286 Minuten; die letzten 1.008 Blöcke dauern rund zehn Tage und die Gesamtperiode rund 17.

Ohne Endpunkt-, Zufalls- und Kompaktrundungseffekte beträgt der Zielmultiplikator 17/14 ≈ 1.214286, der Schwierigkeitsmultiplikator 14/17 ≈ 0.823529: ein Rückgang von etwa 17,65 %. Es sind nicht volle 30 %, weil der Schock nur die halbe Periode betraf. Bleibt die Hashrate bei 70 %, sind Blöcke auch nach dieser Teilanpassung langsamer als zehn Minuten zu erwarten und die nächste Periode liefert weitere Rückkopplung.

Risiken und Prüfungsfehler

Regel- und Rechenfehler

  • Schwierigkeit als Schwelle selbst bezeichnen, statt Zielwert und dessen inverse relative Kennzahl zu unterscheiden.
  • Die Formel umkehren, sodass eine schnelle Periode das Ziel oder eine langsame die Schwierigkeit erhöht.
  • 2.016 Blöcke als 2.016 gemessene Zeitstempelintervalle behandeln; die aktuelle Mainnet-Rechnung umfasst 2.015 Intervalle.
  • Die Grenzen von 3,5 und 56 Tagen, powLimit, Ganzzahldivision oder Rundung des kompakten nBits vergessen.
  • Eine Mainnet-Aussage auf Testnet4, altes Testnet, Signet, Regtest oder eine andere Proof-of-Work-Kette übertragen.
  • Eine Explorer-Prognose vor dem Grenzblock als Konsenseingabe statt als Schätzung ansehen.
  • Lokale Empfangszeiten statt der von der Konsensrechnung verwendeten Header-Zeitstempel einsetzen.
  • Aktuelle Blockschwierigkeit mit Blockarbeit, kumulierter Chainwork oder Fork-Choice-Ergebnis verwechseln.

Messung und Schlussfolgerung

  • Geschätzte Hashrate als direktes Verzeichnis aktiver Maschinen statt als Schluss aus Arbeit und zufälligen Ankünften betrachten.
  • Ein Retarget aus einem kleinen Periodenanteil extrapolieren, in dem normale Blockzeitstreuung dominieren kann.
  • Einen Schwierigkeitsanstieg als Beleg für Preis-, Minererlös-, Energie- oder Dezentralisierungsanstieg lesen.
  • Einen Rückgang ohne Prüfung absoluter Arbeit, Konzentration und Dauer als Netzwerkausfall deuten.
  • Schwierigkeitszahlen zwischen Ketten ohne Normierung von Hashfunktion, Referenzziel und Anpassungsregeln vergleichen.
  • Zehn Minuten als Frist, Servicegarantie oder feste Bestätigungszeit beschreiben.
  • Miner-Rentabilität ohne Blockertrag, Gebühren, Verfügbarkeit, Poolbedingungen, Absicherung, Strom, Finanzierung und Effizienz ableiten.

Sicherheit und Betrieb

  • Retargeting als Sofortschutz gegen abrupten Hashrate-Zu- oder -Abfluss innerhalb der laufenden Periode behandeln.
  • Annehmen, geringere Schwierigkeit erhöhe Blockkapazität oder räume einen Transaktionsstau sofort.
  • Eine Bestätigungspolitik nur aus Schwierigkeit wählen und kumulierte Arbeit, Reorganisationsfähigkeit und Wert ignorieren.
  • Bei Anpassungsmechanismen Anreize zur Zeitstempelmanipulation und protokollspezifische Gegenmaßnahmen übersehen.
  • Konsensarithmetik, Grenzindizierung oder Kompaktkodierung ohne implementierungsübergreifende Vektoren und Aktivierungsplan ändern.

Häufige Missverständnisse

  • Jeder Bitcoin-Block dauert zehn Minuten. Zehn Minuten sind der Zielmittelwert bei passender Hashrate; einzelne Ankünfte bleiben zufällig.
  • Miner stimmen über die nächste Schwierigkeit ab. Validierende Knoten berechnen das zulässige nBits selbst; ein Block mit anderem Wert ist ungültig.
  • Ein um 20 % kleineres Ziel bedeutet 20 % höhere Schwierigkeit. Die Beziehung ist invers: Zielmultiplikator 0,8 ergibt Schwierigkeit 1/0.8 = 1.25, also 25 % mehr.
  • Das Retarget misst die Hashrate direkt. Es reagiert auf zeitgestempelte Blockproduktion; jede Hashrate-Zahl ist eine Schätzung mit Stichproben- und Zeitannahmen.
  • Schwierigkeit ist Bitcoins Geldpolitik. Retargeting stabilisiert den zeitlichen Takt höhenbasierter Ausgabe; getrennte Konsensregeln definieren Subventionswerte und Halbierungen.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...