Hard Fork

Bezeichnen wir mit V(alt) alle von den ursprünglichen Regeln akzeptierten Blöcke. Ein Hard Fork tritt auf, wenn neue Software mindestens einen Block außerhalb dieser Menge akzeptiert, sodass V(neu) keine Teilmenge von V(alt) ist. Oft geht es darum, die Gültigkeit zu verlängern, aber die Kompatibilität ist entscheidend: Wenn ein Block, der für einen neuen Knoten gültig ist, für einen alten ungültig sein kann, kann der alte Validator der neuen Kette nicht folgen, ohne die Regeln zu ändern.

Der alte Vollknoten kennt oder erkennt die neue Regel nicht. Sobald die aktualisierten Miner einen Block erstellen, der das alte Limit überschreitet oder die neu zulässige Konstruktion verwendet, landet der alte Knoten auf dem letzten für ihn gültigen Block und der nächste Zweig lehnt ab. Es wird nicht außer Kraft gesetzt; es führt deterministisch ein anderes Konsensprogramm aus.

Ein festes Datum, eine feste Blockhöhe oder eine Miner-Signalisierung können diejenigen koordinieren, die das Upgrade akzeptiert haben, können aber nicht die Software eines Knotens ändern, der es nicht akzeptiert hat. Bleiben wirtschaftlich bedeutende Teilnehmer bei beiden Regelwerken, können beide Ketten weitergeführt werden. Der Hard-Fork-Aktivierungsplan ist daher ein Migrationsplan mit dem Risiko einer Spaltung.

Am Teilungspunkt erben beide Zweige denselben vorherigen UTXO-Verlauf. Sie können dann andere Transaktionen bestätigen, andere Limits verwenden und andere Kettenarbeiten rekrutieren. Wenn beide überleben, hat der Inhaber typischerweise einen entsprechenden Anspruch auf Münzen auf beiden Ketten, begrenzt durch spätere Regeln, Wiederholungsschutz und Wallet-Unterstützung. Es handelt sich nicht mehr um einen einzelnen Buchungseintrag.

Der Arbeitsnachweis wählt erst dann zwischen den Zweigen, wenn der Knoten die Blöcke als gültig erkennt. Ein alter Knoten vergleicht niemals einen Chainwork-Zweig, der einen für die alten Regeln ungültigen Block enthält, mit seiner eigenen Kette; Ein solcher Kandidat wird zuerst verworfen. Die Aussage „Die Kette mit der höchsten Hashrate gewinnt“ ist daher ohne Angabe der Validierungsregeln unvollständig.

Die gleiche Signatur und das gleiche Transaktionsformat können dazu führen, dass eine einzelne signierte Transaktion bei der Aufteilung in beiden Netzwerken gültig ist. Das ist Wiederholungsrisiko. Ein Fork kann Schutz, einen anderen Sighash oder ein anderes Adressformat bieten, aber das sind separate Maßnahmen. Der Benutzer muss Netzwerke, Salden, abgeleitete Adressen und Umtauschregeln für Gutschriften und Auszahlungen unterscheiden.

Bitcoin Cash spaltete sich am 1. August 2017 bei 478.559 von Bitcoin ab. Es verabschiedete Regeln, die größere Blöcke als die damals akzeptierten Bitcoin-Knoten erlaubten, und schuf eine eigene fortlaufende Kette. Bitcoin-Knoten lehnten reine BCH-Blöcke ab und BCH-Knoten verfolgten ihren eigenen gültigen Verlauf. Dies ist ein Beispiel für einen Hard Fork, der Bitcoin nicht „vor Ort“ austauschte, sondern ein separates Netzwerk schuf.

Nicht jede unvereinbare Spaltung ist ein bewusstes neues Geldprojekt. Ein Softwarefehler kann zu einer vorübergehenden Nichtübereinstimmung der Implementierungen führen, und ein Fallback kann die Teilnehmer auf einen einzigen Regelsatz zurückführen. Die Bitcoin-Spaltung im März 2013 wurde durch ein unterschiedliches Versionsverhalten rund um Datenbank/Limits verursacht und wurde durch eine koordinierte Rückkehr der Miner zu einem Zweig gelöst, der von älteren 0,7-Knoten akzeptiert wurde; ist nicht identisch mit dem dauerhaft gehaltenen BCH.

Ein Soft Fork schränkt den Gültigkeitssatz ein, sodass V(neu) innerhalb von V(alt) bleibt; Der alte Knoten kann kompatible Blöcke verfolgen, erzwingt jedoch nicht die neue Einschränkung. Ein Hard Fork verfügt nicht über diese einseitige Kompatibilität: Ein neuer gültiger Block kann für einen alten Knoten ungültig sein. Sogar ein Soft Fork kann geteilt werden, wenn die Koordination schlecht ist, aber ein Hard Fork erfordert per Definition direkt eine Migration.

Entwickler können Code veröffentlichen, Miner können die Hash-Rate ändern, Unternehmen können die Ticker- und Einzahlungsregeln auswählen und Benutzer können die Software auswählen. Nichts davon allein setzt den Konsens anderer außer Kraft. Ein dauerhafter Hard Fork liegt vor, wenn genügend unabhängige Teilnehmer beide Regelwerke freiwillig beibehalten und wertschätzen. Die Bezeichnung eines Zweigs als „Upgrade“ ist eine gesellschaftliche Regel und keine Konsensregel.

Der Betreiber muss die Netzwerkidentifikation, das spezifische Release, die Konsensparameter, Peers, die Kettenspitze, den Hash-Block am Fork-Standort und die entsprechenden Versionshinweise oder Prüfpunkte überprüfen. Bei größeren Geldbeträgen empfiehlt es sich, Wallets und Arbeitsabläufe zu trennen, bevor man geforkte Coins ausgibt. Explorer- oder Ticker-Hilfe, ersetzen jedoch nicht den eigenen Validierungsknoten.