Soft Fork

Markieren wir mit V(alt) alle Blöcke, die vor dem Upgrade von den Regeln akzeptiert wurden. Die Änderung ist nur dann ein Soft Fork, wenn V(neu) innerhalb von V(alt) liegt: Der neue Knoten lehnt die nächste Blockklasse ab, aber ein Block, der den neuen Regeln entspricht, besteht auch die alten Prüfungen. Der Name spricht für die Kompatibilität der Gültigkeitsregeln, nicht für die Größe, Sicherheit oder soziale Verträglichkeit der Änderung. Das Erhöhen des für einen alten Knoten sichtbaren Limits oder das Zulassen einer zuvor ungültigen Ausgabe erweitert den Pool und erfordert normalerweise einen Hard Fork. [Bitcoin-Entwicklerhandbuch – Änderungen der Konsensregeln] [Bitcoin Optech – Soft-Fork-Aktivierung]

Ein alter vollständiger Knoten kann der Kette weiterhin folgen, da aktualisierte Miner routinemäßig Blöcke erstellen, die er erkennt. Die hinzugefügte Bedingung wird jedoch nicht überprüft. Wenn ein Zweig mit mehr Arbeit gegen die neue Regel verstößt, kann der alte Knoten dies akzeptieren, während der aktualisierte Knoten sie ablehnt. Wer eine neue Garantie benötigt, muss seine eigene Validierungssoftware aktualisieren; Die Fähigkeit einer Wallet, Zahlungen zu akzeptieren, Formatkompatibilität und vollständige Konsensvalidierung sind verschiedene Dinge. [Bitcoin-Entwicklerhandbuch – Änderungen der Konsensregeln] [BIP 341 – Taproot-Bereitstellung]

Bitcoin hat mithilfe mehrerer Techniken Teilmengen erstellt. BIP66 verbot die nicht strengen DER-Signaturen, die die alten Regeln akzeptierten. BIP65 und BIP112 fügten Bedingungen zu NOP-Opcodes hinzu, die der alte Interpreter als erfolgreiches Nichtstun betrachtete. SegWit und Taproot gaben reservierten Versionen des Witness-Programms Bedeutung, die nach Ansicht des alten Knotens von jedem ausgegeben werden können. Gleichzeitig muss die Gestaltung eine Umgehung der neuen Regelung verhindern; SegWit übermittelte daher Zeugendaten über Coinbase und behielt die alten grundlegenden Blockregeln bei. [BIP 66 – Strikte DER-Signaturen] [BIP 65 – CHECKLOCKTIMEVERIFY] [BIP 112 – CHECKSEQUENCEVERIFY] [BIP 141 – Segregated Witness] [BIP 341 – Taproot-Bereitstellung]

Code kann eine inaktive Regel enthalten, lange bevor sie im Mainnet wirksam wird. BIP und geprüfte Implementierung sind keine Bereitstellungen, Bereitstellungsparameter sind kein Lock-in, Lock-in plant nur die zukünftige Durchsetzung und nur der ACTIVE-Status bedeutet die Überprüfung des angegebenen Blocks. Jeder Knoten berechnet den Status aus den Vorfahren seines eigenen Zweigs. Durch eine Neuorganisation an der Grenze kann es zu einer Neuberechnung kommen, und Software mit anderen Parametern beginnt möglicherweise damit, inkompatible Regeln durchzusetzen. [BIP 9 – Versionsbits mit Timeout und Verzögerung] [Bitcoin Core – versionbits.cpp]

BIP9 weist der Bereitstellung einen Namen, eine Bitversion, eine Startzeit und ein Timeout zu. Die ursprüngliche Mainnet-Variante wertet Perioden nach 2.016 Blöcken aus: Nach mindestens 1.916 Signalisierungsblöcken, also 95 %, geht es von STARTED nach LOCKED_IN, wartet eine Periode und ist dann ACTIVE; andernfalls kann es sein, dass der Vorgang fehlschlägt. Die vollständige Sequenz ist DEFINED, STARTED, LOCKED_IN, ACTIVE und FAILED. Der Zustand eines Blocks hängt von seinen Vorfahren ab, nicht von seiner eigenen nVersion, und die Signalisierung nach dem Lock-in ändert das Ergebnis nicht mehr. [BIP 9 – Versionsbits mit Timeout und Verzögerung]

Versionsbits zeigen die Bereitschaft des Miners an und koordinieren den Übergang; Sie gewähren den Bergleuten kein dauerhaftes Eigentum am Konsens. BIP8 verwendet Höhen und kann mit lockinontimeout die Signalisierung im letzten Fenster erzwingen. BIP148 hingegen befahl den teilnehmenden Knoten, Nicht-SegWit-Signalisierungsblöcke abzulehnen; BIP91 senkte die Bergbauschwelle, um diesem Druck gerecht zu werden. Eine obligatorische Aktivierung kann die Kette spalten, wenn Knoten, Hash-Rate und wirtschaftliche Akzeptanz voneinander abweichen, sodass selbst die Aktivierungsmethode ein Sicherheitsrisiko darstellt. [BIP 8 – Versionsbits mit Sperrung nach Höhe] [BIP 148 – Obligatorische Aktivierung von SegWit] [BIP 91 – SegWit MASF mit reduziertem Schwellenwert] [Bitcoin Optech – Soft-Fork-Aktivierung]

