Soft Fork

Anna und Pavel überprüfen Bitcoin jeweils auf ihrem eigenen Computer. Anna hat ihre Software aktualisiert, Pavel noch nicht. Nun kommt eine Änderung ähnlich BIP66: Digitale Signaturen, die die Berechtigung zum Ausgeben bestimmter Bitcoins nachweisen, müssen in einem genauer festgelegten Format vorliegen. Einige bisher zulässige Kodierungen werden ausgeschlossen. Eine Zahlung mit gültiger Signatur im nun vorgeschriebenen Format besteht diese Prüfung bei beiden. Verwendet die Signatur dagegen eine früher erlaubte, jetzt verbotene Kodierung, lehnt Anna sie ab, während Pavel sie noch akzeptieren könnte. Dabei setzen wir voraus, dass die Zahlung alle übrigen Regeln erfüllt. Genau darin liegt das Prinzip eines Soft Fork: Neue Regeln verbieten zusätzliche Fälle, ohne etwas zu erlauben, das nach den alten Regeln verboten war. Solange Miner Blöcke erzeugen, die den strengeren Regeln entsprechen, können beide deren Kette weiter verfolgen. Pavel prüft die zusätzliche Bedingung jedoch nicht selbst. Ein Soft Fork ermöglicht somit Änderungen, ohne dass alle Nodes gleichzeitig aktualisiert werden müssen. Alte Software prüft dadurch aber nicht genauso umfassend wie neue, und eine zweite Währung entsteht nicht automatisch. [1] [6]

Ein Full Node ist ein Computer, der Bitcoins Regeln selbstständig prüft. Bei der Auswahl zwischen gültigen Zweigen vergleicht er die durch Mining nachgewiesene Gesamtarbeit, nicht die Stimmen ihrer Unterstützer. Ein alter Full Node kann der Kette folgen, weil aktualisierte Miner normalerweise für ihn gültige Blöcke erzeugen. Die Zusatzbedingung prüft er aber nicht. Eine Kette mit mehr angesammelter Arbeit kann er auch dann annehmen, wenn sie die neue Regel verletzt; aktualisierte Knoten lehnen sie dagegen ab. Wer die neue Garantie benötigt, muss die eigene Prüfsoftware aktualisieren. Zahlungen empfangen, Adressen verstehen und alle Konsensregeln prüfen sind verschiedene Fähigkeiten. [1] [12]

Ein BIP ist ein nummerierter technischer Vorschlag. Seine Veröffentlichung verändert das Netzwerk noch nicht: Software muss entwickelt und geprüft werden, und ihre Nutzer entscheiden, ob sie sie einsetzen. Das Mainnet ist das Hauptnetz von Bitcoin, in dem echte Bitcoins übertragen werden. Die Aktivierung legt fest, ab wann aktualisierte Knoten dort die neue Regel durchsetzen. Code im Programm zu haben ist also etwas anderes, als ihn bei der Blockprüfung anzuwenden. Bei den hier beschriebenen Verfahren bedeutet Lock-in, dass die Voraussetzung für eine spätere Aktivierung erfüllt ist; die Regel muss deshalb noch nicht gelten. Erst im Zustand ACTIVE prüft der Knoten sie. Den Zustand leitet er aus früheren Blöcken seines eigenen Zweigs ab. Ändert eine Reorganisation diese Vorgeschichte nahe der Aktivierungsgrenze, kann sich auch der berechnete Zustand ändern. Zwei Programme mit unterschiedlichen Aktivierungsparametern können daher zum selben Zeitpunkt unterschiedliche Blöcke akzeptieren. [2] [15]

Ein Miner baut seinen Block auf einem Vorgängerblock auf, auch Elternblock genannt. Prüft er diesen nicht, arbeitet er womöglich vergeblich an einem Zweig, den andere Nodes ablehnen. Im Juli 2015 signalisierten einige Miner BIP66, prüften jedoch den Elternblock unzureichend. Sie bauten auf einem ungültigen Block weiter und erzeugten am 4. Juli einen sechs Blöcke langen ungültigen Zweig; am Folgetag entstand ein weiterer. Aktualisierte validierende Nodes lehnten beide ab. Ein Versionssignal ist eine Behauptung, kein Beweis dafür, dass der Miner den vorbereiteten Block, seinen Vorgänger und die enthaltenen Transaktionen selbst geprüft hat. [6] [14]

