OP_RETURN

Jana wants to attach information to a transaction rather than send someone another amount. She therefore starts an output with OP_RETURN. If anyone tried to spend it, executing that instruction would make script validation fail, whatever the signature. The technical name of the output script is scriptPubKey. Position and execution matter: the same byte inside embedded data is not an instruction being run. Nor is OP_RETURN in an unexecuted branch equivalent to OP_RETURN at the start. Finding the name or byte somewhere in a transaction is therefore insufficient. [1] [5]

Bitcoin Core classifies the usual form as NULL_DATA. The name does not mean the output contains no data. Its Solver function requires an initial OP_RETURN followed by code passing IsPushOnly, meaning only data-pushing instructions. This can carry text, a hash—a short computed fingerprint—or a record for another protocol. Classification does not validate the message’s meaning or by itself guarantee admission to a node’s waiting area. A record also does not automatically establish file ownership, authorship or legal effect; those claims require additional rules and evidence. [3]

Nodes maintain the UTXO set, the collection of unspent outputs still available to use. With an output beginning with OP_RETURN, they know nobody can spend it. IsUnspendable recognizes it and AddCoin does not add it to the UTXO cache. This saves working-state bookkeeping, not space throughout the history: the confirmed transaction remains in its block, and the data must be transferred and retained in historical copies. Exclusion from UTXO does not erase data. If someone assigns money to that output, it is not a miner’s reward. The amount is unspendable; a later signature cannot rescue it. [2] [6] [1]

Consensus determines which blocks a node considers valid. Local policy instead selects what enters its mempool, the waiting area for unconfirmed transactions, and what it relays or offers for mining. This protects its resources. Operators can choose different settings: refusing to relay a transaction does not mean a block containing it violates consensus. Mempool acceptance does not promise confirmation either. The datacarriersize option sets a local data budget; it does not itself rewrite block-validity rules or erase already confirmed content. [8]

The often-quoted older default allowed 1 data output with a script up to 83 bytes, typically 80 bytes of content plus instructions. Bitcoin Core 30.0 raised the default datacarriersize to 100000 and permitted multiple data outputs. The code subtracts each output’s entire scriptPubKey length from a shared budget. It does not count only the message payload, nor the outer field recording the script’s length. Other transaction limits still apply. Setting 83 therefore restores the budget size, but not the earlier single-output rule. These figures describe a particular version change, not an immutable law for the whole network. [7] [4] [8]

Jana can put the document’s hash in OP_RETURN instead of the document itself. When she later presents the original file, someone can recompute its fingerprint using the same method and compare it with the record. She must preserve the exact file bytes and the method; the fingerprint cannot replace the document. A match does not establish that its contents are true, that Jana wrote it or exactly when she created it. A public record can also link identities, and hashed information is not automatically private. Costs depend on the whole transaction and demand for block space, not just message length. [1] [8]

There is an important, precisely defined exception to ordinary application messages. BIP 141 uses OP_RETURN in the coinbase, the block’s initial transaction, for a witness commitment: a cryptographic link to the accompanying data needed to verify transactions. The matching scriptPubKey is at least 38 bytes and starts with 0x6a24aa21a9ed. If several outputs match, the highest index wins—the last matching output in their order. Without witness data in the block, the commitment is optional. The network checks this specific structure; that does not mean it verifies the truth of arbitrary text following OP_RETURN. [9]

First ask which client, version and configuration a claimed limit refers to. Then decode the actual transaction and distinguish its scriptPubKey from the fields surrounding it in the byte encoding. The mempool_datacarrier.py test illustrates implementation boundaries; this article does not run it. BIP 110 proposed additional consensus restrictions, but it is a closed proposal, not a rule switched on by datacarriersize. A description of an older release is no promise that all nodes or future versions behave identically. A particular setting and actual transaction confirmation are different pieces of information. [10] [8] [11]