Was ist ein Soft Fork? Bitcoin-Rückwärtskompatibilität erklärt
Block 481.824. An diesem Punkt, dem 24. August 2017, wurde der erste große moderne Soft Fork von Bitcoin, SegWit, in das Protokoll integriert. Diese Zahl ist wichtig, da ein Soft Fork die Art und Weise ist, wie sich eine Blockchain wie Bitcoin aktualisiert, ohne das Netzwerk zu spalten. Neue Regeln werden eingeführt. Die alte Software läuft weiter. Beide bleiben auf derselben Blockchain.
Fragt man die meisten Leute, was ein Soft Fork ist, erhält man eine kurze Antwort: eine abwärtskompatible Änderung eines Blockchain-Protokolls. Technisch korrekt. Nicht besonders hilfreich. Die Realität ist komplexer und interessanter. Ein Soft Fork ist das Ergebnis eines langsamen Prozesses: Entwickler schlagen Regeländerungen vor, Miner signalisieren ihre Unterstützung oder lehnen sie stillschweigend ab, Node-Betreiber wählen die zu verwendende Software aus, und Nutzer legen im Hintergrund fest, was als Bitcoin gilt. Dieser Artikel erklärt die Mechanismen in einfachen Worten. Anschließend werden die klassischen Beispiele (SegWit und Taproot) auf Block-für-Block-Ebene gezeigt. Und er endet mit der hitzigen Debatte darüber, was als Nächstes per Soft Fork angepasst werden soll.
Soft Fork Definition: Ein rückwärtskompatibles Blockchain-Upgrade
Man kann sich einen Soft Fork als eine Verschärfung der Regeln vorstellen. Alles, was nach den neuen Regeln legal ist, bleibt auch nach den alten Regeln legal. Alte Nodes akzeptieren neue Blöcke also weiterhin problemlos. Neue Nodes lehnen zwar Blöcke im alten Stil ab, die gegen die verschärften Regeln verstoßen, aber die Regeln selbst sind strenger, nicht anders. Die Dynamik des Netzwerks bleibt gleich. Lediglich die Definition dessen, was als gültig gilt, ändert sich.
Ein gutes Beispiel: Bitcoins BIP 16, die Pay-to-Script-Hash-Fork (P2SH). Sie wurde am 1. April 2012 bei Block 173.805 aktiviert. Vor BIP 16 existierte der Transaktionstyp P2SH im Bitcoin-Skript nicht. Nach der Veröffentlichung erzwangen aktualisierte Nodes P2SH. Ältere Nodes sahen dieselben Ausgaben und erkannten ein ungewöhnliches Skript, das jeder ausgeben konnte. Sie zuckten mit den Schultern und akzeptierten die Blöcke trotzdem. Sie wussten nichts von der Regel, die es zu brechen galt. Die Blockchain blieb einheitlich, da die neue Regel eine Teilmenge der alten war. Bitcoin hatte dadurch still und leise eine neue Funktion erhalten.
Das ist also der Clou: Ältere Software akzeptiert eine Obermenge, die alles umfasst, was neuere Software akzeptiert. Keine Kettenaufspaltung. Keine Frist für die Geltendmachung von Ansprüchen. Keine neue Kryptowährung. Das Blockchain-Netzwerk erzeugt weiterhin eine einzige Kette, der alle zustimmen, unabhängig von der verwendeten Softwareversion. Es ist ein erstaunlich elegantes Beispiel für Social Engineering, das wie eine einfache Softwareänderung aussieht.
Diese Eigenschaft ist auch das entscheidende Kriterium, das einen Soft Fork von Inkompatibilitäten mit älterer Software unterscheidet. Wenn ein Upgrade einen zuvor gültigen Block für die alte Software plötzlich ungültig erscheinen lässt, handelt es sich nicht um einen Soft Fork, sondern um einen Hard Fork. Die Prioritäten ändern sich grundlegend. In der Blockchain-Technologie lässt sich die Unterscheidung zwischen diesen beiden Fork-Typen auf eine praktische Frage reduzieren: Akzeptieren Nodes, die kein Upgrade durchführen, die neuen Blöcke weiterhin als gültig?
Weiche Gabel vs. harte Gabel: Der wirkliche Unterschied
Bei einer Hard Fork verläuft die Sache andersherum. Dabei werden die Regeln gelockert oder so geändert, dass die alte Software sie sofort ablehnt. Alte Knoten prüfen einen neuen Block, halten ihn für ungültig und verweigern die Ausführung. Entweder aktualisieren alle ihre Systeme, oder das Netzwerk spaltet sich. Das sind die einzigen beiden Möglichkeiten.
Zwei Fälle treten häufig auf. Die DAO-Abspaltung von Ethereum am 20. Juli 2016 bei Block 1.920.000 verschob etwa 12 Millionen ETH aus zwei kompromittierten Smart Contracts. Alte Nodes lehnten diese Änderung ab, betrieben die ursprüngliche Blockchain weiter, und aus dieser Ablehnung entstand Ethereum Classic. Bitcoin Cash folgte ein Jahr später. Am 1. August 2017 bei Block 478.559 erhöhte Bitcoin Cash die Blockgrößenbegrenzung von 1 MB auf 8 MB. Alte Bitcoin-Nodes lehnten die größeren Blöcke sofort ab. Von diesem Zeitpunkt an war Bitcoin Cash eine eigenständige Kryptowährung auf einer neuen Blockchain.
Ein Soft Fork umgeht dieses ganze Chaos von vornherein. Die alten Nodes müssen nichts unternehmen. Sie validieren weiterhin Blöcke gemäß ihren weniger restriktiven Regeln. Sobald eine klare Mehrheit der Miner die neuen Regeln durchsetzt, ist jeder geschürfte Block nach beiden Regelsätzen gleichzeitig gültig. Eine einzige ökonomische Kette. Ein einziges Ledger. Diese Asymmetrie ist der strukturelle Grund dafür, dass in der Bitcoin-Kultur Soft Forks standardmäßig bevorzugt werden und Hard Forks nur als letzte Option gelten.

