OP_RETURN to instrukcja Bitcoin Script o kodzie 0x6a. Na początku skryptu wyjścia sprawia, że wyjścia w sposób dowodliwy nie da się wydać: żaden podpis go nie odblokuje. Za instrukcją można umieścić dane. To nie adres płatniczy ani pieniądze wysłane odbiorcy, lecz sposób zapisania danych w transakcji.
Jana chce dołączyć informację, a nie wysłać komuś kolejną kwotę. Dlatego zaczyna wyjście od OP_RETURN. Przy próbie wydania wykonanie tej instrukcji zakończyłoby sprawdzanie skryptu niepowodzeniem, niezależnie od podpisu. Techniczna nazwa skryptu wyjścia to scriptPubKey. Liczy się położenie i wykonanie: ten sam bajt wewnątrz wstawionych danych nie jest uruchamianym poleceniem. OP_RETURN w niewykonywanej gałęzi także nie jest tym samym co OP_RETURN na początku. Samo znalezienie nazwy lub bajtu gdzieś w transakcji więc nie wystarcza. [1] [5]
Bitcoin Core zalicza typową postać do NULL_DATA. Nazwa nie oznacza pustej zawartości. Funkcja Solver wymaga OP_RETURN na początku i dalszej części przechodzącej IsPushOnly, czyli zawierającej wyłącznie instrukcje wstawiania danych. Może to być tekst, hash — krótki obliczony odcisk — lub zapis dla innego protokołu. Klasyfikacja nie potwierdza znaczenia wiadomości ani sama nie gwarantuje przyjęcia do kolejki węzła. Zapis nie nadaje też automatycznie własności pliku, autorstwa czy skutków prawnych; takie twierdzenia potrzebują dodatkowych reguł i dowodów. [3]
Węzły utrzymują zbiór UTXO, czyli niewydane wyjścia, których wciąż można użyć. Gdy wyjście zaczyna się od OP_RETURN, wiadomo z góry, że nikt go nie wyda. IsUnspendable je rozpoznaje, a AddCoin nie dodaje do pamięci podręcznej UTXO. Oszczędza to bieżącą ewidencję, nie miejsce w całej historii: potwierdzona transakcja pozostaje w bloku, a dane są przesyłane i zachowywane w jego historycznych kopiach. Pominięcie w UTXO nie usuwa danych. Jeżeli ktoś przypisze temu wyjściu kwotę, nie jest ona nagrodą dla górnika. Nie da się jej wydać ani odzyskać późniejszym podpisem. [2] [6] [1]
Konsensus określa, jakie bloki węzeł uznaje za ważne. Lokalna polityka wybiera natomiast, co trafia do mempoolu, kolejki niepotwierdzonych transakcji, oraz co jest przekazywane dalej lub proponowane do wydobycia. Tak węzeł chroni zasoby. Operatorzy mogą wybierać różne ustawienia: odmowa przekazania transakcji nie dowodzi naruszenia konsensusu przez blok, który ją zawiera. Przyjęcie do mempoolu też nie obiecuje potwierdzenia. Opcja datacarriersize ustala lokalny budżet danych; sama nie zmienia ważności bloków ani nie usuwa potwierdzonych treści. [8]
Często cytowane wcześniejsze ustawienie domyślne dopuszczało 1 wyjście danych ze skryptem do 83 bajtów, zwykle 80 bajtów treści plus instrukcje. Bitcoin Core 30.0 zwiększył domyślne datacarriersize do 100000 i dopuścił wiele wyjść danych. Kod odejmuje długość całego scriptPubKey każdego takiego wyjścia od wspólnego budżetu. Nie liczy tylko treści wiadomości ani zewnętrznego pola określającego długość skryptu. Pozostałe limity transakcji nadal obowiązują. Ustawienie 83 przywraca więc budżet, lecz nie starą zasadę jednego wyjścia. To opis konkretnej zmiany wersji, nie niezmienne prawo całej sieci. [7] [4] [8]
Jana może umieścić hash dokumentu w OP_RETURN zamiast samego pliku. Kiedy później pokaże oryginał, można ponownie obliczyć odcisk tą samą metodą i porównać z zapisem. Musi jednak zachować dokładne bajty pliku i metodę; odcisk nie zastąpi dokumentu. Zgodność nie dowodzi prawdziwości treści, autorstwa Jany ani dokładnej chwili utworzenia pliku. Publiczny zapis może też łączyć tożsamości, a dane poddane hashowaniu nie są automatycznie prywatne. Koszty zależą od całej transakcji i popytu na miejsce w blokach, nie tylko od długości wiadomości. [1] [8]
Istnieje ważny, ściśle określony wyjątek od zwykłych wiadomości aplikacji. BIP 141 używa OP_RETURN w coinbase, początkowej transakcji bloku, do witness commitment: kryptograficznego powiązania z danymi potrzebnymi do weryfikacji transakcji. Odpowiedni scriptPubKey ma przynajmniej 38 bajtów i zaczyna się od 0x6a24aa21a9ed. Jeśli pasuje kilka wyjść, wybiera się najwyższy indeks, czyli ostatnie pasujące wyjście w kolejności. Gdy blok nie zawiera danych witness, umieszczenie witness commitment jest opcjonalne. Sieć sprawdza tu określoną strukturę; nie oznacza to weryfikowania prawdy dowolnego tekstu po OP_RETURN. [9]
Najpierw ustal, jakiego klienta, wersji i konfiguracji dotyczy limit. Potem trzeba zdekodować rzeczywistą transakcję i odróżnić scriptPubKey od otaczających go pól zapisu bajtowego. Test mempool_datacarrier.py pokazuje przypadki graniczne implementacji; ten artykuł go nie uruchamia. BIP 110 proponował dodatkowe ograniczenia konsensusu, ale to zamknięty projekt, a nie reguła włączana przez datacarriersize. Opis starszej wersji nie gwarantuje identycznego działania wszystkich węzłów lub przyszłych wydań. Konkretne ustawienie i rzeczywiste potwierdzenie transakcji to różne informacje. [10] [8] [11]
Dlaczego wiadomość i skrypt mają inną długość
Jana chce dołączyć 32 bajty danych. Prosty skrypt zawiera OP_RETURN, instrukcję bezpośredniego wstawienia i dane: 1 + 1 + 32 = 34 bajty. To długość scriptPubKey. Pola kwoty i długości skryptu należą do innych części kodowania wyjścia i nie wchodzą do tej sumy. Budżet danych mierzy skrypt, a opłata jest oceniana dla całej transakcji. Przykład niczego nie rozsyła i nie dowodzi przyjęcia przez konkretny węzeł.
Pełniejszy obraz uzyskasz, czytając to hasło razem z Bitcoin Script, Transakcja, UTXO, Mempool, Transaction Fees, BIP 110. Do tego hasła prowadzą również odsyłacze z Runes, BRC-20.
01Czy bitcoiny przypisane do takiego wyjścia otrzyma górnik?+
Nie. Kwota w wyjściu, którego w sposób dowodliwy nie da się wydać, pozostaje niewydawalna. Opłata to różnica wartości wszystkich wejść i wszystkich wyjść. Przypisanie kwoty do OP_RETURN samo nie zamienia jej w opłatę.
02Czy większa dozwolona wiadomość zmienia reguły całego Bitcoina?+
Niekoniecznie. Węzeł może zmienić lokalną politykę i przekazywać więcej transakcji bez zmiany ważności bloków. Trzeba odróżnić ustawienia klienta, konsensus i rzeczywiste potwierdzenie danej transakcji.