Soft Fork und Hard Fork

Inhalt

• Was ist ein Fork und warum kann es überhaupt zu einem Fork kommen?
  • Warum können sich diese Regeln ändern?
• Was passiert, wenn sich die Konsensregeln ändern?
• Was ist ein Soft Fork und warum bleiben die neuen Regeln kompatibel?
• Warum können alte Nodes neue Soft-Fork-Blöcke weiterhin akzeptieren?
• Was passiert, wenn Miner die neuen Regeln nicht anwenden?
• Was ist ein Hard Fork und warum sind die neuen Regeln nicht abwärtskompatibel?
  • Der Unterschied zum Soft Fork
• Wann führt eine Regeländerung tatsächlich zu einer Aufspaltung der Blockchain?
• Warum verhindert ein Soft Fork nicht automatisch eine vorübergehende Chain Split?
• Warum führt ein Hard Fork nicht automatisch zu zwei dauerhaften Blockchains?
  • Was passiert, wenn fast alle auf die neuen Regeln wechseln?
  • Was passiert, wenn beide Seiten weitergeführt werden?
• Wie wird ein neuer Soft Fork im Bitcoin-Netzwerk aktiviert?
  • Warum braucht ein Soft Fork überhaupt eine Aktivierung?
  • Wie kann die Aktivierung festgelegt werden?
  • Aktivierung bedeutet Durchsetzung
• Welche Rolle spielt die Signalisierung der Miner bei einem Soft Fork?
  • Warum signalisieren Miner überhaupt?
  • Signalisierung ist keine Abstimmung über die Konsensregeln
• Wer setzt die neuen Konsensregeln im Bitcoin-Netzwerk tatsächlich durch?
  • Welche Rolle spielen die Miner?
  • Welche Rolle spielen die Entwickler?
• Was ist der entscheidende Unterschied zwischen Soft Fork und Hard Fork?
  • Soft Fork und Hard Fork im direkten Vergleich
• Soft-Forks in der Geschichte von Bitcoin
  • Aktivierte Soft Forks
    • 2012 – P2SH (BIP16)
    • 2013 – BIP34
    • 2015 – BIP66
    • 2015 – CLTV (BIP65)
    • 2016 – CSV (BIP68, BIP112, BIP113)
    • 2017 – SegWit (BIP141 u. a.)
    • 2021 – Taproot (BIP341, BIP342)
  • Vorgeschlagene, aber bisher nicht aktivierte Soft Forks
    • BIP54 – Consensus Cleanup
    • BIP110 – Reduced Data Temporary Softfork
    • BIP118 – SIGHASH_ANYPREVOUT
    • BIP119 – CHECKTEMPLATEVERIFY
    • BIP347 – OP_CAT in Tapscript
• Hard Forks und Konsensprobleme in der Geschichte von Bitcoin
  • Bewusste Hard Forks
    • 2017 – Bitcoin Cash
    • 2018 – Bitcoin SV
  • Unbeabsichtigte Konsensprobleme
    • 2010 – Value-Overflow-Bug
    • 2013 – Unbeabsichtigte Chain Split zwischen Bitcoin 0.7 und 0.8

Was ist ein Fork und warum kann es überhaupt zu einem Fork kommen?

Alle Bitcoin-Nodes folgen einem gemeinsamen Satz von Konsensregeln.

Diese Regeln bestimmen beispielsweise, wann eine Transaktion gültig ist, wie ein Block aufgebaut sein muss, wie hoch die Blocksubvention sein darf oder welche Bedingungen ein gültiger Proof-of-Work erfüllen muss.

Jede Node prüft diese Regeln bei der Validierung selbstständig.

Dabei gibt es keine zentrale Instanz, die allen Nodes vorgibt, welche Blockchain gültig ist.

Jede Node entscheidet anhand der Konsensregeln ihrer eigenen Software selbst, welche Blöcke sie akzeptiert.

Warum können sich diese Regeln ändern?

Bitcoin kann weiterentwickelt werden.

Neue Funktionen oder Änderungen am Protokoll können Änderungen an den Konsensregeln erforderlich machen.

Eine neue Version der Bitcoin-Software kann deshalb andere Konsensregeln enthalten als eine ältere Version.

Solange beide Versionen bei allen auftretenden Blöcken zum gleichen Ergebnis kommen, besteht kein Problem.

Interessant wird es, sobald ein Block existiert, den die beiden Regelwerke unterschiedlich bewerten:

Die beiden Nodes sind sich dann nicht mehr darüber einig, ob dieser Block Teil einer gültigen Blockchain sein kann.

Genau diese mögliche Abweichung der Konsensregeln ist die Grundlage eines Forks.

Dabei muss jedoch nicht sofort eine dauerhafte Aufspaltung der Blockchain entstehen.

Ob und wie sich alte und neue Konsensregeln miteinander vereinbaren lassen, hängt davon ab, in welche Richtung die Regeln verändert werden.

Genau daraus ergibt sich der Unterschied zwischen einem Soft Fork und einem Hard Fork.

Was passiert, wenn sich die Konsensregeln ändern?

Eine Änderung der Konsensregeln verändert die Bedingungen, unter denen eine Node einen Block oder eine Transaktion als gültig akzeptiert.

Dabei können Regeln beispielsweise strenger oder weniger streng werden.

Angenommen, bisher gelten die Regeln A, B und C. Wird nun eine zusätzliche Regel D eingeführt, muss eine Node, die diese neue Regel verwendet, auch diese Bedingung überprüfen.

Eine ältere Node kennt Regel D dagegen nicht und überprüft weiterhin nur die Regeln A, B und C.

Damit können im Netzwerk gleichzeitig Nodes existieren, die einen Block nach unterschiedlichen Konsensregeln bewerten.

Entscheidend ist nun, wie sich die neuen Regeln zu den alten Regeln verhalten.

Werden die bisherigen Regeln so verschärft, dass weniger Blöcke gültig sind, handelt es sich um einen Soft Fork.

Werden dagegen Blöcke erlaubt, die nach den bisherigen Regeln ungültig wären, handelt es sich um einen Hard Fork.

Was ist ein Soft Fork und warum bleiben die neuen Regeln kompatibel?

Bei einem Soft Fork werden die bestehenden Konsensregeln verschärft.

Nach der Änderung ist also nicht mehr erlaubt als vorher, sondern weniger.

Nehmen wir wieder an, dass eine alte Node die Regeln A, B und C überprüft.

Durch einen Soft Fork kommt eine zusätzliche Regel D hinzu:

Ein Block, der nach den neuen Regeln gültig ist, muss damit A, B, C und D erfüllen.

Da er automatisch auch A, B und C erfüllt, ist derselbe Block weiterhin nach den alten Regeln gültig.

Die neuen Regeln verkleinern damit lediglich die Menge der möglichen gültigen Blöcke.

Genau diese Eigenschaft macht einen Soft Fork abwärtskompatibel.

Aktualisierte Nodes setzen zusätzliche Regeln durch, während alte Nodes Blöcke, die diese neuen Regeln erfüllen, weiterhin nach ihren bisherigen Regeln als gültig akzeptieren können.

Die alten Nodes müssen die neue Regel dafür nicht einmal kennen.

Wie das möglich ist und was eine alte Node dabei tatsächlich überprüft, sehen wir im nächsten Abschnitt.

Warum können alte Nodes neue Soft-Fork-Blöcke weiterhin akzeptieren?

Eine alte Node kennt die durch einen Soft Fork eingeführten neuen Konsensregeln nicht.

Sie überprüft einen neuen Block weiterhin ausschließlich nach den Regeln, die in ihrer eigenen Software implementiert sind.

Bleiben wir beim vorherigen Beispiel:

Angenommen, ein neuer Block erfüllt alle vier Regeln:

Die neue Node überprüft A, B, C und D und akzeptiert den Block.

Die alte Node überprüft dagegen nur A, B und C. Da der Block auch diese Regeln erfüllt, akzeptiert sie ihn ebenfalls.

Die alte Node weiß dabei nicht, dass zusätzlich Regel D existiert.

Sie kann deshalb auch nicht überprüfen, ob Regel D eingehalten wurde.

Das funktioniert nur, weil ein Soft Fork so konstruiert ist, dass jeder Block, der nach den neuen Regeln gültig ist, gleichzeitig auch nach den alten Regeln gültig bleibt.

Problematisch wird es erst, wenn ein Block zwar die alten Regeln A, B und C erfüllt, aber gegen die neue Regel D verstößt:

Jetzt bewerten beide Nodes denselben Block unterschiedlich.

Die alte Node akzeptiert ihn, weil alle ihr bekannten Regeln erfüllt sind.

Die neue Node lehnt ihn ab, weil der Block gegen die zusätzliche Konsensregel D verstößt.

Genau deshalb ist bei einem Soft Fork entscheidend, dass Miner nach der Aktivierung nur noch Blöcke erzeugen, die auch die neuen Regeln erfüllen.

Was passiert, wenn Miner die neuen Regeln nicht anwenden?

Nicht alle Miner müssen bei einem Soft Fork gleichzeitig auf die neuen Konsensregeln wechseln.

Dadurch können im Netzwerk Miner existieren, die unterschiedliche Regeln für ihre Blöcke anwenden.

Bleiben wir beim bisherigen Beispiel:

Ein Miner mit den neuen Regeln erzeugt nur Blöcke, die auch Regel D erfüllen.

Ein Miner mit den alten Regeln kennt Regel D dagegen nicht. Sein Block kann deshalb entweder zufällig auch D erfüllen oder gegen D verstoßen.

Solange ein alter Miner einen Block erzeugt, der auch D erfüllt, entsteht kein Konflikt:

Anders sieht es aus, wenn ein alter Miner einen Block erzeugt, der gegen die neue Regel D verstößt:

Ab diesem Block können sich unterschiedliche Ketten bilden.

Miner mit den neuen Regeln können nicht auf einem Block weiterbauen, den ihre eigenen Konsensregeln als ungültig betrachten.

Miner mit den alten Regeln können dagegen weiterhin auf dieser Kette minen.

Damit können vorübergehend zwei konkurrierende Ketten entstehen.

Welche davon weiter wächst, hängt unter anderem davon ab, wie sich die Hashrate auf die unterschiedlichen Regeln verteilt. Mehr dazu unter Proof-of-Work.

Ein Soft Fork garantiert deshalb nicht, dass es niemals zu einer Chain Split kommt.

Seine besondere Eigenschaft besteht vielmehr darin, dass Blöcke der neuen Regeln weiterhin von alten Nodes akzeptiert werden können.

Genau diese einseitige Kompatibilität unterscheidet einen Soft Fork von einem Hard Fork.

Was ist ein Hard Fork und warum sind die neuen Regeln nicht abwärtskompatibel?

Bei einem Hard Fork werden die Konsensregeln so verändert, dass Blöcke gültig werden können, die nach den bisherigen Regeln ungültig sind.

Bleiben wir beim bisherigen Beispiel:

Nehmen wir beispielsweise an, Regel C legt bisher eine bestimmte Grenze fest.

Durch einen Hard Fork wird diese Grenze erweitert.

Ein Block mit dem Wert 80 ist für beide Nodes gültig:

Ein Block mit dem Wert 150 zeigt dagegen den entscheidenden Unterschied:

Die neue Node akzeptiert damit etwas, das nach den alten Konsensregeln ausdrücklich verboten ist.

Genau deshalb ist ein Hard Fork nicht abwärtskompatibel.

Eine alte Node kann einen solchen Block nicht einfach akzeptieren, ohne selbst ihre Konsensregeln zu ändern.

