Skip to content
Wszystkie przewodniki po opcjach
Wyjścia transakcji Bitcoin11 min read

OP_RETURN w Bitcoinie: data carrier, nulldata i wyjścia niemożliwe do wydania

Dowiedz się, jak OP_RETURN zapisuje publiczne dane, dlaczego wyjścia nie można wydać, czym polityka relay Bitcoin Core 31.1 różni się od konsensusu oraz jak odróżnić ją od inskrypcji w witness.

W tym przewodnikuOP_RETURN umieszcza dane w skrypcie blokującym

Krótkie podsumowanie

OP_RETURN pozwala dołączyć publiczne dane do skryptu wyjścia transakcji Bitcoin. Bitcoin Core uznaje wyjścia, których skrypt zaczyna się od OP_RETURN, za możliwe do udowodnienia niemożliwe do wydania i pomija je w zbiorze UTXO. Obecne limity relay są lokalną polityką węzłów, a nie wspólnym dla sieci limitem payloadu w konsensusie.

OP_RETURN umieszcza dane w skrypcie blokującym

Wyjście transakcji Bitcoin zawiera wartość i skrypt blokujący scriptPubKey. Wyjście OP_RETURN, klasyfikowane też jako nulldata, zaczyna się od opcode OP_RETURN i może potem wstawiać ciąg bajtów. Po umieszczeniu transakcji w bloku bajty są publicznie zapisane jako część wyjścia. Ten schemat nie tworzy osobnej warstwy danych, salda tokena ani prywatnej wiadomości.

Dlaczego wyjścia nie można wydać ponownie

OP_RETURN to opcode, którego wykonanie kończy się niepowodzeniem. Próba wydania wyjścia, którego skrypt zaczyna się od tego opcode, nie może spełnić warunku skryptu. Bitcoin Core klasyfikuje je więc jako niemożliwe do wydania i może od razu pominąć w zbiorze UTXO, zamiast przechowywać monetę, której nigdy nie da się użyć. Szczegóły są w script.h Bitcoin Core 31.1. Bitcoin Core 31.1 script implementation.

Skrypt jest większy niż payload

Limit data carrier nie musi obejmować wyłącznie bajtów aplikacji. Surowy skrypt wyjścia zawiera opcode OP_RETURN, instrukcję wstawienia danych wraz z kodowaniem długości i payload. Payload 80 bajtów może wymagać skryptu o rozmiarze 83 bajtów: jeden bajt opcode, dwa bajty nagłówka OP_PUSHDATA1 i 80 bajtów danych. Dawne wskazówki o „80 bajtach” często dotyczą payloadu; nowsze opcje mogą mierzyć pełny skrypt.

Domyślna polityka data carrier w Bitcoin Core 31.1

Bitcoin Core 31.1 domyślnie włącza -datacarrier. Domyślna wartość -datacarriersize to 100 000 bajtów, mierzonych jako łączny rozmiar surowych scriptPubKey wszystkich wyjść data carrier w jednej transakcji. Wiele wyjść NULL_DATA korzysta z tego samego limitu, który obejmuje opcode i kodowanie push. Core 30.0 zastąpił dawny limit 83 bajtów skryptu limitem 100 000 bajtów łącznie i dopuścił wiele wyjść; Core 31.1 zachowuje tę politykę. Zobacz opcje Core 31.1, implementację polityki i informacje o wydaniu 30.0.

Ilustracja bez tekstu: strumień danych wyjścia kończy się na barierze, a dane witness wejścia docierają do łańcucha
Porównanie danych OP_RETURN w wyjściu z danymi witness w wejściu; zajmują inne pola transakcji i podlegają innym regułom

Polityka relay i konsensus odpowiadają na różne pytania

Każdy węzeł może wyłączyć relay data carrier albo obniżyć lokalny limit. Inne węzły i wersje oprogramowania mogą mieć inne ustawienia. Odrzucenie transakcji przez mempool węzła może oznaczać tylko, że jego polityka lokalna nie chce jej przekazywać, a nie że konsensus jej zakazuje. Bitcoin Core stosuje limit danych w kontroli standardowości, a reguły konsensusu sprawdza oddzielnie podczas walidacji bloku. Core consensus transaction checks. See Bitcoin Core 31.1 mempool standardness implementation.