Wie ein Soft Fork bei Bitcoin tatsächlich aktiviert wird
Die meisten Erklärungen hören hier auf. Sie sagen, ein Soft Fork „verschärft die Regeln“ und gehen zum nächsten Punkt über. Was aber niemand zu erklären scheint, ist, wie diese Verschärfung tatsächlich umgesetzt wird. Ein Soft Fork ist kein Schalter, den ein Entwickler einfach umlegt. Es ist ein langsamer, manchmal unschöner Koordinationsprozess. Und diese Koordination wurde in Bitcoin selbst integriert.
Die klassische Aktivierungsmethode ist das Miner-Signal. Ein vorgeschlagener Soft Fork wird zu einem Bitcoin Improvement Proposal (BIP) und erhält ein Bit im Versionsfeld des Blockheaders. Miner mit aktualisierter Software ändern dieses Bit. Die Mining-Leistung dieser Blöcke dient dem restlichen Netzwerk als Signal zur Beurteilung der Bereitschaft. Sobald der Anteil der signalisierenden Blöcke innerhalb eines definierten Zeitraums einen Schwellenwert überschreitet, wird der Fork aktiviert. Das bis 2017 verwendete Modell war BIP 9: 95 % innerhalb eines gleitenden Blockfensters von 2016. BIP 8 folgte später. Er führte eine feste Frist ein, um zu verhindern, dass ein ins Stocken geratener Vorschlag unbegrenzt weiterläuft.
Dieses Modell funktionierte, bis es nicht mehr funktionierte. Anfang 2017 stagnierte SegWit monatelang bei einer Miner-Unterstützung von 30 bis 45 Prozent. Große Miner hatten Gründe, das Signal nicht zu senden – und keiner davon war schmeichelhaft. Die Community musste einen Ausweg finden. BIP 91 senkte die effektive Schwelle und wurde schnell veröffentlicht. Parallel dazu setzte eine andere Bewegung, der nutzeraktivierte Soft Fork BIP 148, den 1. August 2017 als Stichtag. Ab diesem Tag würden BIP-148-Nodes jeden Block ablehnen, der kein SegWit-Signal sendete. Die Kombination aus BIP 91 und dem politischen Druck der UASF löste die Blockade. So etwas hatten die meisten noch nie erlebt. Viele von uns diskutieren noch immer darüber, wessen Drohung letztendlich den Durchbruch brachte.
Für Taproot wählte die Community einen eleganteren Ansatz: die Schnelltestphase. Dabei wurde eine Signalisierungsschwelle von 90 % innerhalb von 90 Tagen erreicht. Wurde diese Schwelle überschritten, wurde der Fork aktiviert. Andernfalls verfiel der Vorschlag ordnungsgemäß und konnte erneut versucht werden. Taproot überschritt die Schwelle problemlos und wurde am 14. November 2021 bei Block 709.632 aktiviert.
Soft-Gabel-Aktivierungsmodelle
| Verfahren | Wie es ausgelöst wird | Beispiel | Ergebnis |
|---|---|---|---|
| BIP 9 | 95% Miner-Signal über ein gleitendes Fenster von 2016 Blöcken | SegWit (anfangs festgefahren) | Funktionierte bei frühen Forks; führte zu einer Pattsituation bei SegWit. |
| BIP 91 | Senkung der Schwelle zur Lösung der Signalstörung | SegWit im August 2017 | SegWit-Deadlock behoben |
| BIP 148 (UASF) | Knoten setzen eine Frist; nicht signalisierende Blöcke werden abgelehnt | SegWit, 1. August 2017 | Politischer Druck; wurde sofort durch BIP 91 ersetzt. |
| BIP 8 / Schnellverfahren | 90% Signal innerhalb eines festgelegten Zeitfensters oder Ablauf | Taproot 2021 | Sauber aktiviert, ohne Probleme |
Bitcoin Soft Forks: Fallstudien zu SegWit und Taproot
SegWit, kurz für Segregated Witness, ist der am häufigsten zitierte Soft Fork in der Geschichte von Bitcoin. Dabei wurde eine Methode entwickelt, Transaktionssignaturen, die sogenannten „Zeugendaten“, aus dem Hauptteil der Transaktion auszulagern und separat zu speichern. Ältere Nodes interpretierten die neuen Ausgaben als für jeden nutzbare Skripte und akzeptierten Blöcke, die diese enthielten. Neuere Nodes setzten die Witness-Regeln korrekt um. Der Clou: Eine sanfte Änderung der zugrundeliegenden Transaktionsstruktur führte zu einer effektiven Kapazitätssteigerung. Die harte Blockgrößenbegrenzung von 1 MB wurde durch eine Begrenzung auf 4 Millionen Gewichtseinheiten ersetzt. In der Praxis enthält ein typischer Block nun etwa 1,8 MB Daten. Das theoretische Maximum liegt bei etwa 2,4 MB.
SegWit wurde am 24. August 2017 um 01:57:37 UTC bei Block 481.824 aktiviert. Die acht Monate davor sind mittlerweile fester Bestandteil der Bitcoin-Governance-Geschichte. Die Unterstützung für Miner war fast das gesamte Jahr 2017 blockiert. Die endgültige Freigabe erfolgte durch BIP 91, die UASF-Drohung und das sogenannte SegWit2x-Abkommen. Ich komme immer wieder auf diesen Zeitraum zurück, weil er als Fallbeispiel für jede nachfolgende Aktivierung dient.
Taproot ist der zweithäufigst erwähnte Soft Fork und wahrscheinlich die reibungsloseste Bitcoin-Aktivierung seit SegWit. Er wurde vier Jahre nach SegWit, am 14. November 2021, bei Block 709.632 aktiviert. Das Überschreiten der 90-Prozent-Schwelle im Rahmen des Speedy Trial verlief unspektakulär. Taproot selbst führte drei Neuerungen ein: Schnorr-Signaturen, MAST-Bäume und einen einheitlichen Ausgabetyp für Single-Signature-, Multi-Signature- und Script-Path-Ausgaben. Diese Änderungen legten auch den Grundstein dafür, dass Lösungen wie das Lightning Network im Laufe der Zeit effizienter werden konnten.
Die weitere Entwicklung von Taproot ist bemerkenswert. Die Akzeptanz stieg bis 2023 stetig an und erreichte Anfang 2024 mit rund 42 Prozent aller Bitcoin-Transaktionen ihren Höhepunkt, beflügelt vom Boom der Ordinals-Inschriften. Mitte 2025 fiel sie wieder auf etwa 20 Prozent. Die Inschriften ließen nach. Es entbrannte eine Debatte darüber, ob Taproots Signaturverfahren zukünftigen Quantencomputerangriffen ausgesetzt sei. All das konnte die Aktivierung jedoch nicht aufhalten. Die Nutzungskurve verdeutlicht aber, dass ein erfolgreicher Soft Fork auf Protokollebene nicht automatisch zu einer höheren Akzeptanz bei Wallets oder Nutzern führt.
Bitcoins Soft-Fork-Linie
| BIP / Name | Aktiviert | Block | Schwelle |
|---|---|---|---|
| BIP 16 (P2SH) | 1. April 2012 | 173.805 | 55% |
| BIP 34 | 24. März 2013 | 227.835 | 95 % |
| BIP 66 | 4. Juli 2015 | 363.731 | 95 % |
| BIP 65 (CLTV) | 14. Dezember 2015 | 388.380 | 95 % |
| BIP 141 (SegWit) | 24. August 2017 | 481.824 | 95 % (nach BIP 91) |
| BIPs 340/341/342 (Taproot) | 14. November 2021 | 709.632 | 90 % beschleunigtes Verfahren |
Die Soft-Fork-Debatte 2025-2026: OP_CTV und OP_CAT
Die erste ernsthafte Diskussion um eine Bitcoin-Soft-Fork seit Taproot findet gerade statt. Im Mittelpunkt steht die Frage, wie ausdrucksstark das Bitcoin-Skript sein sollte. Zwei Vorschläge dominieren die Debatte. Bislang hat sich keiner von beiden durchgesetzt.
OP_CHECKTEMPLATEVERIFY, formalisiert als BIP 119, fügt einen Skript-Opcode hinzu, der es ermöglicht, eine Transaktion auf ein bestimmtes zukünftiges Ausgabemuster festzulegen. OP_CAT, formalisiert als BIP 347, nachdem es im April 2024 endlich eine BIP-Nummer erhalten hatte, reaktiviert die Verkettung von Skriptelementen. Diese Funktion hatte Satoshi Nakamoto 2010 aufgrund von Bedenken hinsichtlich Denial-of-Service-Angriffen entfernt. Beide Opcodes sind Gateway-Primitive für sogenannte Covenants (Vereinbarungen). Covenants sind Skripte, die einschränken, wohin Coins als Nächstes gesendet werden können. Sie ermöglichen den Zugriff auf Vaults, die Stapelverarbeitung zur Staukontrolle und Verbesserungen des Netzwerkdurchsatzes auf Ebenen oberhalb der Bitcoin-Blockchain.
Mit 2026 werden die Aktivierungsparameter von OP_CTV erstmals seit 2022 offiziell diskutiert. Der vorgeschlagene Schwellenwert liegt bei 90 Prozent Miner-Signalisierung. OP_CAT wird auf Signet, dem Entwickler-Testnetzwerk, getestet. Für beide Varianten besteht noch kein Konsens in der Community. Der damit verbundene Konflikt ist real. Mehr Ausdrucksstärke eröffnet neue Anwendungsfälle, vergrößert aber auch die Angriffsfläche von Bitcoin. Jeder neue Opcode ist permanent. Ich bin nicht überzeugt, dass eine der beiden Varianten in 2026 angenommen wird, aber die Debatte ist das bisher deutlichste Zeichen dafür, dass die Bitcoin-Governance weiterhin Soft Forks in Betracht zieht.
Was eine Soft Fork für Wallets und Inhaber bedeutet
Für jeden Bitcoin-Besitzer stellt sich die Frage, ob ein Soft Fork Handlungsbedarf erfordert. Die ehrliche Antwort lautet fast immer: Nein. Es ist nichts zu tun, nichts zu beanspruchen und nichts zu migrieren. Ein Soft Fork erzeugt keinen neuen digitalen Vermögenswert. Bestehende Wallets senden und empfangen weiterhin Coins nach den alten Regeln, ohne dass ein Eingreifen des Nutzers erforderlich ist.
Eine Ausnahme bildet die Einführung eines neuen Adressformats durch einen Soft Fork. SegWit führte das Adresspräfix bc1 ein. Wallets mussten das neue Format unterstützen, damit Nutzer Coins an und von SegWit-Adressen senden und empfangen konnten und die Gebührenersparnis der neuen Transaktionsstruktur nutzen konnten. Nutzer älterer Wallets konnten weiterhin problemlos Coins an die alten Adressen senden und empfangen. Das Upgrade auf die neue Version war optional. Taproot ging mit bc1p-Adressen genauso vor. Genau diese optionale Vorgehensweise ist der entscheidende Punkt. Ein Soft Fork ist weniger disruptiv als ein Hard Fork, da die Einführung schrittweise und freiwillig erfolgt.
Für Node-Betreiber ändert sich die Situation etwas. Wer nach einem Soft Fork einen Node der alten Version betreibt, ist nicht mehr selbst für die Durchsetzung der neuen Regeln verantwortlich. Er vertraut darauf, dass aktualisierte Miner und andere Nodes dies übernehmen. Nodes, die nicht auf die neue Version aktualisieren, können zwar weiterhin Blöcke nach dem alten Softwareprotokoll validieren, jedoch nicht die durch den Fork eingeführten neuen Einschränkungen. Die meisten Betreiber führen ohnehin zeitnah ein Upgrade durch. Das ist einer der Gründe, warum das Full-Node-Ökosystem von Bitcoin so wichtig ist.