Der Unterschied zum Soft Fork

Beim Soft Fork werden die Regeln verschärft:

Jeder nach den neuen Regeln gültige Block bleibt damit auch nach den alten Regeln gültig.

Beim Hard Fork gilt diese Beziehung nicht. Die neue gültige Menge wird größer und enthält die alte:

Die neuen Regeln können Blöcke zulassen, die außerhalb dessen liegen, was alte Nodes akzeptieren.

Sobald ein solcher Block tatsächlich erzeugt wird, bewerten alte und neue Nodes denselben Block unterschiedlich:

Ab diesem Punkt können alte Nodes der nach den neuen Regeln erzeugten Blockchain nicht mehr folgen.

Das bedeutet jedoch noch nicht automatisch, dass dauerhaft zwei Blockchains entstehen.

Dafür müssen Teilnehmer auf beiden Seiten weiterhin unterschiedliche Konsensregeln anwenden und entsprechende Blöcke erzeugen.

Wann führt eine Regeländerung tatsächlich zu einer Aufspaltung der Blockchain?

Unterschiedliche Konsensregeln allein führen noch nicht dazu, dass zwei Blockchains entstehen.

Solange alle erzeugten Blöcke sowohl die alten als auch die neuen Regeln erfüllen, können Nodes mit unterschiedlichen Regelwerken weiterhin derselben Blockchain folgen.

Die unterschiedlichen Regeln werden erst sichtbar, wenn ein Block erzeugt wird, den beide Seiten unterschiedlich bewerten.

Bleiben wir bei unserem bisherigen Beispiel:

Solange jeder Block auch Regel D erfüllt, folgen alte und neue Nodes derselben Kette.

Erzeugt ein Miner dagegen einen Block, der zwar A, B und C erfüllt, aber gegen D verstößt, entsteht erstmals eine unterschiedliche Sicht auf die Blockchain.

Alte Nodes können Block 101 akzeptieren und darauf weiterbauen.

Neue Nodes behandeln Block 101 dagegen so, als wäre er niemals ein gültiger Teil ihrer Blockchain geworden. Für sie bleibt Block 100 weiterhin die gültige Spitze der Kette.

Wenn anschließend Miner auf beiden Seiten weitere Blöcke erzeugen, entstehen tatsächlich zwei unterschiedliche Ketten:

Eine Chain Split entsteht also nicht bereits dadurch, dass unterschiedliche Konsensregeln existieren.

Dafür müssen zwei Dinge zusammenkommen:

1. Es wird ein Block erzeugt, den die unterschiedlichen Regelwerke verschieden bewerten.
2. Miner erzeugen anschließend Blöcke auf den unterschiedlichen gültigen Ketten weiter.

Wie lange diese Aufspaltung bestehen bleibt, ist eine andere Frage.

Eine der beiden Ketten kann wieder aufgegeben werden, oder beide Gruppen können dauerhaft an ihren unterschiedlichen Konsensregeln festhalten.

Deshalb bedeutet weder ein Soft Fork automatisch, dass niemals eine Chain Split entstehen kann, noch bedeutet ein Hard Fork automatisch, dass dauerhaft zwei getrennte Blockchains entstehen.

Warum verhindert ein Soft Fork nicht automatisch eine vorübergehende Chain Split?

Ein Soft Fork ist abwärtskompatibel, weil Blöcke, die die neuen Regeln erfüllen, weiterhin auch nach den alten Regeln gültig sind.

Diese Kompatibilität funktioniert jedoch nur in eine Richtung:

Umgekehrt gilt das nicht zwingend.

Ein Block kann nach den alten Regeln gültig sein und gleichzeitig gegen eine neue Konsensregel verstoßen:

Wird nach der Aktivierung eines Soft Forks ein solcher Block erzeugt, unterscheiden sich die Ansichten der Nodes.

Bleiben wir bei unserem Beispiel:

Ein Miner, der nur die alten Regeln anwendet, erzeugt Block 101 und verletzt dabei Regel D:

Alte Nodes können Block 101 akzeptieren und Miner können darauf weiterarbeiten.

Für Nodes mit den neuen Regeln existiert Block 101 dagegen nicht als gültige Fortsetzung von Block 100. Ihre gültige Kette endet weiterhin bei Block 100.

Findet anschließend ein Miner einen Block, der die neuen Regeln erfüllt und direkt auf Block 100 aufbaut, existieren zwei konkurrierende Ketten:

Die Besonderheit eines Soft Forks besteht darin, dass alte Nodes beide Ketten grundsätzlich als gültig betrachten können, sofern alle Blöcke ihre alten Regeln erfüllen.

Neue Nodes akzeptieren dagegen ausschließlich die Kette, auf der auch die neuen Regeln eingehalten werden.

Eine solche Aufspaltung kann deshalb vorübergehend bestehen, solange Miner auf dem nach den neuen Regeln ungültigen Zweig weiterarbeiten.

Ein Soft Fork verhindert also nicht grundsätzlich eine Chain Split.

Er sorgt vielmehr dafür, dass die nach den neuen Regeln gültige Kette weiterhin mit den alten Konsensregeln kompatibel bleibt.

Warum führt ein Hard Fork nicht automatisch zu zwei dauerhaften Blockchains?

Ein Hard Fork macht eine dauerhafte Aufspaltung der Blockchain möglich, verursacht sie aber nicht automatisch.

Nach einem Hard Fork können die neuen Regeln Blöcke erlauben, die von alten Nodes abgelehnt werden.

Solange jedoch kein solcher Block erzeugt wird, können alte und neue Nodes weiterhin derselben Blockchain folgen.

Erst wenn tatsächlich ein Block erzeugt wird, der nur nach den neuen Regeln gültig ist, können sich die Ketten trennen:

Die alten Nodes können Block 101 nicht akzeptieren.

Wenn Miner mit den alten Regeln weiterhin Blöcke erzeugen, müssen sie deshalb auf dem letzten für sie gültigen Block weiterarbeiten.

Jetzt existieren tatsächlich zwei unterschiedliche Blockchains.

Damit daraus jedoch zwei dauerhafte Blockchains werden, müssen beide Seiten weiterhin Teilnehmer haben, die ihre jeweilige Kette verwenden und Miner, die darauf neue Blöcke erzeugen.

Was passiert, wenn fast alle auf die neuen Regeln wechseln?

Wenn Nodes, Miner und andere Teilnehmer die neuen Regeln übernehmen und niemand die alte Kette weiter minet, entsteht keine dauerhaft weiterlaufende zweite Blockchain.

Die alte Software wäre zwar weiterhin mit den neuen Blöcken inkompatibel, aber es gäbe keine dauerhaft weitergeführte alte Blockchain.

Was passiert, wenn beide Seiten weitergeführt werden?

Anders sieht es aus, wenn ein Teil des Netzwerks die alten Regeln beibehält und ein anderer Teil die neuen Regeln verwendet.

Wenn auf beiden Seiten weiterhin Blöcke erzeugt werden, können zwei dauerhaft getrennte Blockchains entstehen:

Beide Blockchains teilen sich bis zum Fork dieselbe Historie, entwickeln sich danach aber unabhängig voneinander weiter.

Ein Hard Fork bedeutet deshalb zunächst nur:

Die neuen Konsensregeln sind nicht vollständig mit den alten Konsensregeln kompatibel.

Ob daraus tatsächlich zwei dauerhaft getrennte Blockchains entstehen, hängt davon ab, ob nach der Trennung beide Regelwerke weiterhin verwendet und beide Ketten weitergeführt werden.

Wie wird ein neuer Soft Fork im Bitcoin-Netzwerk aktiviert?

Ein Soft Fork wird nicht allein dadurch aktiv, dass neue Konsensregeln programmiert und in einer neuen Version von Bitcoin Core veröffentlicht werden.

Die neuen Regeln müssen zunächst von Nodes installiert werden und zu einem vorher festgelegten Zeitpunkt oder unter bestimmten Bedingungen aktiviert werden.

Ab diesem Moment beginnen aktualisierte Nodes, die neuen Regeln tatsächlich als Konsensregeln durchzusetzen.

Vereinfacht lässt sich der Ablauf so darstellen:

Warum braucht ein Soft Fork überhaupt eine Aktivierung?

Würden aktualisierte Nodes eine neue Konsensregel sofort nach Installation durchsetzen, könnten verschiedene Nodes zu völlig unterschiedlichen Zeitpunkten mit der Durchsetzung beginnen.

Das wäre besonders problematisch, wenn Miner noch Blöcke erzeugen, die gegen die neue Regel verstoßen.

Deshalb wird normalerweise festgelegt, unter welchen Bedingungen die neuen Regeln aktiv werden.

Vor der Aktivierung:

Nach der Aktivierung:

Wie kann die Aktivierung festgelegt werden?

Bitcoin hat im Laufe seiner Geschichte unterschiedliche Aktivierungsmechanismen verwendet.

Eine Aktivierung kann beispielsweise von einer bestimmten Blockhöhe oder Zeit abhängen oder mit der Signalisierung von Minern verbunden sein.

Bekannte Mechanismen und Verfahren sind unter anderem:

• Aktivierung ab einer festgelegten Blockhöhe
• BIP9 Version Bits
• BIP8
• minerbasierte Aktivierungsschwellen
• nutzergetriebene Aktivierungsansätze

Es gibt deshalb nicht den einen Aktivierungsmechanismus, der für jeden Bitcoin-Soft-Fork verwendet wird.

Der jeweilige Mechanismus legt fest, wann aktualisierte Nodes vom Zustand nicht aktiv in den Zustand aktiv wechseln.

Wie sich Signalisierung und Fork-Zustände im laufenden Mainnet darstellen, lässt sich beispielsweise auf fork.observer nachvollziehen.

Aktivierung bedeutet Durchsetzung

Der entscheidende Moment ist nicht die Veröffentlichung der Software und auch nicht die bloße Unterstützung einer neuen Regel.

Entscheidend ist der Zeitpunkt, ab dem eine Node die neue Regel tatsächlich bei der Blockvalidierung anwendet:

Ab der Aktivierung akzeptieren aktualisierte Nodes nur noch Blöcke, die sowohl die bisherigen als auch die neuen Konsensregeln erfüllen.

Die Aktivierung koordiniert damit den Übergang von den alten zu den verschärften Konsensregeln.

Welche Rolle dabei die Signalisierung der Miner spielt, betrachten wir im nächsten Abschnitt.

Welche Rolle spielt die Signalisierung der Miner bei einem Soft Fork?

Bei einigen Soft-Fork-Aktivierungsmechanismen können Miner in den von ihnen erzeugten Blöcken signalisieren, dass sie für die Aktivierung eines bestimmten Soft Forks bereit sind.

Diese Signalisierung erfolgt über das Versionsfeld im Block Header.

Bei Version Bits können verschiedene Bits des Versionsfeldes für unterschiedliche Soft-Fork-Deployments verwendet werden.

Aktualisierte Nodes beobachten die Blöcke und können dadurch feststellen, wie viele der erzeugten Blöcke innerhalb eines festgelegten Zeitraums das entsprechende Bit gesetzt haben.

Ein öffentlicher Überblick über aktuelle und historische Soft-Fork-Signalisierung im Mainnet findet sich auf fork.observer.

Warum signalisieren Miner überhaupt?

Eine neue Konsensregel kann für Miner relevant sein, weil sie nach der Aktivierung keine Blöcke erzeugen sollten, die gegen diese Regel verstoßen.

