OP_RETURN je instrukce jazyka Bitcoin Script, v kódu označená 0x6a. Pokud stojí na začátku výstupního skriptu, výstup je prokazatelně neutratitelný: žádný podpis ho neodemkne. Za instrukci lze připojit data. Nejde o platební adresu ani o peníze odeslané příjemci; je to způsob, jak v transakci vytvořit datový záznam.
Jana chce do transakce připojit údaj, nikoli někomu poslat další částku. Výstup proto začne instrukcí OP_RETURN. Při pokusu o utracení by její vykonání ukončilo kontrolu skriptu neúspěchem, ať by byl podpis jakýkoli. Skript výstupu se technicky jmenuje scriptPubKey. Důležité je, kde instrukce stojí a zda se vykoná: stejný bajt uvnitř vložených dat není příkazem ke spuštění. Ani OP_RETURN v neprovedené větvi skriptu není totéž jako OP_RETURN na jeho začátku. Nestačí tedy hledat název nebo bajt v libovolném místě transakce. [1] [5]
Bitcoin Core řadí obvyklou podobu takového výstupu do kategorie NULL_DATA. Název neznamená, že uvnitř nejsou data. Funkce Solver vyžaduje úvodní OP_RETURN a zbytek, který projde kontrolou IsPushOnly, tedy obsahuje jen instrukce vkládající data. Takto lze nést text, hash neboli krátký vypočtený otisk, či záznam pro další protokol. Klasifikace však nepotvrzuje význam zprávy a sama nezaručuje přijetí transakce do čekárny uzlu. Zápis také automaticky nepřiznává vlastnictví souboru, autorství ani právní účinek; taková tvrzení potřebují další pravidla a důkazy. [3]
Uzly si udržují UTXO, soubor dosud neutracených výstupů, které se ještě mohou použít. U výstupu začínajícího OP_RETURN vědí předem, že ho nikdo neutratí. Kontrola IsUnspendable jej rozpozná a funkce AddCoin ho do UTXO cache nepřidá. Tím se šetří tato pracovní evidence, nikoli prostor celé historie: potvrzená transakce zůstává v bloku a data se musí přenášet a uchovávat v jeho historických kopiích. Vynechání z UTXO data nemaže. A pokud někdo takovému výstupu přidělí částku, není to odměna těžaři. Částka je neutratitelná a pozdější podpis ji nezachrání. [2] [6] [1]
Konsensus určuje, jaké bloky uzel považuje za platné. Místní politika naproti tomu vybírá, co vpustí do mempoolu, čekárny nepotvrzených transakcí, a co bude přeposílat nebo nabízet k těžbě. Chrání tak své zdroje. Provozovatelé mohou mít různá nastavení: odmítnutí transakce k přeposlání ještě neznamená, že blok s ní porušuje konsensus. Ani přijetí do mempoolu neslibuje potvrzení. Volba datacarriersize nastavuje místní datový rozpočet; sama nepřepisuje pravidla platnosti bloků ani nemaže již potvrzený obsah. [8]
Často citovaný starší výchozí režim dovoloval 1 datový výstup se skriptem do 83 bajtů, obvykle 80 bajtů obsahu a zbytek instrukce. Bitcoin Core 30.0 zvýšil výchozí datacarriersize na 100000 a dovolil více datových výstupů. Kód odečítá délku celého scriptPubKey každého takového výstupu ze společného rozpočtu. Nepočítá jen obsah zprávy ani vnější pole, které zapisuje délku skriptu. Nadále platí další limity transakce. Nastavení 83 tedy vrátí velikost rozpočtu, ale ne dřívější pravidlo jediného výstupu. Tato čísla popisují konkrétní změnu verze, nikoli neměnný zákon celé sítě. [7] [4] [8]
Jana může místo dokumentu vložit do OP_RETURN jeho hash. Až později ukáže původní soubor, lze stejným postupem spočítat otisk znovu a porovnat jej se záznamem. Potřebuje ale zachovat přesné bajty souboru i použitý postup; samotný otisk dokument nenahradí. Shoda neříká, že obsah je pravdivý, že Jana je autorkou ani kdy přesně soubor vytvořila. Veřejný záznam navíc může propojovat identity a ani zahashovaný údaj není automaticky soukromý. Náklady závisí na celé transakci a poptávce po prostoru v blocích, ne jen na délce zprávy. [1] [8]
Existuje důležitá přesně vymezená výjimka k běžným aplikačním zprávám. BIP 141 používá OP_RETURN v coinbase, úvodní transakci bloku, pro witness commitment: kryptografické navázání na doprovodná data potřebná k ověření transakcí. Odpovídající scriptPubKey má nejméně 38 bajtů a začíná 0x6a24aa21a9ed. Když vzoru odpovídá více výstupů, vybere se nejvyšší index, tedy poslední z odpovídajících výstupů v pořadí. Pokud blok neobsahuje witness data, commitment je volitelný. Síť zde ověřuje konkrétně definovanou strukturu; neznamená to ověřování pravdivosti libovolného textu za OP_RETURN. [9]
U tvrzení o limitu se nejdřív ptejte na klienta, verzi a konfiguraci. Pak je potřeba rozkódovat skutečnou transakci a odlišit scriptPubKey od polí, která jej při ukládání do bajtů obalují. Test mempool_datacarrier.py ukazuje hraniční případy implementace; toto heslo jej samo nespouští. BIP 110 navrhoval další omezení na úrovni konsensu, ale jde o uzavřený návrh, nikoli pravidlo zapínané volbou datacarriersize. Také popis starší verze není příslibem stejného chování všech uzlů nebo budoucích verzí. Konkrétní nastavení a skutečné potvrzení transakce jsou dvě různé informace. [10] [8] [11]
Proč zpráva a skript nemají stejnou délku
Jana chce připojit 32 bajtů dat. Její jednoduchý skript obsahuje OP_RETURN, instrukci přímého vložení a samotná data: 1 + 1 + 32 = 34 bajtů. To je délka scriptPubKey. Pole s částkou a pole s délkou skriptu jsou další části zápisu výstupu a do tohoto součtu nepatří. Datový rozpočet se řídí skriptem, zatímco poplatek se posuzuje podle celé transakce. Tento příklad nic nevysílá a nedokládá přijetí konkrétním uzlem.
Pro nejúplnější obraz čtěte toto heslo společně s Bitcoin Script, Transakce, UTXO, Mempool, Transaction Fees, BIP 110. Opačným směrem na něj odkazují také Runes, BRC-20.
01Když takovému výstupu přiřadím bitcoiny, dostane je těžař?+
Ne. Částka přidělená prokazatelně neutratitelnému výstupu je neutratitelná. Poplatek tvoří rozdíl mezi součtem vstupů a všech výstupů. Přidělení částky výstupu OP_RETURN z ní samo o sobě poplatek neudělá.
02Znamená větší povolená zpráva změnu pravidel celého Bitcoinu?+
Ne nutně. Uzel může změnit místní politiku a přeposílat více transakcí, aniž by změnil pravidla platnosti bloků. Je potřeba rozlišit nastavení klienta, pravidla konsensu a to, zda se konkrétní transakce skutečně potvrdila.