BIP 110 mit dem Titel Reduced Data Temporary Softfork ist ein abgeschlossener Vorschlag, die Regeln für die Annahme von Blöcken vorübergehend zu verschärfen. Ein Knoten ist ein Rechner, der Verlauf und Zahlungen selbst prüft. Der Vorschlag sollte bestimmte Arten der Datenspeicherung erschweren und nach Ansicht seiner Befürworter Bitcoins Geldfunktion stärken. Damit wurde er nicht automatisch zur Regel für das gesamte Netzwerk.
Zwei Knotenbetreiber empfangen denselben Block. Einer akzeptiert ihn nach den bisherigen Regeln, der andere lehnt ihn wegen einer neuen Einschränkung ab. So tief griff BIP 110 ein: Es ging um die Gültigkeit von Blöcken, nicht nur darum, ob ein Knoten eine Transaktion weiterleitet oder in seinem Mempool behält, dem lokalen Warteraum für unbestätigte Zahlungen. Bei der Prüfung am 2026-10-23 trug die Spezifikation in Version 1.0.1 den Status Closed, also abgeschlossen. Eine BIP-Nummer oder veröffentlichte Software bestätigt keine Übernahme durch das Netzwerk. Das Vorschlagsregister bewahrt Dokument und Geschichte auf; es schaltet die Regeln der Knoten nicht aus der Ferne um. [1] [2]
Jeder neue Transaktionsausgang hat ein scriptPubKey: ein Skript mit Bedingungen für seine spätere Ausgabe. Erlaubt wären höchstens 34 Byte, beziehungsweise 83 Byte bei einem Beginn mit OP_RETURN. Diese Anweisung macht den Ausgang nachweislich unausgebbar. Gezählt wird das gesamte Skript. Eine weitere Grenze von 256 Byte galt für einzelne OP_PUSHDATA*-Nutzdaten und Argumente im Witness, den Begleitdaten zur Prüfung einer Ausgabe. Ausgenommen ist das Einfügen des redeemScript, des offengelegten Bedingungsskripts, in ein scriptSig nach BIP16. Witness scripts und Tapleaf scripts sind selbst keine solchen Argumente; ihre Anweisungen zum Einfügen von Daten bleiben aber begrenzt. Gemessen werden bestimmte Teile, nicht die Gesamtlänge einer Transaktion oder ihres gesamten Witness. [1]
Die Einschränkungen betrafen auch Taproot, eine Art, Ausgabebedingungen auszudrücken. Untersagt wäre das Ausgeben von Ausgängen mit undefinierten Witness- oder Tapleaf-Versionen, nicht aber das Erzeugen solcher Ausgänge. Verboten wären außerdem der Annex, ein Zusatzfeld, sowie control blocks über 257 Byte: zu lange Nachweise der Zugehörigkeit eines Skripts zur festgelegten Struktur. Tapscript dürfte OP_SUCCESS* auch in nicht ausgeführtem Code nicht enthalten; OP_IF und OP_NOTIF dürften unabhängig vom Ergebnis der Bedingung nicht ausgeführt werden. Zur technischen Einordnung gehören zu den definierten Formaten P2WPKH, P2WSH, P2TR mit Tapleaf-Version 0xc0 und P2A mit Programm 0x4e73, letzteres nur bei leerem Witness-Stack. Das sind genaue Formatbezeichnungen, keine Angaben, die normale Nutzer in ihre Wallet eingeben müssen. [1]
Ein UTXO ist ein noch nicht ausgegebener Transaktionsausgang: ein bestimmter Betrag mit Bedingungen für seine Verwendung. Eingänge, die vor der Aktivierung bestätigte UTXO ausgeben, sind von den neuen Regeln ausgenommen. Das ist aber kein Freibrief für neue Ausgänge derselben Transaktion. Auch eine vorab erstellte Signatur schützt keinen Ausgang, der erst während der aktiven Phase entsteht. Bei bestimmten vorsignierten Taproot-Konstruktionen räumt die Spezifikation eingefrorene oder verlorene Mittel ein, wenn vorgesehene Ausgabepfade ungültig werden und keine nutzbare Alternative bleibt. Das betrifft auch mögliche Folgen für Miniscript, ein Werkzeug zum Erstellen von Ausgabebedingungen, und BitVM, Konstruktionen zur Überprüfung von Berechnungen. Man kann daher nicht versprechen, ausschließlich nichtmonetäre Inhalte zu treffen. [1] [3]
Ein Miner kann Unterstützung im Block signalisieren: hier mit Bit 4 und einer Schwelle von 1109 aus 2016 Blöcken, ungefähr 55 Prozent. Der Vorschlag blieb jedoch nicht bei freiwilligen Signalen. Wurde die Schwelle nicht früher erreicht, verlangte er Signalisierung in den Höhen 961632–963647, anschließend LOCKED_IN ab 963648 und ACTIVE ab 965664, sofern die betreffende Kette diese Höhen erreicht. Die Höhe bezeichnet die Position eines Blocks in der Kette. LOCKED_IN steht für den festgelegten Übergang, ACTIVE für die tatsächliche Durchsetzung der Datenregeln. Schon während der Pflichtsignalisierung würde der Client Blöcke ohne Signal zurückweisen. Die Knoten könnten sich also vor Beginn der Datenlimits trennen. Diese sollten 52416 Blöcke ab tatsächlicher Aktivierung gelten, dann mit EXPIRED auslaufen; das ist kein exakt bemessenes Kalenderjahr. [1] [4]
Befürworter wollten geringere Betriebskosten für Knoten, weniger Belastung des UTXO-Satzes und weniger unerwünschte Inhalte sowie einen stärkeren Fokus auf Zahlungen. Das erklärt die Absicht, beweist aber keinen Erfolg. Kritiker verwiesen auf Folgen für nützliche Skripte, künftige Erweiterungen und das Risiko einer Netzspaltung. Daten lassen sich zudem auf kleinere Stücke verteilen: Peter Todd demonstrierte in der frühen Diskussion eine Transaktion mit dem gesamten damaligen Vorschlag in dieser Form. Auch die Spezifikation verspricht keine vollständige Verhinderung von Steganografie, also des Verbergens von Informationen in anderen Daten. Speicherung zu verteuern und sie vollständig zu verhindern sind unterschiedliche Ergebnisse. Ebenso belegt die Sorge vor rechtlicher Verantwortung für Inhalte für sich genommen keine konkrete Rechtspflicht. [1] [3]
Der Eintrag zu PR 2247 beschreibt eine Spaltung am 2026-08-08 bei Höhe 961632. Die Hauptkette enthielt einen Block ohne das geforderte Signal, während OCEAN eine signalisierende Alternative schürfte. Murch berichtete am 2026-08-09, die Minderheitskette habe nur 2 Blöcke gewonnen und sei zum Stillstand gekommen, während die Hauptkette um mehr als 100 Blöcke vorangekommen sei. Zu diesem Bericht gehören Datum und Urheber: Er ist weder eine für diesen Artikel unabhängig nachgeprüfte Kettenhistorie noch eine Aussage über den heutigen Zustand des Minderheitszweigs. Er verdeutlicht auch, weshalb eine signalbedingte Spaltung nicht mit ACTIVE und dem Beginn der eigentlichen Datenregeln gleichgesetzt werden darf. [5] [6]
Das Dokument durchlief Complete, also eine fertige Spezifikation, und endete bei Closed. PR 2245 zum Abschluss wurde am 2026-08-10 übernommen; das Änderungsprotokoll nennt 2026-08-09. Die Daten betreffen verschiedene Aufzeichnungen, keine weitere Aktivierung. Client-Version v0.4.1 dokumentiert EXPIRED und vbrequired, das Feld der Blockvorlage für das vorgeschriebene Signalbit. Dieser Client belegt keine Übernahme in Bitcoin Core. Es gibt außerdem Testvektoren, Beispieltransaktionen mit erwarteten Ergebnissen, und Funktionstests. Der Artikel führt sie nicht aus und prüft nicht den gegenwärtigen Minderheitszweig. Er erklärt den Vorschlag und seinen dokumentierten Verlauf, statt ein historisches Dokument als heutige gemeinsame Netzwerkregeln darzustellen. [7] [1] [4]
Ein zusätzliches Byte kann den Unterschied machen
Stellen wir uns die Prüfung eines neuen Ausgangs unter den hypothetisch aktiven Regeln vor. Ein normales scriptPubKey mit 34 Byte besteht diesen Längentest, eines mit 35 Byte nicht. Ein mit OP_RETURN beginnendes Skript darf 83 Byte lang sein; 84 Byte überschreiten die Grenze. Gemessen wird immer das gesamte Ausgangsskript, nicht nur der eingefügte Text. Das Bestehen dieses Tests beweist noch keine gültige Gesamttransaktion, und das Ausgeben eines alten UTXO befreit einen neuen Ausgang nicht von der Prüfung.
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Soft Fork, Full Node, Taproot, Bitcoin Script, Transaction Fees, UTXO. Auf diesen Eintrag verweisen außerdem OP_RETURN.
01Darf nach dem Status Closed niemand mehr den Client betreiben?+
Closed bezeichnet den Dokumentstatus, kein Softwareverbot. Knoten folgen den Regeln ihrer Software. Wer andere Regeln wählt, kann jedoch auf einem anderen Kettenzweig landen; das Schließen eines Registereintrags beseitigt diesen Unterschied nicht.
02Galten die Datenlimits schon während der Pflichtsignalisierung?+
Nein. Pflichtsignalisierung geht LOCKED_IN und ACTIVE voraus. Ein Client kann einen Block ohne das erforderliche Signal bereits vor Beginn der Datenregeln ablehnen. Ein Kalenderdatum allein reicht deshalb nicht: Entscheidend sind Zustand und Höhe der jeweiligen Kette.