Die Signalisierung soll deshalb anzeigen, dass ein Miner beziehungsweise die von ihm verwendete Mining-Infrastruktur auf die neuen Regeln vorbereitet ist.

Vereinfacht:

Je nach Aktivierungsmechanismus kann eine bestimmte Signalisierungsschwelle dazu führen, dass der Soft Fork in einen nächsten Aktivierungszustand übergeht.

Die genauen Zeiträume, Schwellenwerte und Zustände hängen vom jeweiligen Aktivierungsmechanismus ab.

Signalisierung ist keine Abstimmung über die Konsensregeln

Ein wichtiger Unterschied besteht zwischen Signalisierung und Durchsetzung.

Wenn ein Miner ein bestimmtes Bit setzt, verändert er dadurch nicht die Konsensregeln anderer Nodes.

Die Konsensregeln einer Full Node werden durch die Software bestimmt, die der Betreiber dieser Node ausführt.

Nach der Aktivierung entscheidet deshalb weiterhin jede aktualisierte Node selbst, ob ein Block die neuen Regeln erfüllt.

Ein Miner kann einer Node also nicht durch seine Signalisierung vorschreiben, welche Konsensregeln sie anwenden soll.

Die Signalisierung kann Bestandteil des Aktivierungsmechanismus sein, die eigentliche Durchsetzung der Regeln erfolgt jedoch durch die Nodes, die diese Regeln in ihrer Software aktiviert haben.

Welche Rolle Full Nodes dabei genau spielen, betrachten wir im nächsten Abschnitt.

Wer setzt die neuen Konsensregeln im Bitcoin-Netzwerk tatsächlich durch?

Die Konsensregeln werden von den Nodes selbst durchgesetzt.

Jede Full Node überprüft unabhängig jeden empfangenen Block anhand der Konsensregeln, die in ihrer eigenen Software aktiv sind.

Nach der Aktivierung eines Soft Forks beginnen aktualisierte Nodes, zusätzlich die neuen Konsensregeln zu überprüfen.

Bleiben wir bei unserem bisherigen Beispiel:

Erzeugt ein Miner einen Block, der gegen die neue Regel D verstößt, entscheidet jede Node selbst über dessen Gültigkeit:

Die aktualisierte Node fragt dabei weder andere Nodes noch Miner, Entwickler oder einen zentralen Server um Erlaubnis.

Für sie ist der Block schlicht ungültig.

Welche Rolle spielen die Miner?

Miner haben eine andere Aufgabe.

Sie wählen Transaktionen aus, erzeugen neue Blöcke und leisten den erforderlichen Proof-of-Work.

Sie können dadurch bestimmen, welche gültige Kette mehr kumulative Arbeit erhält.

Sie können aber eine Full Node nicht dazu zwingen, einen nach deren Konsensregeln ungültigen Block zu akzeptieren.

Auch zusätzliche Rechenarbeit macht einen ungültigen Block für diese Node nicht gültig.

Die Regel der Kette mit der meisten kumulativen Arbeit gilt nur zwischen Ketten, die eine Node zuvor als gültig bewertet hat.

Welche Rolle spielen die Entwickler?

Entwickler können neue Konsensregeln entwerfen und Software veröffentlichen, die diese Regeln implementiert.

Damit werden die Regeln jedoch nicht automatisch für das gesamte Bitcoin-Netzwerk verbindlich.

Node-Betreiber entscheiden selbst, welche Software sie installieren und ausführen.

Deshalb gibt es bei Bitcoin keine einzelne Instanz, die eine Änderung der Konsensregeln allein durchsetzen kann.

Miner erzeugen Blöcke, Entwickler stellen Software bereit und Nutzer entscheiden, welche Software und damit welche Regeln ihre eigenen Nodes anwenden.

Die eigentliche Entscheidung über einen empfangenen Block trifft am Ende jede Full Node selbst:

Genau darin liegt die Bedeutung einer selbst betriebenen Full Node: Sie verlässt sich bei der Frage, welche Blöcke gültig sind, nicht auf die Entscheidung eines Miners oder eines anderen Teilnehmers, sondern überprüft die Konsensregeln selbst.

Was ist der entscheidende Unterschied zwischen Soft Fork und Hard Fork?

Der entscheidende Unterschied liegt darin, wie sich die neuen Konsensregeln zu den bisherigen Konsensregeln verhalten.

Bei einem Soft Fork werden die Regeln verschärft.

Die Menge der Blöcke, die nach den neuen Regeln gültig sind, ist damit eine Teilmenge der Blöcke, die nach den alten Regeln gültig waren.

Ein Block, der die neuen Regeln erfüllt, erfüllt damit gleichzeitig die alten Regeln.

Alte Nodes können einen solchen Block weiterhin akzeptieren, obwohl sie die zusätzlichen Regeln selbst nicht kennen oder überprüfen.

Bei einem Hard Fork werden dagegen Blöcke möglich, die nach den bisherigen Konsensregeln ungültig sind.

Die neue gültige Blockmenge ist damit nicht vollständig in der alten enthalten:

Eine alte Node kann einem solchen Block nicht folgen, ohne ihre eigenen Konsensregeln zu ändern.

Soft Fork und Hard Fork im direkten Vergleich

Der Begriff Fork bedeutet deshalb nicht automatisch, dass zwei Coins oder zwei dauerhaft getrennte Blockchains entstehen.

Entscheidend ist zunächst nur, ob sich die alten und neuen Konsensregeln bei der Bewertung eines Blocks unterscheiden können.

Kurz zusammengefasst:

Ein Soft Fork schränkt ein, was gültig ist. Ein Hard Fork erlaubt mindestens etwas, das nach den bisherigen Regeln ungültig war.

Soft-Forks in der Geschichte von Bitcoin

Bitcoin hat seit seinem Start mehrere Soft Forks erlebt.

Dabei wurden die Konsensregeln schrittweise verschärft und unter anderem neue Script-Funktionen, strengere Validierungsregeln und neue Möglichkeiten für Transaktionen eingeführt.

Die wichtigsten aktivierten Soft Forks betrachten wir chronologisch.

Ein öffentlicher Überblick über Soft-Fork-Deployments und Signalisierung im Mainnet findet sich auf fork.observer.

Aktivierte Soft Forks

2012 – P2SH (BIP16)

Mit BIP16 wurde 2012 Pay-to-Script-Hash (P2SH) als neuer Standard für Bitcoin-Scripts aktiviert.

Vor P2SH musste der Sender die Bedingungen zum Ausgeben eines Outputs direkt im scriptPubKey festlegen.

P2SH ermöglichte stattdessen, nur den Hash eines Scripts im Output zu hinterlegen. Das eigentliche redeemScript wird erst beim späteren Ausgeben des Outputs offengelegt.

P2SH wurde als Soft Fork eingeführt, indem Outputs mit dem Muster für aktualisierte Nodes zusätzliche Konsensbedingungen erhielten.

Alte Nodes konnten eine entsprechende Transaktion weiterhin nach ihren bisherigen Regeln akzeptieren. Aktualisierte Nodes überprüften zusätzlich, ob das vorgelegte redeemScript zum gespeicherten Hash passt und anschließend erfolgreich ausgeführt wird.

Damit ist P2SH ein frühes Beispiel dafür, wie Bitcoin durch einen Soft Fork neue Funktionen einführen konnte, ohne dass alte Nodes die neue Funktion selbst verstehen mussten.

2013 – BIP34

Mit BIP34 wurde 2013 eine neue Konsensregel für die Coinbase-Transaktion aktiviert.

Seit der Aktivierung muss die aktuelle Blockhöhe am Anfang der Coinbase-Daten stehen.

Vereinfacht:

BIP34 wurde bereits 2012 vorgeschlagen. Die vollständige Durchsetzung der neuen Regel erfolgte 2013 ab Block 227.931.

Für einen Block auf Höhe 227931 muss die Coinbase-Transaktion also mit einer Script-Zahl beginnen, die 227931 repräsentiert.

Die Blockhöhe wird dadurch nicht erst durch BIP34 bestimmbar. Eine Node kennt die Höhe eines Blocks bereits durch seine Position innerhalb der Blockchain.

BIP34 verlangt vielmehr, dass der Miner diese Höhe zusätzlich explizit in die Coinbase-Transaktion schreibt.

Warum ist BIP34 ein Soft Fork?

Vor BIP34 gab es diese zusätzliche Bedingung nicht.

Eine alte Node prüft daher nicht, ob die Coinbase-Daten mit der korrekten Blockhöhe beginnen.

BIP34 hat damit eine zusätzliche Bedingung für gültige Blöcke eingeführt.

Ein Block, der die neue BIP34-Regel erfüllt, kann weiterhin auch die bisherigen Konsensregeln erfüllen.

Umgekehrt kann ein Block nach den alten Regeln gültig erscheinen, obwohl er gegen BIP34 verstößt.

Genau deshalb konnte BIP34 als Soft Fork eingeführt werden: Die Menge der gültigen Blöcke wurde eingeschränkt, nicht erweitert.

2015 – BIP66

Mit BIP66 wurden 2015 die Regeln für die Kodierung von ECDSA-Signaturen verschärft.

Bitcoin verwendet ECDSA-Signaturen, um bei entsprechenden Script-Typen zu prüfen, ob eine Transaktion mit dem passenden privaten Schlüssel autorisiert wurde.

Die beiden Bestandteile einer ECDSA-Signatur, r und s, werden dabei in einem bestimmten Format kodiert.

BIP66 verlangt für Signaturen, die von den entsprechenden Signatur-Opcodes geprüft werden, eine strikte DER-Kodierung.

Wie r und s dabei als Bytefolge aufgebaut sind, zeigt die Darstellung unter ECDSA:

Vereinfacht:

Damit wurde nicht das ECDSA-Verfahren selbst verändert.

BIP66 verschärfte vielmehr die Regeln dafür, wie eine Signatur als Bytefolge aufgebaut sein darf.

Warum ist BIP66 ein Soft Fork?

Vor BIP66 konnten alte Nodes bestimmte Signaturkodierungen akzeptieren, die nach der neuen Regel nicht mehr zulässig waren.

Angenommen, eine Transaktion enthält eine ECDSA-Signatur, die kryptografisch geprüft werden könnte, aber nicht der von BIP66 geforderten strikten DER-Kodierung entspricht:

BIP66 führte damit eine zusätzliche Bedingung für gültige Scripts ein:

Die neuen Regeln erlaubten also keine Signaturkodierungen, die zuvor verboten waren.

Stattdessen wurde ein Teil der zuvor akzeptierten Kodierungen ausgeschlossen.

Genau deshalb konnte BIP66 als Soft Fork aktiviert werden: Die Menge der nach diesen Regeln gültigen Transaktionen und damit der möglichen gültigen Blöcke wurde eingeschränkt.

2015 – CLTV (BIP65)

Mit BIP65 wurde 2015 der Opcode OP_CHECKLOCKTIMEVERIFY (CLTV) als neue Konsensregel aktiviert.

CLTV ermöglicht es, direkt in einem Bitcoin-Script festzulegen, dass ein Output nicht vor einer bestimmten Blockhöhe oder einem bestimmten Zeitpunkt ausgegeben werden kann.

Vereinfacht kann ein Script beispielsweise verlangen:

Damit können Bitcoins mit einer zeitlichen Bedingung versehen werden, die bei der späteren Script-Ausführung von jeder aktualisierten Node überprüft wird.

Wie konnte ein neuer Opcode als Soft Fork eingeführt werden?

Der interessante Teil von BIP65 ist nicht nur die neue Funktion, sondern wie sie abwärtskompatibel eingeführt werden konnte.