Warum Soft Forks Hard Forks hinsichtlich der Netzwerkgesundheit überlegen sind
Das Argument für Soft Forks als Standard-Upgrade-Pfad basiert auf der Netzwerkstabilität, und die Berechnungen sind hier tatsächlich ziemlich ernüchternd. Bitcoin betreibt laut einem Bitnodes-Snapshot vom 27. April 2026 weltweit etwa 22.992 erreichbare Full Nodes. Hinzu kommt eine unbekannte, größere Anzahl von Nodes hinter Firewalls. Ein Hard Fork, bei dem 10 Prozent dieser Nodes aufgrund von Trägheit oder Uneinigkeit verloren gehen, ist per Definition eine Kettenspaltung. Zwei Kryptowährungen. Zwei Ledger. Zwei Märkte. Zwei Gemeinschaften.
Ein Soft Fork, bei dem 10 Prozent der Miner aufgrund fehlender Signale ausscheiden, führt lediglich zu einer geringfügig langsameren Bestätigung, während die 90-prozentige Mehrheit die neuen Regeln durchsetzt. Die ökonomische Kette bleibt einheitlich. Diese Asymmetrie ist der Grund für Bitcoins Vorliebe für Abwärtskompatibilität. Ein erfolgreicher Soft Fork belohnt Koordination, ohne langsame Miner zu bestrafen. Ein fehlgeschlagener Soft Fork wird einfach nicht aktiviert und kann im nächsten Zyklus erneut versucht werden. Ein fehlgeschlagener Hard Fork hingegen erzeugt eine neue Blockchain mit neuem Branding und anhaltendem politischen Einfluss, den niemand gewollt hat.
Deshalb handelte es sich bei jedem größeren Upgrade der Bitcoin-Blockchain seit 2012 – mit Ausnahme der umstrittenen Abspaltung vom August 2017, aus der Bitcoin Cash hervorging – um einen Soft Fork. Die Mehrheit der Mining-Ressourcen hat sich stets für abwärtskompatible Änderungen anstelle von Divergenzen entschieden. Dieses Muster ist kein Zufall.
Risiken und Ausfallarten von Soft-Gabeln
Soft Forks sind sicherer als Hard Forks. Sie sind jedoch nicht risikofrei. BIP 66 im Juli 2015 führte zu einer unbeabsichtigten Aufspaltung der Blockchain in sechs Blöcke, da einige Miner zwar ihre Unterstützung für die neuen Regeln signalisierten, diese aber nicht validierten. Ein klassischer Fehlerfall: Aktualisierte Nodes lehnen die Blöcke ab, die nicht aktualisierte Miner weiterhin produzieren. Kurzzeitig existieren konkurrierende Blockchains. Die Netzwerksicherheit leidet für einige Stunden. Die Aufspaltung löste sich von selbst auf, sobald die Mehrheit die neuen Regeln implementiert hatte. Doch für mehrere Stunden liefen auf Bitcoin zwei konkurrierende Blockchains gleichzeitig. Auch das zweijährige Aktivierungsfenster von SegWit verursachte politischen Schaden, der sich nicht vollständig erholte, einschließlich der späteren Entstehung von Bitcoin Cash. Und ein UASF ohne klare Miner-Mehrheit birgt das reale Risiko einer dauerhaften Aufspaltung. Rückwärtskompatibilität ist eine starke Einschränkung, kein Freifahrtschein.