Bitcoin OP_RETURN erklärt: Data Carrier, nulldata und nicht ausgebbare Ausgaben
Erfahre, wie OP_RETURN öffentliche Daten in Bitcoin-Ausgaben schreibt, warum sie nicht ausgegeben werden können, wie sich Bitcoin-Core-31.1-Relayrichtlinien vom Konsens unterscheiden und was sie von Witness-Inscriptions trennt.
In diesem LeitfadenOP_RETURN speichert Daten im Sperrskript
Kurze Zusammenfassung
OP_RETURN hängt öffentliche Daten an das Ausgabeskript einer Bitcoin-Transaktion an. Bitcoin Core behandelt Ausgaben, deren Skript mit OP_RETURN beginnt, als nachweislich nicht ausgebbar und nimmt sie nicht in den UTXO-Satz auf. Aktuelle Relaygrenzen sind lokale Node-Richtlinien, keine netzwerkweite Konsensgrenze für Payloads.
OP_RETURN speichert Daten im Sperrskript
Eine Bitcoin-Ausgabe enthält einen Betrag und ein Sperrskript namens scriptPubKey. Eine OP_RETURN-Ausgabe, auch nulldata genannt, beginnt mit dem Opcode OP_RETURN und kann danach Bytes pushen. Wird die Transaktion in einen Block aufgenommen, sind diese Bytes öffentlich Teil der Ausgabe. Das Muster ist keine separate Datenebene, kein Tokenbestand und keine private Nachricht.
Warum die Ausgabe nicht noch einmal ausgegeben werden kann
OP_RETURN ist ein Opcode, bei dessen Ausführung das Skript fehlschlägt. Eine Ausgabe mit einem Skript, das damit beginnt, kann daher nicht gültig ausgegeben werden. Bitcoin Core stuft sie als nicht ausgebbar ein und kann sie sofort aus dem UTXO-Satz weglassen, statt eine dauerhaft unbrauchbare Coin zu speichern. Die Prüfung steht in Bitcoin Core 31.1 script.h. Bitcoin Core 31.1 script implementation.
Das Skript ist größer als die Payload
Eine Größenbegrenzung für Data Carrier zählt nicht zwingend nur die Anwendungsdaten. Das rohe Ausgabeskript enthält den OP_RETURN-Opcode, die Push-Anweisung samt Längencodierung und die Payload. 80 Payload-Bytes benötigen beispielsweise 83 Skriptbytes: ein Byte für den Opcode, zwei Bytes für den OP_PUSHDATA1-Kopf und 80 Bytes Inhalt. Alte Hinweise auf „80 Bytes“ meinen oft den Inhalt; neuere Optionen messen das ganze Skript.
Bitcoin Core 31.1 erlaubt Data Carrier standardmäßig
Bitcoin Core 31.1 aktiviert -datacarrier standardmäßig. -datacarriersize steht standardmäßig auf 100.000 Bytes und summiert die rohen scriptPubKey-Größen aller Data-Carrier-Ausgaben einer Transaktion. Mehrere NULL_DATA-Ausgaben teilen sich denselben Spielraum; Opcode und Push-Codierung zählen mit. Core 30.0 ersetzte die frühere Grenze von 83 Skriptbytes durch 100.000 aggregierte Bytes und erlaubte mehrere Ausgaben; Core 31.1 behält das bei. Siehe Core-31.1-Optionen, die Policy-Implementierung und die Release Notes zu 30.0.
Relay-Policy und Konsens beantworten verschiedene Fragen
Jeder Node kann Data-Carrier-Relay abschalten oder seine lokale Größenbegrenzung senken. Andere Nodes und Softwareversionen können abweichende Einstellungen verwenden. Lehnt ein Node eine Transaktion im Mempool ab, bedeutet das möglicherweise nur, dass seine lokale Policy sie nicht weiterleitet; ein Konsensverstoß folgt daraus nicht automatisch. Bitcoin Core prüft den Data-Carrier-Spielraum bei der Standardness-Prüfung und kontrolliert die Konsensregeln separat bei der Blockvalidierung. Core consensus transaction checks. See Bitcoin Core 31.1 mempool standardness implementation.
Der Ausgabewert geht verloren; die Gebühr wird separat berechnet
Eine OP_RETURN-Ausgabe kann einen Betrag enthalten, aber niemand kann ihn zurückholen. Wallets verwenden für Datenausgaben meist null. Zugewiesene 1.000 Sats werden nicht automatisch zur Miner-Gebühr, sondern bleiben unausgebbar. Die Gebühr ist weiterhin die Summe der Inputs abzüglich aller Outputs. Skriptbytes verbrauchen Transaktionsgewicht und können bei gleichem Satz in sat/vB die Gebühr erhöhen. Mehr dazu im Bitcoin-Transaktionsgebührenleitfaden.
Mehrere Datenausgaben vervielfachen das Limit nicht
Bitcoin Core 31.1 lässt mehrere standardmäßige NULL_DATA-Ausgaben zu, summiert deren Skriptgrößen aber auf dasselbe Transaktionslimit. Eine Aufteilung der Payload erhöht den Spielraum nicht; zusätzliche Ausgaben vergrößern außerdem Transaktion und Blockgewicht. Ob ein Node relayt, hängt auch von Transaktionsgewicht, Gebühren und weiteren Standardnessregeln ab. Die Annahme durch ein Wallet oder einen Explorer garantiert keine Verbreitung im gesamten Netzwerk.
OP_RETURN unterscheidet sich von einer Taproot-Witness-Inscription
OP_RETURN-Daten stehen beim Erstellen in der scriptPubKey einer Ausgabe. SegWit-Witness-Daten werden für jeden Input getrennt serialisiert; BIP 141 beschreibt die Witness-Felder als Stack-Daten je Input. Ein Taproot-Script-Path-Spend kann Skript und Control Block im Input-Witness offenlegen. Ordinals-Software kann darin ein bestimmtes Envelope-Format nach einer Anwendungskonvention als Inscription deuten; das ist nicht dasselbe wie eine nulldata-Ausgabe. Siehe BIP 141, BIP 341 und den [Bitcoin-Ordinals-Leitfaden](/learn/bitcoin-ordinals-inscriptions-satoshi-numbering-witness-data-explained).
Vor dem Einsatz Policy, Wert und Öffentlichkeit prüfen
Prüfe die Bitcoin-Core-Version und lokalen Optionen, auf die du dich verlässt. Berechne getrennt die Größe des vollständigen Ausgabeskripts, das Gesamtgewicht der Transaktion, den Betrag der nicht ausgebbaren Ausgabe und die Miner-Gebühr. Der Konsens verleiht beliebigen Payload-Bytes keine Bedeutung; bestätige zusätzlich, dass das Protokoll oder der Empfänger das Format erkennt. Daten auf der Blockchain sind öffentlich. Für Ausgaben und Wechselgeld siehe den Bitcoin-UTXO- und Coin-Control-Leitfaden.
Häufige Fragen
Q1Begrenzt der Bitcoin-Konsens OP_RETURN auf 80 Datenbytes?
Nein. 80 Bytes ist ein Payload-Wert aus einem älteren Standardness-Policy-Beispiel, keine universelle Konsensgrenze. Bitcoin Core 31.1 setzt standardmäßig 100.000 aggregierte Bytes für rohe Datenskripte an; Nodes können ihre Policy ändern.
Q2Erhöht ein größeres OP_RETURN die Transaktionsgebühr?
Das ist möglich. Skriptbytes erhöhen das Transaktionsgewicht und damit bei gleichem sat/vB möglicherweise die Gebühr. Zugewiesene Sats der nicht ausgebbaren Ausgabe gehen zusätzlich verloren und sind nicht die Miner-Gebühr.
Q3Ist OP_RETURN dasselbe wie eine Ordinals-Inscription?
Nein. OP_RETURN steht in einem Ausgabeskript und macht diese Ausgabe nicht ausgebbar. Eine typische Taproot-Inscription legt Inhalte in Script-Path-Daten des Input-Witness offen, die Ordinals nach eigenen Konventionen interpretiert.
Quellen und weiterführende Lektüre
Problem melden
Wir bereiten eine E-Mail mit dem Link zu diesem Artikel vor. Mark erhält den Hinweis erst nach dem Senden
Schnelltest
Fertig gelesen? Prüfe dich mit 3 Fragen
Frage 01
Was misst Bitcoin Core 31.1 mit dem Standardwert von -datacarriersize?
Wähle eine Antwort, um die Erklärung zu sehen
Optionsglossar
Eine Lage, in der der Ausübungspreis einer Option nahe am Marktpreis ihres Basiswerts liegt. Der innere Wert kann gering oder null sein, während wegen verbleibender Zeit und Unsicherheit noch eine Prämie bestehen kann.
Detaillierten Leitfaden lesenKaufoptionEin Kontrakt, der dem Inhaber das Recht, aber nicht die Pflicht gibt, den Basiswert zum Ausübungspreis nach den Vertragsbedingungen zu kaufen. Der Verkäufer trägt bei Ausübung und Zuteilung die entsprechende Pflicht.
Detaillierten Leitfaden lesenVerkaufsoptionEin Kontrakt, der dem Inhaber das Recht, aber nicht die Pflicht gibt, den Basiswert zum Ausübungspreis nach den Vertragsbedingungen zu verkaufen.
Detaillierten Leitfaden lesen