OP_CHECKLOCKTIMEVERIFY verwendete den bereits vorhandenen Opcode OP_NOP2.

NOP steht für No Operation. Für alte Nodes hatte dieser Opcode keine relevante Wirkung auf die Script-Ausführung.

Vereinfacht:

Genau dadurch konnte eine neue Funktion eingeführt werden, ohne dass alte Nodes den neuen Opcode verstehen mussten.

Warum ist CLTV ein Soft Fork?

Angenommen, ein Output enthält eine CLTV-Bedingung und soll erst ab Blockhöhe 400000 ausgegeben werden.

Eine Transaktion versucht bereits auf Höhe 399999, diesen Output auszugeben.

BIP65 erlaubt damit nicht einfach zusätzliche Transaktionen.

Stattdessen werden bestimmte Transaktionen, die alte Nodes noch akzeptieren konnten, von aktualisierten Nodes unter zusätzlichen Bedingungen abgelehnt.

Genau darin liegt der Soft-Fork-Mechanismus von CLTV:

Ein bisher praktisch wirkungsloser Opcode wurde mit einer zusätzlichen Bedingung versehen.

Alte Nodes können CLTV-konforme Transaktionen und Blöcke weiterhin akzeptieren, obwohl sie die neue Zeitbedingung selbst nicht überprüfen. Aktualisierte Nodes setzen dagegen zusätzlich die neuen CLTV-Regeln durch.

2016 – CSV (BIP68, BIP112, BIP113)

2016 wurde mit CheckSequenceVerify (CSV) ein Paket aus mehreren zusammengehörenden Konsensänderungen aktiviert.

Während CLTV einen Output bis zu einer absoluten Blockhöhe oder einem absoluten Zeitpunkt sperren kann, ermöglicht CSV relative Zeitsperren.

Ein Output kann dadurch beispielsweise verlangen:

Entscheidend ist hier nicht eine vorher festgelegte Blockhöhe wie 500144.

Die Sperre beginnt relativ zu dem Zeitpunkt beziehungsweise der Blockhöhe, zu der der ausgegebene Output bestätigt wurde.

BIP68 – relative Locktime über nSequence

BIP68 gibt dem nSequence-Feld eines Inputs eine neue Konsensbedeutung.

Für Transaktionen mit entsprechender Version kann nSequence festlegen, wie lange nach der Bestätigung des ausgegebenen Outputs gewartet werden muss.

Die Verzögerung kann in Blöcken oder in Zeiteinheiten angegeben werden.

BIP112 – OP_CHECKSEQUENCEVERIFY

BIP112 führte OP_CHECKSEQUENCEVERIFY (CSV) ein.

Ähnlich wie bei CLTV wurde dafür kein vollkommen neuer Opcode-Bereich benötigt.

Der bisherige Opcode OP_NOP3 erhielt für aktualisierte Nodes eine neue Bedeutung.

Damit kann ein Script selbst verlangen, dass ein bestimmter relativer Zeitraum vergangen sein muss, bevor der Output ausgegeben werden darf.

BIP113 – Median Time Past

BIP113 änderte außerdem die Zeitbasis für die Überprüfung zeitbasierter Locktimes.

Anstatt sich dabei auf den Zeitstempel des aktuellen Blocks zu stützen, wird der Median Time Past (MTP) der vorherigen Blöcke verwendet.

Dadurch wird die für Locktime-Regeln verwendete Zeit weniger unmittelbar vom Zeitstempel eines einzelnen Miners abhängig.

Warum ist CSV ein Soft Fork?

Auch hier wurden die Regeln nicht gelockert, sondern zusätzliche Bedingungen eingeführt.

Eine alte Node kennt die neue Bedeutung von OP_NOP3 nicht.

Angenommen, ein Output verlangt über CSV eine Wartezeit von 144 Blöcken, wird aber bereits nach 100 Blöcken ausgegeben:

Die aktualisierte Node akzeptiert damit nur noch eine Teilmenge dessen, was eine alte Node akzeptieren konnte.

CSV ist deshalb wie CLTV ein gutes Beispiel dafür, wie Bitcoin neue Funktionen durch eine Verschärfung bestehender Regeln einführen kann.

Alte Nodes können CSV-konformen Blöcken weiterhin folgen, obwohl sie die zusätzlichen Bedingungen selbst nicht vollständig überprüfen.

2017 – SegWit (BIP141 u. a.)

Mit Segregated Witness (SegWit) wurde 2017 eine der umfangreichsten Konsensänderungen in der Geschichte von Bitcoin aktiviert.

SegWit veränderte unter anderem, wie Signaturdaten in Transaktionen behandelt werden.

Bei SegWit-Inputs werden Signaturen und andere Freigabedaten in einem separaten Witness-Bereich übertragen.

Vereinfacht:

SegWit führte außerdem neue Witness-Programme, eine neue Berechnung der Transaktions-ID für Witness-Daten (wtxid) und das Konzept des Block Weight ein. Mehr dazu unter SegWit und Blockgewicht.

Dadurch konnte Bitcoin unter anderem Transaction Malleability für SegWit-Spends stark reduzieren und die verfügbare Blockkapazität anders bemessen.

Wie konnte SegWit als Soft Fork eingeführt werden?

Der entscheidende Punkt ist, wie alte Nodes SegWit-Ausgaben interpretieren.

Ein SegWit-v0-Output kann beispielsweise so aussehen:

Für eine alte Node hatte dieses Script noch nicht die neue SegWit-Bedeutung.

Sie kennt weder Witness-Version 0 noch die zusätzlichen Regeln, die aktualisierte Nodes für diesen Output anwenden.

Vereinfacht betrachtet sieht die alte Node beim Ausgeben eines nativen SegWit-Outputs ein Script, dessen Ausführung nach ihren alten Regeln erfolgreich sein kann, ohne die Witness-Daten zu überprüfen.

Eine SegWit-Node erkennt dagegen das spezielle Witness-Programm und führt zusätzliche Konsensprüfungen durch.

Damit entsteht wieder dasselbe Prinzip wie bei den vorherigen Soft Forks:

Die alte Node kann einen Spend akzeptieren, obwohl sie die zusätzlichen Bedingungen selbst nicht überprüft.

Warum ist SegWit ein Soft Fork?

Angenommen, jemand versucht einen SegWit-Output mit einer ungültigen Signatur auszugeben.

Für die SegWit-Node gelten also zusätzliche Bedingungen, die eine alte Node nicht kennt.

SegWit erweitert damit zwar die Funktionen, die Bitcoin-Nutzer verwenden können, aus Sicht der alten Konsensregeln geschieht dies jedoch durch eine Verschärfung.

Aktualisierte Nodes akzeptieren nur SegWit-Spends, die zusätzlich die neuen Witness-Regeln erfüllen.

Alte Nodes können SegWit-konformen Blöcken weiterhin folgen, obwohl sie diese zusätzlichen Regeln selbst nicht durchsetzen.

Gerade SegWit zeigt deshalb besonders deutlich, wie Bitcoin durch einen Soft Fork neue Funktionen erhalten kann, ohne dass alle bestehenden Nodes gleichzeitig aktualisiert werden müssen.

2021 – Taproot (BIP341, BIP342)

Mit Taproot wurde 2021 der bisher jüngste große Soft Fork im Bitcoin-Mainnet aktiviert.

Taproot führte unter anderem Schnorr-Signaturen, Pay-to-Taproot-Ausgaben (P2TR) und mit Tapscript neue Regeln für Bitcoin Script ein.

Ein Taproot-Output verwendet ein Witness-Programm der Version 1:

Beim Ausgeben kann anschließend entweder der Key Path oder der Script Path verwendet werden.

Wie Taproot-Outputs, Taproot-Schlüssel und die beiden Ausgabepfade genau funktionieren, betrachten wir auf der Taproot-Seite.

Wie konnte Taproot als Soft Fork eingeführt werden?

Hier kommt derselbe Mechanismus zum Einsatz, den wir bereits bei SegWit gesehen haben.

SegWit führte versionierte Witness-Programme ein.

Taproot verwendet die zuvor noch nicht definierte Witness-Version 1.

Eine Node vor Taproot kennt die neuen Regeln für Witness-Version 1 nicht.

Sie erkennt also nicht, dass OP_1 <32-byte-output-key> heute einen Taproot-Output darstellt und welche Bedingungen beim Ausgeben erfüllt werden müssen.

Eine aktualisierte Taproot-Node erkennt dagegen Witness-Version 1 und setzt die zusätzlichen Taproot-Konsensregeln durch.

Warum ist Taproot ein Soft Fork?

Nehmen wir einen Taproot-Output, der über den Key Path ausgegeben werden soll.

Dafür ist nach den Taproot-Regeln eine gültige Schnorr-Signatur erforderlich.

Ein Angreifer versucht nun, diesen Output ohne gültige Signatur auszugeben.

Damit entsteht wieder die für einen Soft Fork typische Situation:

Taproot erlaubt aus Sicht alter Nodes also nicht einfach etwas, das vorher verboten war.

Stattdessen bekommt ein bereits abwärtskompatibel behandeltes Witness-Programm durch aktualisierte Nodes zusätzliche Konsensbedingungen.

Ein Taproot-konformer Block kann deshalb weiterhin von Nodes akzeptiert werden, die Taproot selbst noch nicht verstehen.

Diese alten Nodes überprüfen die Taproot-Bedingungen jedoch nicht selbst.

Aktivierung von Taproot

Taproot wurde 2021 über den Aktivierungsmechanismus Speedy Trial aktiviert.

Miner signalisierten ihre Bereitschaft über Version Bits in den von ihnen erzeugten Blöcken.

Nachdem innerhalb eines Signalisierungszeitraums die notwendige Schwelle erreicht worden war, wurde Taproot für die Aktivierung festgesetzt.

Die neuen Konsensregeln wurden anschließend ab Block 709.632 am 14. November 2021 durchgesetzt.

Auch hier gilt deshalb:

Die Miner-Signalisierung machte Taproot nicht selbst zu einer Konsensregel. Sie war Teil des Aktivierungsmechanismus. Nach der Aktivierung entscheiden die Konsensregeln jeder Full Node darüber, ob ein Taproot-Block gültig ist.

Vorgeschlagene, aber bisher nicht aktivierte Soft Forks

Nicht jeder vorgeschlagene Soft Fork wird automatisch Teil der Bitcoin-Konsensregeln.

Ein BIP kann diskutiert, implementiert, verändert oder wieder verworfen werden, ohne dass die darin beschriebenen Regeln jemals im Bitcoin-Mainnet aktiviert werden.

BIP54 – Consensus Cleanup

BIP54, auch Consensus Cleanup genannt, schlägt einen Soft Fork vor, der mehrere seit Langem bekannte Schwachstellen und Sonderfälle der Bitcoin-Konsensregeln gleichzeitig bereinigen soll.

Anders als SegWit oder Taproot soll BIP54 keine große neue Funktion für Nutzer einführen. Im Mittelpunkt steht vielmehr, bestehende Konsensregeln robuster, einfacher und weniger angreifbar zu machen.

BIP54 umfasst vier wesentliche Änderungen:

Timewarp-Angriffe

Die Difficulty wird alle 2016 Blöcke anhand der vergangenen Blockzeiten angepasst.

Bestimmte Eigenschaften der bisherigen Timestamp-Regeln ermöglichen theoretisch einen Timewarp-Angriff, bei dem Miner die Difficulty über mehrere Anpassungsperioden künstlich nach unten beeinflussen können.