Wer wissen möchte, welche Regeln der eigene Knoten tatsächlich anwendet, beginnt bei dessen Softwareversion und eigenen Auskünften. Je nach Version liefern getdeploymentinfo und getblockchaininfo Informationen über eingeführte Änderungen und die Blockchain. Zusammen mit der Dokumentation der jeweiligen Version, der Aktivierungshöhe und den Protokolldateien helfen sie, eine vorbereitete von einer bereits aktiven Regel zu unterscheiden. Ein Blockexplorer im Web zeigt dagegen die Sicht eines anderen Dienstes. Er belegt nicht, was der eigene Computer prüft. Die Hashrate misst die Rechenleistung des Minings. Sie berechtigt Miner nicht, die Regeln Ihres Knotens zu umgehen: Im Zustand ACTIVE lehnt ein aktualisierter Knoten einen Block ab, der gegen die neue Bedingung verstößt, auch wenn die Mehrheit der Rechenleistung dahintersteht. Ob eine Aufspaltung bestehen bleibt, hängt auch von der angesammelten Arbeit der Zweige und ihrer wirtschaftlichen Nutzung ab. Das bloße Entfernen einer aktiven Einschränkung würde bisher ungültige Blöcke wieder erlauben und wäre deshalb ein Hard Fork. Vor der Aktivierung lassen sich Parameter durch eine abgestimmte Softwareversion ändern. Aber auch diese Änderung installiert sich nicht von selbst auf fremden Knoten. [1] [15] [16]

V(alt) enthält alle vor dem Upgrade akzeptierten Blöcke. Nur wenn V(neu) darin liegt, handelt es sich um einen Soft Fork: neue Nodes verwerfen zusätzliche Fälle, während jeder neu gültige Block alte Prüfungen besteht. Der Begriff bezeichnet Regelkompatibilität, nicht geringe Tragweite, Sicherheit oder sozialen Konsens. Ein für alte Nodes sichtbares Limit zu erhöhen oder eine früher ungültige Ausgabe zu erlauben erweitert die Menge und verlangt gewöhnlich einen Hard Fork. [1] [17]

Strengere Regeln können auch neue Funktionen ermöglichen. BIP66 präzisierte DER, das Format zur Kodierung von Signaturdaten. BIP65 und BIP112 ergänzten ausgewählte NOP-Befehle, die zuvor nichts erzwangen, um zeitliche Ausgabebedingungen. SegWit führte Witness-Programme und Prüfdaten namens Witness ein, darunter Signaturen. Taproot nutzte später die reservierte Version 1. Ältere Nodes prüfen die jeweiligen neuen Bedingungen nicht. Anyone-can-spend beschreibt diese eingeschränkte Sicht, nicht eine Möglichkeit, aktualisierte Nodes zu umgehen und fremde Coins auszugeben. SegWit bindet Witness-Daten außerdem über ein Witness Commitment kryptografisch an den Block. Diese Bindung steht in der Coinbase-Transaktion, der ersten Transaktion mit der Belohnung für den Miner, und bewahrt die Kompatibilität mit den bisherigen Regeln des Basisblocks. [6] [5] [7] [8] [12]

Ein Bit hat den Wert 0 oder 1. Im Feld nVersion, das die Version im Blockheader festhält, können einzelne Bits die Bereitschaft eines Miners signalisieren. BIP9 ordnet jeder Einführung einen Namen, ein bestimmtes Bit, einen Startzeitpunkt und eine Frist zu. Das ursprüngliche Mainnet-Verfahren wertet Abschnitte von 2016 Blöcken aus. Signalisieren im Zustand STARTED mindestens 1916 Blöcke, also 95 %, wechselt der nächste Abschnitt zu LOCKED_IN. Nach einer weiteren Warteperiode folgt ACTIVE. Wird die Bedingung nicht rechtzeitig erfüllt, kann das Verfahren in FAILED enden. Der Anfangszustand vor dem Start heißt DEFINED. Jeder Knoten berechnet diese Zustandsfolge aus früheren Blöcken. Das eigene nVersion eines Blocks entscheidet daher nicht, ob die neue Regel für ihn gilt. Die Signale helfen, den Übergang zu koordinieren; sie sind keine Abstimmung über die Gültigkeit einzelner Blöcke. Nach dem Lock-in ändern spätere Signale das Ergebnis dieses Verfahrens nicht mehr. [2]

Mit Versionbits können Miner Bereitschaft signalisieren, aber nicht die Regeln anderer Nodes umschreiben. BIP8 verwendet Blockhöhen statt Zeitgrenzen. Ist lockinontimeout auf true gesetzt und noch kein Lock-in erreicht, kann die letzte Periode in MUST_SIGNAL mit verpflichtender Signalisierung übergehen. BIP148 verlangte von teilnehmenden Nodes, Blöcke ohne SegWit-Signal abzulehnen; BIP91 nutzte eine niedrigere Schwelle für Miner-Signale, um den Übergang zu koordinieren. Weichen Regeldurchsetzung, Hashrate und wirtschaftliche Akzeptanz voneinander ab, kann sich die Kette spalten. Die Wahl des Aktivierungsverfahrens erfordert deshalb Sicherheitsabwägungen. [11] [9] [10] [17]