Wartość wyjścia przepada, a opłata jest liczona oddzielnie

Do wyjścia OP_RETURN można przypisać wartość, ale nie da się jej odzyskać i pozostaje niemożliwa do wydania. Portfele zwykle przypisują mu zero. 1 000 sat przypisane do wyjścia nie staje się automatycznie opłatą dla górnika. Opłata nadal wynosi sumę wejść pomniejszoną o sumę wszystkich wyjść. Bajty skryptu zwiększają wagę transakcji i mogą podnieść opłatę przy tej samej stawce sat/vB. Zobacz poradnik opłat transakcyjnych Bitcoin.

Wiele wyjść danych nie zwielokrotnia limitu

Bitcoin Core 31.1 dopuszcza wiele standardowych wyjść NULL_DATA, ale sumuje ich skrypty w ramach tego samego limitu transakcji. Podział payloadu nie zwiększa dostępnego miejsca, a każde wyjście dodaje dane i wagę bloku. Relay zależy też od wagi transakcji, opłat i innych zasad standardowości. Akceptacja przez jeden portfel lub eksplorator nie gwarantuje propagacji w całej sieci.

OP_RETURN różni się od inskrypcji w witness Taproot

Dane OP_RETURN znajdują się w scriptPubKey wyjścia już przy tworzeniu transakcji. Dane witness SegWit są serializowane osobno dla każdego wejścia; BIP 141 opisuje je jako dane stosu danego wejścia. Wydanie Taproot ścieżką skryptu może ujawnić skrypt i blok kontrolny w witness wejścia. Oprogramowanie Ordinals może rozpoznać tam format inskrypcji według konwencji aplikacyjnej, lecz to inny mechanizm niż wyjście nulldata. Zobacz BIP 141, BIP 341 i poradnik [Bitcoin Ordinals i inskrypcje](/learn/bitcoin-ordinals-inscriptions-satoshi-numbering-witness-data-explained).

Przed użyciem sprawdź politykę, wartość i prywatność

Sprawdź wersję Bitcoin Core i ustawienia lokalne, na których polegasz. Osobno oblicz rozmiar pełnego surowego skryptu wyjścia, całkowitą wagę transakcji, wartość wyjścia niemożliwego do wydania i opłatę dla górnika. Konsensus nie nadaje znaczenia dowolnym bajtom payloadu; upewnij się też, że protokół lub odbiorca rozpoznaje format. Dane w łańcuchu są publiczne. O wyjściach i reszcie przeczytasz w poradniku Bitcoin UTXO i coin control.

Częste pytania

Q1Czy konsensus Bitcoina ogranicza OP_RETURN do 80 bajtów danych?

Nie. 80 bajtów to wartość payloadu z przykładu dawnej polityki standardowości, a nie uniwersalny limit konsensusu. Bitcoin Core 31.1 domyślnie stosuje łączny limit 100 000 bajtów surowych skryptów danych; węzły mogą zmieniać politykę.

Q2Czy większy OP_RETURN podnosi opłatę transakcji?

Może. Bajty skryptu zwiększają wagę transakcji, więc przy tej samej stawce sat/vB opłata może wzrosnąć. Sat przypisane do wyjścia niemożliwego do wydania przepadają osobno i nie są opłatą dla górnika.

Q3Czy OP_RETURN to to samo co inskrypcja Ordinals?

Nie. OP_RETURN znajduje się w skrypcie wyjścia i uniemożliwia jego wydanie. Typowa inskrypcja Taproot umieszcza treść w danych ścieżki skryptu witness wejścia, które Ordinals interpretuje według własnych konwencji.

Źródła i dalsza lektura

Zgłoś problem

Przygotujemy e-mail z linkiem do tego artykułu. Mark otrzyma zgłoszenie dopiero po jego wysłaniu

Szybki test

Przeczytano? Sprawdź się w 3 pytaniach

Pytanie 1 / 3

Pytanie 01

Co mierzy domyślny -datacarriersize w Bitcoin Core 31.1?

Wybierz odpowiedź, aby zobaczyć wyjaśnienie

Słownik opcji