BIP54 führt deshalb zusätzliche Regeln für die Zeitstempel am Anfang und Ende einer Difficulty-Periode ein.

Dadurch soll verhindert werden, dass eine Mehrheit der Hashrate die Difficulty über diesen Mechanismus beliebig weit absenken kann.

Diese Änderung würde direkt in die Header-Regeln der Blockvalidierung eingreifen, also dort, wo bereits Timestamp und Difficulty geprüft werden.

Begrenzung teurer Signaturprüfungen

Ein speziell konstruierter Block kann im ungünstigsten Fall sehr aufwendig zu validieren sein.

BIP54 führt deshalb ein zusätzliches Limit für Signaturoperationen innerhalb einer Transaktion ein.

Überschreitet eine Nicht-Coinbase-Transaktion insgesamt 2500 gezählte Signaturoperationen, ist sie nach den vorgeschlagenen Regeln ungültig.

Damit soll insbesondere die maximale Zeit begrenzt werden, die eine Node für die Validierung speziell konstruierter Blöcke aufwenden muss.

Diese Prüfung würde zur Transaktionsvalidierung gehören und dort die bestehenden Script-Regeln um eine zusätzliche Konsensgrenze ergänzen.

64-Byte-Transaktionen

Eine weitere Änderung betrifft Transaktionen, deren Serialisierung ohne Witness-Daten exakt 64 Bytes groß ist.

Durch die Struktur des Bitcoin-Merkle Trees kann eine solche Bytefolge unter bestimmten Umständen sowohl wie eine Transaktion als auch wie ein innerer Knoten eines Merkle Trees interpretiert werden.

BIP54 würde solche Transaktionen deshalb vollständig ungültig machen.

Solche Transaktionen sind bereits seit Jahren nicht standardmäßig relaybar und wurden laut BIP54 seit 2016 nicht mehr verwendet. Die neue Regel würde aus der bisherigen Policy-Beschränkung jedoch eine Konsensregel machen.

Die zusätzliche Prüfung würde damit die Transaktionsvalidierung verschärfen und gleichzeitig einen historischen Sonderfall des Merkle-Root-Verfahrens beseitigen.

Coinbase-Transaktionen und Duplicate-TXIDs

BIP54 schlägt außerdem zusätzliche Anforderungen an die Coinbase-Transaktion vor.

Das nLockTime-Feld der Coinbase soll auf die vorherige Blockhöhe gesetzt werden. Zusätzlich darf ihr nSequence nicht 0xffffffff sein.

Dadurch sollen neue Coinbase-Transaktionen eindeutig von bestimmten historischen Coinbase-Transaktionen unterscheidbar bleiben und zukünftige Probleme mit BIP30 vermieden werden.

Diese Regeln würden die bestehenden Coinbase-Regeln der Blockvalidierung um zusätzliche Bedingungen erweitern.

Was würde BIP54 an der Validierung ändern?

Die heutige Validierung würde durch BIP54 nicht ersetzt.

Stattdessen würden an mehreren Stellen zusätzliche Konsensprüfungen hinzukommen:

Die vollständige heutige Prüfpipeline ist unter Validierung beschrieben.

BIP54 würde diese Pipeline also verschärfen, nicht grundsätzlich neu aufbauen.

Warum wäre BIP54 ein Soft Fork?

Alle vorgeschlagenen Änderungen haben eine gemeinsame Eigenschaft:

Sie machen bisher gültige Sonderfälle ungültig, erlauben aber keine Blöcke, die nach den heutigen Konsensregeln ungültig wären.

Eine nicht aktualisierte Node könnte deshalb weiterhin einen BIP54-konformen Block akzeptieren.

Sie würde die zusätzlichen Regeln jedoch nicht selbst überprüfen und könnte umgekehrt einen Block als gültig betrachten, den eine BIP54-Node aufgrund einer der neuen Einschränkungen ablehnt.

BIP54 ist damit ein besonders anschauliches Beispiel dafür, dass ein Soft Fork nicht zwangsläufig neue Funktionen wie SegWit oder Taproot einführen muss.

Ein Soft Fork kann auch dazu dienen, bestehende Konsensregeln gezielt zu verschärfen und bekannte Schwachstellen zu beseitigen.

BIP54 ist derzeit als Consensus Soft Fork spezifiziert und im BIP-Repository als Complete gekennzeichnet.

Complete bedeutet dabei, dass die Spezifikation fertiggestellt wurde, nicht, dass der Soft Fork im Bitcoin-Mainnet aktiviert wurde.

BIP110 – Reduced Data Temporary Softfork

BIP110, auch Reduced Data Temporary Softfork genannt, schlägt einen zeitlich begrenzten Soft Fork vor, der bestimmte Möglichkeiten zur Speicherung großer Datenmengen innerhalb von Bitcoin-Transaktionen einschränken soll.

Der Vorschlag entstand vor dem Hintergrund der Diskussion darüber, in welchem Umfang die Bitcoin-Blockchain für beliebige Daten verwendet werden sollte.

Anders als BIP54 geht es bei BIP110 deshalb nicht hauptsächlich um die Bereinigung historischer Konsens-Sonderfälle.

BIP110 würde bewusst bestimmte heute konsensgültige Verwendungen von Scripts, Witness-Daten und Taproot für einen begrenzten Zeitraum ungültig machen.

Welche Regeln würde BIP110 verschärfen?

Während BIP110 aktiv ist, würden sieben zusätzliche Konsensregeln gelten.

Die Regeln würden an mehreren Stellen in die heutige Transaktionsvalidierung und insbesondere in die Script-Regeln eingreifen.

Begrenzung des scriptPubKey

Neu erzeugte Outputs dürften grundsätzlich keinen scriptPubKey mit mehr als 34 Bytes besitzen.

Eine Ausnahme bilden OP_RETURN-Outputs. Dort wären bis zu 83 Bytes erlaubt.

Damit würde aus einer Größenbeschränkung, die für viele praktische Verwendungen bereits durch Policy beeinflusst wird, teilweise eine echte Konsensgrenze.

Ein Miner könnte einen dagegen verstoßenden Output dann nicht mehr dadurch in die Blockchain bringen, dass er die Mempool-Policy anderer Nodes umgeht.

Begrenzung großer Daten-Pushes

BIP110 würde außerdem bestimmte OP_PUSHDATA*-Payloads und sogenannte Script Argument Witness Items auf 256 Bytes begrenzen.

Damit sind insbesondere Witness-Elemente gemeint, die vor der Ausführung eines Scripts als Argumente auf den Stack gelegt werden.

Bestimmte Script-Bestandteile wie Witness Scripts und Tapleaf Scripts werden dabei gesondert behandelt und fallen nicht einfach unter dieses 256-Byte-Limit.

Die Prüfung würde Teil der Script-Validierung werden.

Einschränkungen für zukünftige Witness-Versionen

Eine besonders weitreichende Regel betrifft bislang nicht definierte Witness- und Tapleaf-Versionen.

Bitcoin lässt solche Versionsbereiche bewusst offen, damit ihnen durch zukünftige Soft Forks neue Regeln gegeben werden können.

BIP110 würde während seiner Laufzeit das Ausgeben solcher noch nicht definierten Versionen verbieten.

Das Erzeugen entsprechender Outputs bliebe dagegen möglich.

Zu den im aktuellen BIP110 ausdrücklich als definiert behandelten Witness-Programmen gehören unter anderem SegWit v0, Taproot und P2A.

Änderungen an Taproot

Mehrere Regeln betreffen direkt Taproot.

Ein Taproot Annex wäre während der Aktivierung nicht erlaubt.

Außerdem dürften Taproot Control Blocks höchstens 257 Bytes groß sein. Dadurch wird die Tiefe des auf der Blockchain nachweisbaren Taptrees begrenzt.

Zusätzlich würden Tapscripts mit OP_SUCCESS* ungültig.

Auch die Ausführung von OP_IF und OP_NOTIF innerhalb von Tapscript würde während der Aktivierung verboten.

Damit würde BIP110 bewusst auch einige der Erweiterungsmöglichkeiten einschränken, die bei Taproot für zukünftige Soft Forks vorgesehen wurden.

Was passiert mit bereits bestehenden UTXOs?

BIP110 enthält deshalb eine wichtige Grandfathering-Regel.

UTXOs, die bereits vor der Aktivierung von BIP110 erzeugt wurden, wären von den neuen Einschränkungen beim Ausgeben ausgenommen.

Damit soll verhindert werden, dass bereits vorhandene Coins allein durch die Aktivierung plötzlich nicht mehr auf die bisher vorgesehene Weise ausgegeben werden können.

Nach Ablauf des Soft Forks würden die zusätzlichen Einschränkungen wieder aufgehoben.

Warum ist BIP110 nur temporär?

BIP110 ist ausdrücklich nicht als dauerhafte Konsensänderung entworfen.

Nach der Aktivierung sollen die zusätzlichen Regeln für 52.416 Blöcke, also ungefähr ein Jahr, gelten.

Danach wechselt der Deployment-Status zu EXPIRED und die zusätzlichen Regeln werden nicht mehr durchgesetzt.

Der Grund dafür ist bemerkenswert:

Die Autoren des BIPs weisen selbst darauf hin, dass einige der Einschränkungen zukünftige Bitcoin-Upgrades erschweren könnten.

Insbesondere bislang ungenutzte Witness-Versionen und OP_SUCCESS* sind gerade als Erweiterungspunkte für zukünftige Soft Forks vorgesehen.

BIP110 würde diese Möglichkeiten deshalb nur vorübergehend einschränken.

Welche Nachteile hätte BIP110?

Die Einschränkungen sind nicht kostenlos.

Beispielsweise begrenzt die maximale Control-Block-Größe die Größe eines auf der Blockchain nachgewiesenen Taptrees. Das könnte komplexe Konstruktionen wie bestimmte BitVM-Designs einschränken.

Auch bestimmte mit Miniscript erzeugte Taproot-Konstruktionen könnten betroffen sein.

Das BIP selbst räumt deshalb ein, dass es theoretische Sonderfälle gibt, in denen bestimmte vorab signierte Taproot-Konstruktionen während der aktiven Phase problematisch werden könnten.

Gerade deshalb ist das Grandfathering bereits vorhandener UTXOs ein wichtiger Bestandteil des Vorschlags.

Warum wäre BIP110 ein Soft Fork?

Trotz dieser weitreichenden Änderungen bleibt die Richtung der Konsensänderung eindeutig.

BIP110 würde nichts erlauben, was heutige Nodes als ungültig betrachten.

Stattdessen würden zusätzliche Bedingungen eingeführt:

Eine Node ohne BIP110 könnte deshalb einen BIP110-konformen Block weiterhin akzeptieren.

Sie würde die zusätzlichen Regeln jedoch nicht überprüfen und könnte umgekehrt einen Block akzeptieren, den eine BIP110-Node ablehnt.

Genau damit erfüllt BIP110 die technische Definition eines Soft Forks.

Wie soll BIP110 aktiviert werden?

BIP110 verwendet einen modifizierten Aktivierungsmechanismus auf Basis von BIP9.

Miner signalisieren über Bit 4 im Versionsfeld ihrer Blöcke.

Für einen regulären Lock-in müssen innerhalb eines Difficulty-Zeitraums mindestens 1109 von 2016 Blöcken, also 55 %, Bit 4 setzen.

Wird diese Schwelle erreicht, wechselt das Deployment zunächst zu LOCKED_IN.

Einen Difficulty-Zeitraum später werden die eigentlichen BIP110-Konsensregeln ACTIVE.