P2SH unter BIP16 wurde 2012 durch Coinbase-Signalisierung und Zeitlimit aktiviert. BIP34 verwendete die Blockversion und den Schwellenwert für die obligatorische Höhe in Coinbase. Die gleiche Integer-Prozedur führte striktes DER in BIP66 und CHECKLOCKTIMEVERIFY in BIP65 aus, verbrauchte jedoch Versionswerte und konnte keine gleichzeitigen Bereitstellungen durchführen. BIP9 führte daher unabhängige Bits ein. BIP68, BIP112 und BIP113 wurden dann 2016 gemeinsam als relative Locktime und CSV bei der Höhe 419.328 aktiviert. [BIP 16 – Pay to Script Hash] [BIP 34 – Block v2, Höhe in Coinbase] [BIP 65 – CHECKLOCKTIMEVERIFY] [BIP 66 – Strenge DER-Signaturen] [BIP 112 – CHECKSEQUENCEVERIFY]

SegWit wurde im August 2017 bei 481.824 aktiviert. Ein alter Knoten sieht eine Transaktion ohne Zeugendaten und betrachtet Zeuge v0 als jeder, der etwas ausgeben kann; Aktualisierter Prüfzeuge, neuer Signatur-Digest und Anti-Formbarkeitsregeln. Merkles Verpflichtung, Daten in der Coinbase-Ausgabe zu beobachten, verhindert, dass ein Miner unbemerkt Daten ändert oder weglässt. Durch die Gewichtungsabrechnung wurde die effektive Kapazität erhöht, ohne dass der zugrunde liegende Block, der für den alten Knoten sichtbar war, die alte Grenze von einem Megabyte überschritt. [BIP 141 – Getrennter Zeuge]

BIP341 und BIP342 bezeugen die Ausgabe von Schlüsselpfaden und Skriptpfaden der Version 1 mit Schnorr-Signaturen und Tapscript. Der alte Knoten behandelt das reservierte Programm erneut als etwas, das jeder ausgeben kann: Die Teilmenge bleibt erhalten, die vollständige Validierung jedoch nicht. Das Mainnet verwendete eine modifizierte BIP9 Speedy Trial mit einem Schwellenwert von 1.815 von 2.016 Blöcken oder 90 % und einer minimalen Aktivierungshöhe von 709.632. Taproot wurde darin am 14. November 2021 aktiviert; Die Regeln von Taproot und wie man sie aktiviert, sind zwei separate Prüffragen. [BIP 341 – Taproot-Bereitstellung] [BIP 342 – Tapscript] [Bitcoin Core 0.21.1 Versionshinweise – Taproot-Bereitstellung]

Als BIP66 im Juli 2015 aktiviert wurde, signalisierten einige Miner die neue Version, validierten jedoch den übergeordneten Block, auf dem sie schürfen, nicht ausreichend. Sie erweiterten den ungültigen Block und erstellten am 4. Juli einen ungültigen Zweig mit sechs Blöcken. Am nächsten Tag folgte ein weiterer kürzerer Vorfall. Aktualisierte Validierungsknoten haben beide Zweige abgelehnt. Die Versionsnummer oder das Bit ist eine Behauptung des Miners und kein Beweis dafür, dass er selbst die Vorlage, die Eltern und die Transaktionen überprüft hat. [BIP 66 – Strikte DER-Signaturen] [Bitcoin.org – Juli 2015 BIP66 Chain Fork Alert]

Im Status ACTIVE lehnen aktualisierte Knoten den fehlerhaften Block unabhängig vom Hash-Raten-Anteil ab; Ob eine dauerhafte Teilung entsteht, hängt von der Arbeit der Zweigniederlassungen und ihrer wirtschaftlichen Nutzung ab. Eine einfache Aufhebung der Einschränkung würde die heutigen ungültigen Blöcke wieder aktivieren und ist daher ein Hard Fork; Parameter oder Code können vor der Aktivierung durch eine koordinierte Freigabe ersetzt werden. Der Betreiber überprüft seine eigene Version, getdeploymentinfo oder getblockchaininfo, genaue Parameter, Aktivierungshöhe und Protokolle. Weder das Signaldiagramm noch das Explorer-Label können die lokale Validierung ersetzen. [Bitcoin-Entwicklerhandbuch – Änderungen der Konsensregeln] [Bitcoin Core – versionbits.cpp] [Versionshinweise zu Bitcoin Core 0.21.1 – Taproot-Bereitstellung]