P2SH (BIP16) erlaubt es, Geld an den Hash eines Skripts zu senden, also eines Programms mit Bedingungen für das spätere Ausgeben. Bei der Einführung 2012 halfen Signale in Coinbase-Transaktionen dabei, die Bereitschaft der Miner einzuschätzen. Die neuen Prüfungen galten jedoch ab einer festgelegten Grenze für Blockzeitstempel; Signale ersetzten keine Prüfung. Die Coinbase ist die erste Transaktion eines Blocks und enthält die Vergütung des Miners. Spätere Änderungen verwendeten Blockversionen und Signalschwellen. BIP34 schrieb vor, die Blockhöhe, also die Position in der Kette, in der Coinbase festzuhalten. BIP66 verschärfte das DER-Format der Signaturen; BIP65 führte mit CHECKLOCKTIMEVERIFY eine Prüfung des frühesten Zeitpunkts oder der frühesten Höhe für eine Ausgabe ein. Das fortlaufende Erhöhen der Versionsnummer erschwerte die parallele Einführung unabhängiger Änderungen. BIP9 brachte deshalb getrennte Bits. BIP68, BIP112 und BIP113 wurden 2016 gemeinsam auf Höhe 419328 aktiviert, betreffen aber unterschiedliche Zeitbedingungen. BIP68 führt eine relative Wartezeit ab der Bestätigung des ausgegebenen Outputs ein. BIP112 lässt Skripte diese Wartezeit über CHECKSEQUENCEVERIFY, kurz CSV, verlangen. BIP113 ändert dagegen die Zeitbasis für eine absolute Zeitsperre: Statt des Zeitstempels des geprüften Blocks wird Median Time Past verwendet, der Median der Zeitstempel der vorherigen 11 Blöcke. Die gemeinsame Aktivierung bedeutet also nicht, dass alle drei Vorschläge dieselbe relative Sperre einführen. [3] [4] [5] [6] [7] [18] [19] [20]

SegWit wurde im August 2017 auf Höhe 481824 aktiviert. Es trennte Witness-Prüfdaten wie Signaturen von dem Teil der Transaktion, aus dem ihre Kennung txid berechnet wird. Warum ist das wichtig? Bei der älteren Kodierung konnte jemand die Darstellung einer Signatur und damit die Transaktionskennung ändern, ohne Empfänger oder Betrag zu ändern. Diese Möglichkeit heißt Malleability. Eine Änderung allein der Witness-Daten ändert die txid nicht. Inputs, die weiterhin das ältere Format verwenden, werden damit allerdings nicht repariert. Ein alter Knoten sieht die Transaktion ohne Witness-Daten und behandelt ein Witness-Programm der Version v0 als anyone-can-spend. Ein aktualisierter Knoten prüft zusätzlich den Witness und den Signatur-Digest, den Fingerabdruck der signierten Daten. Das Witness Commitment in einem Coinbase-Output bindet die Witness-Daten kryptografisch an den Block. Eine vollständige Prüfung kann dadurch Änderungen oder fehlende Daten erkennen. Weight, die Gewichtung der Daten beim Anrechnen auf die Blockkapazität, erhöhte die nutzbare Kapazität. Der für alte Knoten sichtbare Basisblock blieb dabei innerhalb der bisherigen Grenze von einem Megabyte. [8]

Beim Key-Path genügt eine passende Signatur zum Ausgabeschlüssel; beim Script-Path werden Bedingungen eines offengelegten Skripts erfüllt. Schnorr ist ein Signaturverfahren, Tapscript die Sprache dieser Skripte. BIP341 und BIP342 definieren Key-Path- und Script-Path-Ausgaben mit Schnorr-Signaturen und Tapscript für native SegWit-Outputs mit einem 32 Byte langen Witness-Programm der Version 1. Alte Nodes sehen weiterhin anyone-can-spend: Kompatibilität bleibt, volle Prüfung nicht. Speedy Trial nutzte modifiziertes BIP9 mit 1815 von 2016 Signalen (90 %) und Mindesthöhe 709632. Dort wurde Taproot am 14. November 2021 aktiv. Regeln und Aktivierungsweg sind getrennt zu beurteilen. [12] [13] [16]