Was passiert, wenn die 55 % nicht erreicht werden?

Hier unterscheidet sich BIP110 erheblich von einem normalen BIP9-Deployment.

Der Vorschlag besitzt keinen normalen Timeout, nach dem die Aktivierung einfach scheitert.

Stattdessen sieht er eine Mandatory-Signaling-Phase vor.

Zwischen Block 961.632 und 963.647 würden Nodes, die BIP110 durchsetzen, Blöcke ohne das vorgeschriebene Signalisierungsbit als ungültig ablehnen.

Damit könnte bereits in dieser Phase eine Chain Split entstehen, wenn ein bedeutender Teil der Miner und Nodes diese Regel nicht übernimmt.

Das ist ein wichtiger Unterschied:

Die mögliche Chain Split beginnt nicht erst mit den eigentlichen Reduced-Data-Regeln. Bereits das verpflichtende Signalisieren ist nach BIP110 eine neue Konsensregel.

Aktueller Stand von BIP110

Stand 17. August 2026 ist BIP110 nicht Teil der aktiven Bitcoin-Mainnet-Konsensregeln.

Das BIP besitzt den Status Closed. Dieser Status wurde am 9. August 2026 eingetragen.

Zuvor war die Spezifikation am 25. Juni 2026 als Complete gekennzeichnet worden. Complete bedeutet nur, dass der Text als fertiggestellt gilt. Es bedeutet nicht, dass Bitcoin die darin beschriebenen Regeln übernommen hat.

Ab Block 961632 begann nach der Spezifikation das verpflichtende Signalisieren von Bit 4.

Nodes, die BIP110 durchsetzen, behandelten Blöcke ohne dieses Bit als ungültig. Der Rest des Netzwerks akzeptierte dieselben Blöcke weiterhin.

Damit entstand genau die Situation, die weiter oben unter vorübergehende Chain Split beschrieben ist.

Auf dem BIP110-Zweig kamen danach kaum noch neue Blöcke hinzu. Im BIP-Repository wurde der Vorschlag daraufhin mit dem Hinweis auf eine Chain Split und zum Stillstand gekommenes Mining als Closed markiert.

Closed ist eine Kennzeichnung der Spezifikation. Die Konsensregeln des Bitcoin-Mainnets ergeben sich weiterhin daraus, welche Regeln Miner, wirtschaftlich relevante Teilnehmer und Full Nodes tatsächlich ausführen und durchsetzen.

BIP110 ist damit ein besonders anschauliches Beispiel dafür, dass ein festgelegter Aktivierungsplan nicht automatisch die Konsensregeln von Bitcoin verändert. Bereits das verpflichtende Signalisieren ist eine neue Konsensregel. Ob daraus eine weitergeführte Blockchain wird, hängt davon ab, ob auf dieser Regel auch weiter Blöcke erzeugt werden.

BIP118 – SIGHASH_ANYPREVOUT

BIP118 schlägt mit SIGHASH_ANYPREVOUT neue Möglichkeiten vor, festzulegen, welche Teile einer Transaktion durch eine Signatur kryptografisch gebunden werden.

Der entscheidende Unterschied zu den heute üblichen Sighash-Verfahren betrifft den Previous Output eines Inputs.

Normalerweise bindet eine Signatur den Input an eine bestimmte UTXO:

BIP118 ermöglicht dagegen Signaturen, die nicht an genau diesen Outpoint gebunden sind.

Dadurch kann eine bereits erzeugte Signatur unter bestimmten Bedingungen auch verwendet werden, wenn die Transaktion später an eine andere kompatible UTXO gebunden wird. BIP118 bezeichnet dieses Prinzip als dynamic rebinding.

Was würde ANYPREVOUT ändern?

Ein normaler Taproot-Sighash bindet verschiedene Informationen über den ausgegebenen Input in die Signatur ein.

Dazu gehört insbesondere der Outpoint aus Previous TXID und vout.

Ändert sich dieser Outpoint, verändert sich normalerweise auch die zu signierende Nachricht.

Die vorhandene Signatur passt dann nicht mehr.

Mit SIGHASH_ANYPREVOUT wird der Outpoint dagegen nicht in den Signatur-Hash aufgenommen.

Das bedeutet nicht, dass eine solche Signatur jede beliebige UTXO ausgeben könnte.

Bei SIGHASH_ANYPREVOUT bleiben unter anderem der Betrag und der scriptPubKey des ausgegebenen Outputs Bestandteil der Signaturberechnung.

Zwei Varianten

BIP118 definiert zwei neue Sighash-Modifikatoren: SIGHASH_ANYPREVOUT (0x40) und SIGHASH_ANYPREVOUTANYSCRIPT (0xc0).

Bei SIGHASH_ANYPREVOUTANYSCRIPT geht BIP118 deutlich weiter: Zusätzlich zum Outpoint werden unter anderem auch Amount, scriptPubKey und der Tapleaf-Hash nicht in die Signatur eingebunden.

Welche Outputs und Transaktionsbestandteile zusätzlich gebunden werden, hängt weiterhin von den verwendeten Sighash-Flags wie SIGHASH_ALL, SIGHASH_NONE oder SIGHASH_SINGLE ab.

Wofür wird das benötigt?

Der wichtigste Anwendungsfall sind Off-Chain-Protokolle.

Solche Protokolle können Transaktionen bereits im Voraus signieren, obwohl diese möglicherweise erst viel später veröffentlicht werden.

Das Problem:

Ändert sich die Transaktion, auf die eine vorbereitete Folgetransaktion reagieren soll, kann sich auch deren TXID ändern.

Da TX B normalerweise auf TXID A festgelegt wurde, müsste eine neue Signatur erzeugt werden.

ANYPREVOUT kann diese feste Bindung lösen:

Solange die jeweiligen Bedingungen von BIP118 erfüllt werden, kann dieselbe vorbereitete Reaktion dynamisch an den tatsächlich entstandenen Previous Output gebunden werden.

Eltoo

Ein besonders wichtiger Anwendungsfall ist eltoo, ein vorgeschlagener alternativer Mechanismus für Lightning-Channels.

Bei heutigen Lightning-Konstruktionen muss verhindert werden, dass ein Teilnehmer einen veralteten Channel-State veröffentlicht.

Eltoo verfolgt stattdessen vereinfacht das Prinzip:

Ein neuerer State kann einen älteren State ersetzen.

ANYPREVOUT erleichtert das, weil eine vorbereitete State-Transaktion nicht mehr zwingend an die konkrete TXID ihres Vorgängers gebunden sein muss.

Bitcoin Optech nennt einen NOINPUT-/ANYPREVOUT-artigen Sighash deshalb als notwendige Grundlage für das vorgeschlagene Eltoo-Design.

Die genaue Funktionsweise von Eltoo betrachten wir später im Bereich Lightning.

Warum gilt ANYPREVOUT nur für bestimmte Taproot-Scripts?

BIP118 würde ANYPREVOUT nicht einfach für jede bestehende Bitcoin-Signatur aktivieren.

Der Vorschlag definiert dafür einen neuen Public-Key-Typ innerhalb von Tapscript.

Ein BIP118-Public-Key wird entweder durch einen einzelnen Bytewert 0x01 oder durch einen 33-Byte-Wert mit dem Präfix 0x01 gekennzeichnet.

Diese Public Keys werden heute nach den Tapscript-Regeln als unbekannter Public-Key-Typ behandelt.

Genau darin liegt der Soft-Fork-Mechanismus.

Damit nutzt BIP118 genau einen Erweiterungsmechanismus, der mit Taproot für zukünftige Soft Forks vorgesehen wurde.

Warum wäre BIP118 ein Soft Fork?

Das ist bei BIP118 besonders interessant, weil es zunächst so aussieht, als würde Bitcoin etwas lockern:

Das könnte zunächst wie ein Hard Fork wirken.

Entscheidend ist jedoch, dass BIP118 nicht die Regeln für bestehende Public Keys lockert.

Stattdessen bekommt ein bisher unbekannter Tapscript-Public-Key-Typ eine neue Bedeutung.

Aus Sicht der heutigen Nodes wird also kein bestehender Signaturtyp gelockert.

Aktualisierte Nodes führen vielmehr zusätzliche Prüfungen für einen bisher reservierten Erweiterungsbereich durch.

Genau dadurch lässt sich ANYPREVOUT als Soft Fork einführen.

Das ist ein weiteres gutes Beispiel dafür, warum Bitcoin trotz immer strenger werdender Soft-Fork-Regeln neue Funktionalität erhalten kann:

Taproot hat bewusst Erweiterungsbereiche offengelassen, denen spätere Soft Forks strengere Regeln geben können.

Welche Risiken entstehen?

Dass eine Signatur nicht mehr an einen bestimmten Outpoint gebunden ist, bringt neue Risiken mit sich.

BIP118 nennt insbesondere Signature Replay.

Eine ANYPREVOUT-Signatur kann unter bestimmten Bedingungen für eine andere UTXO erneut verwendet werden.

Bei SIGHASH_ANYPREVOUT betrifft das beispielsweise unterschiedliche UTXOs mit demselben scriptPubKey und demselben Betrag.

Bei SIGHASH_ANYPREVOUTANYSCRIPT sind die Möglichkeiten noch größer.

Implementierungen müssen deshalb verhindern, dass BIP118-Schlüssel auf eine Weise wiederverwendet werden, bei der ein solches Replay zum Verlust von Bitcoin führen könnte.

BIP118 diskutiert außerdem zusätzliche Malleability- und Privacy-Auswirkungen.

ANYPREVOUT ist deshalb kein Ersatz für normale Signaturen, sondern ein gezielt einsetzbarer Mechanismus für Protokolle, die diese Eigenschaft tatsächlich benötigen.

Was würde BIP118 an der Validierung ändern?

BIP118 würde vor allem die Script-Regeln der Transaktionsvalidierung erweitern.

Die heutige Taproot-Prüfung kennt BIP118-Public-Keys noch nicht als eigenen Signaturtyp.

Nach einer Aktivierung würde die Script Engine bei entsprechenden Tapscripts zusätzliche Regeln anwenden:

Die bestehenden Taproot-Regeln würden damit nicht ersetzt, sondern um einen weiteren definierten Tapscript-Public-Key-Typ ergänzt.

Aktueller Stand von BIP118

Stand 17. August 2026 ist BIP118 nicht im Bitcoin-Mainnet aktiviert.

Das BIP ist weiterhin als Consensus Soft Fork klassifiziert und besitzt den Status Draft.

Es existiert damit derzeit keine Aktivierungshöhe und keine BIP118-Konsensregel, die Mainnet-Full-Nodes durchsetzen müssten.

ANYPREVOUT wurde jedoch bereits über mehrere Jahre diskutiert und experimentell getestet, unter anderem im Zusammenhang mit Eltoo und anderen Off-Chain-Konstruktionen.

BIP118 ist damit derzeit ein Vorschlag für einen möglichen zukünftigen Soft Fork, nicht Bestandteil der aktiven Bitcoin-Konsensregeln.

BIP119 – CHECKTEMPLATEVERIFY

BIP119 schlägt mit OP_CHECKTEMPLATEVERIFY (CTV) einen neuen Bitcoin-Script-Befehl vor.

CTV ermöglicht sogenannte Covenants: Ein Output kann nicht nur festlegen, unter welchen Bedingungen seine Coins ausgegeben werden dürfen, sondern zusätzlich bestimmte Eigenschaften der zukünftigen ausgebenden Transaktion vorgeben.

Dafür enthält das Script einen 32-Byte-Hash, der ein bestimmtes Transaktions-Template festlegt.

Beim Ausgeben berechnet die Node aus der tatsächlichen Transaktion erneut den sogenannten DefaultCheckTemplateVerifyHash.

Nur wenn beide Hashes übereinstimmen, ist die Ausgabe erlaubt.

Was ist ein Transaktions-Template?

CTV legt nicht einfach die vollständige zukünftige Transaktion Byte für Byte fest.

Stattdessen wird ein Hash aus bestimmten Eigenschaften der späteren Transaktion gebildet.

Der DefaultCheckTemplateVerifyHash bindet unter anderem an:

Damit kann ein Output beispielsweise festlegen:

Wenn diese Coins ausgegeben werden, muss die ausgebende Transaktion genau die vorgesehenen Outputs erzeugen.

Der konkrete Previous Outpoint sowie die Beträge der Inputs werden dagegen nicht direkt in den CTV-Hash aufgenommen.

Wie funktioniert CHECKTEMPLATEVERIFY?

Vereinfacht könnte ein CTV-Script so aussehen:

<32-Byte Template Hash> OP_CHECKTEMPLATEVERIFY

Wird der Output später ausgegeben, passiert konzeptionell:

Die Node überprüft damit nicht eine Signatur, sondern ob die ausgebende Transaktion dem vorher festgelegten Template entspricht.

Ein einfaches Beispiel

Alice besitzt einen Output über 1 BTC.

Normalerweise könnte ein entsprechender Schlüssel die Coins beispielsweise an beliebige neue Outputs senden.

Mit CTV könnte Alice stattdessen bereits beim Erzeugen des Outputs festlegen:

Der CTV-Output enthält dafür nicht diese komplette Transaktion, sondern den Hash ihres Templates.

Eine Transaktion mit anderen Outputs würde einen anderen Template-Hash erzeugen:

Damit können die Ausgabebedingungen einer UTXO auf zukünftige Transaktionen übertragen werden.

Warum nennt man das einen Covenant?

Bei normalen Bitcoin-Scripts geht es hauptsächlich darum, welche Bedingungen erfüllt werden müssen, um eine UTXO auszugeben.

Beispielsweise:

Ein Covenant kann zusätzlich einschränken, was mit den Coins anschließend passieren darf.

CTV ist dabei bewusst eine relativ eingeschränkte Form von Covenant.

Das Script kann nicht beliebige Eigenschaften einer zukünftigen Transaktion dynamisch untersuchen. Es vergleicht die Transaktion mit einem vorher festgelegten Hash-Commitment. Bitcoin Optech beschreibt CTV entsprechend als Mechanismus, mit dem ein Output bestimmen kann, wie seine Mittel ausgegeben werden dürfen.

Wofür könnte CTV verwendet werden?

Ein wichtiger vorgeschlagener Anwendungsbereich sind Vaults.

Ein Vault soll beispielsweise ermöglichen, dass Bitcoin zunächst nur über einen kontrollierten Ablauf bewegt werden können:

Statt einem Angreifer nach dem Diebstahl eines Schlüssels sofort beliebige Ausgaben zu ermöglichen, könnten die möglichen Folgewege bereits durch die Konstruktion des Vaults eingeschränkt werden.

BIP119 verweist unter anderem auf verschiedene Vault-Konstruktionen als möglichen Anwendungsfall.

Ein weiterer Anwendungsbereich ist Congestion Control.

Dabei kann zunächst ein einzelner Output bestätigt werden, der bereits auf eine spätere Transaktion mit vielen Empfängern festgelegt ist:

Die große Verteilung kann anschließend zu einem günstigeren Zeitpunkt bestätigt werden.

Bitcoin Optech nennt neben Congestion Control unter anderem Vaults, Payment Pools, Channels und verschiedene Off-Chain-Protokolle als diskutierte Anwendungen von CTV.

Was ist der Unterschied zu ANYPREVOUT?

BIP118 und BIP119 verändern beide, welche Transaktionsstrukturen im Voraus festgelegt werden können, verfolgen aber unterschiedliche Ansätze.

Vereinfacht:

ANYPREVOUT verändert also die Signaturbindung.

CTV führt dagegen eine neue Script-Bedingung für Transaktions-Templates ein.

Warum wäre BIP119 ein Soft Fork?

BIP119 verwendet dafür einen bereits existierenden Opcode: OP_NOP4 (0xb3).

Heute besitzt OP_NOP4 auf Konsensebene keine entsprechende CTV-Prüfsemantik.

BIP119 würde diesem Opcode eine strengere Bedeutung geben:

Damit entsteht wieder das typische Soft-Fork-Verhältnis.

Eine alte Node überprüft die neue Bedingung nicht.

Eine aktualisierte Node akzeptiert dagegen nur noch die Teilmenge der Ausgaben, welche die zusätzliche CTV-Regel erfüllen.

Das gleiche grundsätzliche Verfahren wurde bereits bei früheren Soft Forks verwendet.

OP_CHECKLOCKTIMEVERIFY ersetzte OP_NOP2 und OP_CHECKSEQUENCEVERIFY ersetzte OP_NOP3.

CTV würde diese Reihe mit OP_NOP4 fortsetzen.

Was würde BIP119 an der Validierung ändern?

BIP119 würde vor allem die Script-Regeln der Transaktionsvalidierung erweitern.

Während der Ausführung eines Scripts müsste die Script Engine bei OP_CHECKTEMPLATEVERIFY zusätzliche Daten aus der aktuellen Transaktion verwenden:

Wichtig ist dabei eine Besonderheit der aktuellen BIP119-Spezifikation:

Ist das Stack-Element genau 32 Bytes lang, besitzt es die definierte CTV-Bedeutung.

Andere Längen bleiben auf Konsensebene zunächst NOP-artig und können damit als Erweiterungsraum für zukünftige Soft Forks dienen. Für die Standard-Policy empfiehlt BIP119 dagegen, solche Verwendungen abzulehnen.

Welche Risiken und Einschränkungen gibt es?

CTV macht bestimmte zukünftige Ausgabepfade bereits beim Erzeugen einer UTXO verbindlich.

Das kann gewollt sein, bedeutet aber auch:

BIP119 nennt deshalb ausdrücklich das Risiko permanent unausgebbarer Outputs.

CTV bringt außerdem eine neue Form der Programmierbarkeit in Bitcoin, weshalb seit Jahren diskutiert wird, wie viel Covenant-Funktionalität Bitcoin besitzen sollte und ob andere vorgeschlagene Mechanismen flexibler oder besser kombinierbar wären.

Aktueller Stand von BIP119

Stand 17. August 2026 ist BIP119 nicht im Bitcoin-Mainnet aktiviert.

Das BIP ist als Consensus Soft Fork klassifiziert und besitzt weiterhin den Status Draft.

Besonders wichtig ist der Unterschied zu einem BIP mit bereits definiertem Aktivierungsverfahren:

Die aktuelle BIP119-Spezifikation legt keinen konkreten Aktivierungsmechanismus fest. Der Abschnitt Deployment lässt die eigentliche Aktivierungslogik ausdrücklich offen.

Es gibt daher derzeit weder eine Mainnet-Aktivierungshöhe noch einen durch BIP119 festgelegten laufenden Signalisierungsprozess.

OP_NOP4 besitzt im aktuellen Bitcoin-Mainnet weiterhin nicht die von BIP119 vorgeschlagene OP_CHECKTEMPLATEVERIFY-Konsenssemantik.

BIP119 ist damit weiterhin ein Vorschlag für einen möglichen zukünftigen Soft Fork.

BIP347 – OP_CAT in Tapscript

BIP347 schlägt vor, den historischen Bitcoin-Script-Befehl OP_CAT innerhalb von Tapscript wieder einzuführen.

OP_CAT besitzt eine sehr einfache Funktion:

Die beiden obersten Elemente des Stacks werden zu einem einzigen Byte-String zusammengefügt.

Die Operation selbst ist damit wesentlich einfacher als viele andere vorgeschlagene Script-Erweiterungen.

Ihre Bedeutung entsteht daraus, dass Scripts anschließend mit dem zusammengesetzten Wert weiterarbeiten können.

Wie würde OP_CAT funktionieren?

Bei der Ausführung nimmt OP_CAT die beiden obersten Stack-Elemente [x1, x2], wobei x2 oben auf dem Stack liegt.

Anschließend werden beide Elemente entfernt und x1 || x2 wieder auf den Stack gelegt.

|| bedeutet dabei die Konkatenation der beiden Bytefolgen.

Die Operation schlägt fehl, wenn weniger als zwei Elemente auf dem Stack liegen.

Außerdem darf das Ergebnis nicht größer als 520 Bytes sein, die bestehende maximale Größe eines einzelnen Script-Stack-Elements.

BIP347 würde die bestehende 520-Byte-Grenze ausdrücklich nicht erhöhen.

OP_CAT gab es bereits in Bitcoin

OP_CAT ist streng genommen kein vollständig neuer Bitcoin-Opcode.

Er war bereits in frühen Bitcoin-Versionen vorhanden.

2010 deaktivierte Satoshi OP_CAT zusammen mit mehreren anderen Opcodes.

Ein häufig genannter Grund war die Möglichkeit, durch wiederholtes Kombinieren von OP_DUP und OP_CAT sehr schnell große Datenmengen zu erzeugen.

Vereinfacht:

Ohne Größenbegrenzung wächst das Ergebnis exponentiell.

BIP347 weist allerdings darauf hin, dass dieses Problem bei der vorgeschlagenen Tapscript-Version durch die bestehende 520-Byte-Grenze für Stack-Elemente begrenzt wird.

Wichtig ist dabei:

BIP347 würde OP_CAT nicht allgemein für alte Bitcoin-Scripts reaktivieren.

Außerhalb von Tapscript bliebe der Opcode weiterhin deaktiviert.

Warum ist das Zusammenfügen von Daten überhaupt nützlich?

Tapscript kann Daten auf dem Stack bereits vergleichen, hashen und kryptografisch prüfen.

Es besitzt jedoch keinen allgemeinen Befehl, um zwei getrennte Bytefolgen wieder zu einer gemeinsamen Bytefolge zusammenzusetzen.

Gerade bei kryptografischen Konstruktionen ist diese Fähigkeit wichtig.

So können beispielsweise Datenstrukturen aus mehreren Stack-Elementen zusammengesetzt und anschließend mit OP_SHA256 oder anderen vorhandenen Script-Befehlen verarbeitet werden.

BIP347 nennt unter anderem die Konstruktion und Prüfung von Merkle Trees und anderen gehashten Datenstrukturen als Motivation.

Welche Anwendungen könnte OP_CAT ermöglichen?

Obwohl OP_CAT selbst nur Bytefolgen zusammenfügt, kann diese primitive Operation als Baustein für deutlich komplexere Konstruktionen dienen.

BIP347 nennt unter anderem:

Insbesondere die Covenant-Eigenschaften sind interessant. BIP347 nennt außerdem Verbesserungen für BitVM.

In Verbindung mit den bereits vorhandenen kryptografischen Operationen kann OP_CAT Konstruktionen ermöglichen, bei denen ein Script Informationen über eine Transaktion kryptografisch bindet und dadurch Bedingungen für zukünftige Ausgaben durchsetzt.

Damit verfolgt BIP347 einen anderen Ansatz als CHECKTEMPLATEVERIFY.

CTV stellt eine relativ spezifische Template-Operation bereit. OP_CAT stellt dagegen einen wesentlich allgemeineren Baustein bereit:

Diese größere Allgemeinheit ist gleichzeitig ein Grund dafür, warum die möglichen Auswirkungen von OP_CAT besonders sorgfältig untersucht werden.

Post-Quantum-Signaturen

Ein weiterer diskutierter Anwendungsfall sind hashbasierte Signaturen.

BIP347 nennt insbesondere Lamport-Signaturen. Neuere Experimente zeigen außerdem, dass mit OP_CAT beispielsweise Winternitz-Signaturen innerhalb von Bitcoin Script konstruiert werden können.

Das bedeutet allerdings nicht, dass die Aktivierung von OP_CAT Bitcoin automatisch quantensicher machen würde.

Die heutigen ECDSA- und Schnorr-Schlüssel blieben weiterhin bestehen. Insbesondere besitzt ein normaler Taproot-Output zusätzlich seinen Key Path, dessen elliptische Kurvenkryptografie durch einen ausreichend leistungsfähigen Quantencomputer angreifbar wäre.

OP_CAT wäre deshalb höchstens ein möglicher Baustein für zukünftige Post-Quantum-Konstruktionen, nicht selbst die Lösung des Quantencomputer-Problems.

Wie würde OP_CAT aktiviert?

BIP347 nutzt bewusst einen Erweiterungsmechanismus, der bereits mit Taproot eingeführt wurde.

Tapscript besitzt reservierte Opcodes namens OP_SUCCESSx.

BIP347 würde OP_SUCCESS126 mit dem Opcode-Wert 126 dezimal bzw. 0x7e hex als OP_CAT definieren.

Das ist kein zufällig gewählter Wert.

0x7e war bereits der Opcode-Wert des ursprünglichen OP_CAT.

Warum wäre BIP347 ein Soft Fork?

Hier zeigt sich besonders gut, warum OP_SUCCESSx als zukünftiger Erweiterungsmechanismus in Taproot eingebaut wurde.

Nach den heutigen Tapscript-Regeln führt das Auftreten eines OP_SUCCESSx dazu, dass das Script erfolgreich ist.

Eine alte Node kennt deshalb die neue Bedeutung von OP_CAT nicht:

Eine aktualisierte Node würde also zusätzliche Bedingungen für etwas prüfen, das eine alte Node bereits akzeptiert.

Damit entsteht wieder das typische Soft-Fork-Verhältnis:

BIP347 nutzt damit genau den mit BIP342 vorgesehenen OP_SUCCESSx-Upgrade-Pfad.

Was würde BIP347 an der Validierung ändern?

BIP347 würde vor allem die Script-Regeln der Transaktionsvalidierung erweitern.

Die bestehende Taproot-Validierung würde bei Tapscript zusätzlich die neue Bedeutung von 0x7e berücksichtigen:

Andere Script-Versionen wären davon nicht betroffen.

Dort bleibt OP_CAT weiterhin ein deaktivierter Opcode und führt weiterhin zu SCRIPT_ERR_DISABLED_OPCODE.

Aktueller Stand von BIP347

Stand 17. August 2026 ist BIP347 nicht im Bitcoin-Mainnet aktiviert.

Das BIP ist als Consensus Soft Fork klassifiziert und besitzt inzwischen den Status Complete.

Die Version 1.0.0 wurde am 1. März 2026 als vollständig markiert.

Complete bedeutet auch hier nicht, dass OP_CAT Bestandteil der aktiven Bitcoin-Konsensregeln geworden ist.

Es bedeutet, dass die Spezifikation des BIPs als fertiggestellt gilt.

Im aktuellen Mainnet gilt daher weiterhin:

Eine konkrete Mainnet-Aktivierung von BIP347 ist derzeit nicht Bestandteil der aktiven Bitcoin-Konsensregeln.

BIP347 ist damit ein besonders anschauliches Beispiel für die bewusst eingebauten Erweiterungsmöglichkeiten von Taproot: Ein bisher sehr permissiv behandelter OP_SUCCESSx-Opcode kann durch einen späteren Soft Fork eine konkrete, strengere Bedeutung erhalten.

Hard Forks und Konsensprobleme in der Geschichte von Bitcoin

Auch Hard Forks und unbeabsichtigte Konsensprobleme gehören zur Geschichte von Bitcoin.

Dabei muss zwischen bewusst eingeführten inkompatiblen Konsensregeln und unbeabsichtigten Abweichungen bei der Blockvalidierung unterschieden werden.

Bewusste Hard Forks

Hard Forks können bewusst eingesetzt werden, um Konsensregeln so zu verändern, dass Blöcke erlaubt werden, die nach dem bisherigen Regelwerk ungültig wären.

Wird das neue Regelwerk von einem Teil der Teilnehmer übernommen und werden anschließend beide Regelwerke dauerhaft weitergeführt, können daraus zwei voneinander unabhängige Blockchains entstehen.

In der Geschichte von Bitcoin ist dafür vor allem die Entstehung von Bitcoin Cash relevant.

2017 – Bitcoin Cash

Am 1. August 2017 spaltete sich Bitcoin Cash (BCH) von Bitcoin ab.

Ausgangspunkt war insbesondere der jahrelange Konflikt darüber, wie die Transaktionskapazität von Bitcoin erhöht werden sollte.

Bitcoin Cash änderte die Konsensregeln so, dass deutlich größere Blöcke erlaubt waren.

Damit konnten Bitcoin-Cash-Miner Blöcke erzeugen, die von Bitcoin-Nodes aufgrund ihrer Größe als ungültig abgelehnt wurden.

Bis zum Fork besaßen beide Netzwerke dieselbe Blockchain-Historie:

Der letzte gemeinsame Block lag auf Höhe 478.558. Anschließend wurden die beiden Regelwerke unabhängig weitergeführt.

Das ist der entscheidende Unterschied zu einem normalen kurzfristigen Chain Split:

Keine der beiden Seiten kehrte später zur anderen Blockchain zurück.

Stattdessen entstanden zwei dauerhaft getrennte Netzwerke mit gemeinsamer Historie bis zum Fork.

Bitcoin selbst übernahm die neuen Bitcoin-Cash-Regeln dabei nicht.

Bitcoin Cash ist deshalb präziser beschrieben als eine neue, durch einen Hard Fork aus der Bitcoin-Historie entstandene Blockchain.

2018 – Bitcoin SV

Am 15. November 2018 kam es innerhalb von Bitcoin Cash erneut zu einem Konflikt über die zukünftigen Konsensregeln.

Dabei standen sich insbesondere die Implementierungen Bitcoin ABC und Bitcoin SV gegenüber.

Die Bitcoin-ABC-Seite führte unter anderem eine kanonische Reihenfolge von Transaktionen und neue Script-Opcodes ein. Bitcoin SV verfolgte dagegen ein anderes Regelwerk und erhöhte unter anderem das Blockgrößenlimit auf 128 MB.

Da beide Seiten inkompatible Regeln verwendeten und anschließend weiter Blöcke erzeugten, entstanden erneut zwei dauerhafte Blockchains:

Der Split fand auf der Bitcoin-Cash-Blockchain bei Höhe 556.766 statt. Ab dem folgenden Block existierten unterschiedliche BCH- und BSV-Historien.

Bitcoin SV ist deshalb kein direkter Hard Fork der Bitcoin-Blockchain von 2018.

Seine Abstammung lautet:

Das Beispiel zeigt außerdem, dass eine durch einen Hard Fork entstandene Blockchain später selbst wieder durch weitere Hard Forks aufgeteilt werden kann.

Unbeabsichtigte Konsensprobleme

Nicht jede Aufspaltung der Blockchain entsteht durch eine bewusst geplante Änderung der Konsensregeln.

Softwarefehler oder unterschiedliche Interpretationen bestehender Regeln können ebenfalls dazu führen, dass Nodes denselben Block unterschiedlich bewerten.

Der entscheidende Unterschied zu Bitcoin Cash und Bitcoin SV besteht darin, dass solche Ereignisse nicht mit dem Ziel entstehen, dauerhaft zwei verschiedene Netzwerke weiterzuführen.

2010 – Value-Overflow-Bug

Im August 2010 wurde ein schwerwiegender Fehler in den damaligen Bitcoin-Konsensregeln ausgenutzt.

Die Überprüfung der Transaktionsbeträge erkannte einen Integer-Overflow bei der Berechnung der Output-Summe nicht korrekt.

Dadurch konnte eine Transaktion erstellt werden, deren Outputs zusammen eine enorme Menge Bitcoin erzeugten.

Die Transaktion wurde in Block 74.638 aufgenommen.

Damit enthielt die Blockchain plötzlich Bitcoin, deren Erzeugung nach dem beabsichtigten Emissionsmodell niemals hätte möglich sein sollen. Neue Bitcoin entstehen nur über die Coinbase, nicht durch eine solche Overflow-Transaktion.

Der Fehler wurde kurz darauf behoben.

Nodes wechselten auf die korrigierte Software und die Blockchain wurde von einer Historie ohne die Overflow-Transaktion weitergeführt.

Das Ziel war also nicht, zwei getrennte Regelwerke dauerhaft weiterzuführen:

Stattdessen sollte der fehlerhafte Konsenszustand korrigiert und eine gemeinsame Blockchain weitergeführt werden:

Der Value-Overflow-Bug ist deshalb kein Beispiel für die bewusste Gründung einer neuen Kryptowährung durch einen Hard Fork, sondern für die Behebung eines kritischen Konsensfehlers.

2013 – Unbeabsichtigte Chain Split zwischen Bitcoin 0.7 und 0.8

Am 11. März 2013 kam es tatsächlich zu einer vorübergehenden Aufspaltung der Bitcoin-Blockchain.

Auslöser war Block 225.430.

Bitcoin 0.8 verwendete für die Blockdatenbank LevelDB, während Bitcoin 0.7 und ältere Versionen Berkeley DB verwendeten.

Der neue Block führte bei älteren Nodes zu einer Berkeley-DB-Lock-Grenze.

Dadurch entstand eine besonders gefährliche Situation: Dieselbe Blockvalidierung kam bei unterschiedlichen Node-Versionen zu unterschiedlichen Ergebnissen.

Miner bauten zeitweise auf beiden Ketten weitere Blöcke.

Bitcoin hatte damit tatsächlich zwei konkurrierende Blockchain-Spitzen.

Um die Netzwerkteilung zu beenden, wurden große Mining-Pools gebeten, vorübergehend wieder mit Bitcoin 0.7 kompatible Blöcke zu erzeugen.

Dadurch erhielt diese Kette genügend weitere akkumulierte Arbeit und das Netzwerk konvergierte wieder auf eine gemeinsame Blockchain. Bitcoin 0.8.1 wurde anschließend so angepasst, dass zunächst keine mit älteren Nodes inkompatiblen Blöcke erzeugt wurden.

Dieses Ereignis ist besonders wichtig für das Verständnis von Konsens:

Die beiden Node-Versionen hatten nicht bewusst beschlossen, unterschiedliche Bitcoin-Regeln zu verwenden.

Ein Implementierungsunterschied führte unbeabsichtigt dazu, dass sie denselben Block unterschiedlich bewerteten.

Genau das ist die Situation, die bei Konsenssoftware unbedingt vermieden werden muss:

Der Unterschied zu Bitcoin Cash lässt sich damit auf einen Satz reduzieren:

2017 wurde eine inkompatible Regeländerung bewusst weitergeführt und daraus entstand eine dauerhafte zweite Blockchain. 2013 war die Aufspaltung unbeabsichtigt und die Teilnehmer koordinierten sich darauf, wieder zu einer gemeinsamen Bitcoin-Blockchain zurückzukehren.