How Data Gets Stored In Bitcoin

The coinbase transaction is the first transaction in every block. It creates the block subsidy and fees, so only the miner who finds the block can choose its input field. Bitcoin has always allowed a small amount of arbitrary data there.

This is the cleanest historical place for a short message: it does not pretend to be a payment output, and it does not create an unspendable UTXO. The tradeoff is control. You need mining power, or cooperation from a miner or pool, and the space is tiny.

The famous genesis block headline is this kind of message. Later miners used the same space for pool names, political messages, prayers, and halving commemorations.

A normal pay-to-public-key-hash output contains a 20-byte public-key hash. A data uploader can put arbitrary 20-byte chunks in that field instead. To the network it looks like many ordinary-looking outputs, but the “addresses” are fake because nobody knows a private key whose public key hashes to those bytes.

Reconstruction means reading the raw 20-byte hash field from each data output, in output order, and concatenating those chunks. Change outputs have to be skipped; they usually stand out because their value differs from the repeated dust-value data outputs.

This method is simple and became common in early image upload services, including cryptograffiti-style raw images. Its major downside is permanent UTXO bloat: every fake address output is unspendable, so full nodes must carry it as an unspent output forever unless special handling removes it.

Instead of hiding data in a 20-byte hash, this method places data where a public key would normally appear. An uncompressed public key-sized field can carry much more data than a public-key hash.

The network sees a pay-to-public-key output. In reality the “key” bytes are payload. Unless the fake key accidentally corresponds to a usable key, the output is not spendable.

This catalog mostly sees P2FK as part of the AtomSea naming vocabulary rather than as a standalone common method. It is conceptually important because it shows the general pattern: any fixed byte field in a standard script can be abused as storage if users are willing to burn or lock coins.

Bare multisig outputs list several public keys and say how many signatures are needed to spend them. Uploaders discovered that the public-key slots could carry arbitrary bytes. A transaction can include many such multisig outputs, each carrying one or more fake key-sized chunks.

There are two styles. Some outputs include one real key and one or two fake data keys, making the output spendable later. Others use only fake keys and effectively burn the output. The Bitcoin whitepaper upload used fake multisig because it is much more space-efficient than fake P2PKH addresses.

Reconstruction means taking the public-key-sized payload fields from each multisig output and removing wrapper bytes that only exist to make the field look like a public key. The kitchen selfie is a concrete example: every payload chunk had a leading public-key-prefix byte that had to be stripped before the JPEG became valid.

OP_RETURN explicitly marks an output as unspendable and lets it carry a small data payload. Unlike fake-address methods, it does not create a spendable-looking UTXO. That makes it the least deceptive standard way to place small data on-chain.

The size limit has changed over time, but the important practical point is that an OP_RETURN output is small. It is excellent for hashes, short messages, protocol prefixes, filenames, and pointers. Large objects require many transactions or an external protocol for ordering.

Many metadata systems use OP_RETURN as their visible anchor: Counterparty, Omni, Open Assets, Factom, Eternity Wall, and many smaller experiments. It also carries ASCII art lines and small plaintext messages.

A daisy chain splits a larger object across many OP_RETURN transactions and links them through spends: one transaction funds or points to the next, so a decoder can walk the chain in order.

The simplest version just appends each OP_RETURN payload as the chain is followed. More specialized versions add headers with a magic byte, package number, and sequence number so fragments can be sorted and grouped even if the chain has mistakes.

The Iranian polar-bear-hat image uses a return-blob variant. Its early packets literally describe the protocol: a magic value, package number, sequence number, and small payload. The artifact is still incomplete because the later JPEG bytes were never found on-chain.

P2SH methods are two-stage. First, a setup transaction creates script-hash outputs. Later, a spend transaction reveals input scripts containing the actual data plus a redeem script. Because the data appears when the output is spent, it does not remain in the UTXO set.

Data Drop variants push data onto the script stack and then discard it during script execution. This gives high capacity, but the data itself is not strongly committed unless the construction also uses signatures or hashes.

Data Hash variants commit to each data chunk by putting its hash in the redeem script. When the spend happens, the provided chunk must match the committed hash. This is more robust against tampering and is the family used by several large image examples in the catalog.

SegWit moved signatures and related unlocking data into a witness area that is still committed to by the block but counted differently for block weight. That witness area can also carry arbitrary data if a spending path is constructed to reveal it.

Pre-Ordinals experiments used witness data directly for files such as images. The Taproot-era Ordinals/inscriptions wave later standardized this with an envelope that declares a content type and carries content bytes — the technique behind the inscription boom of 2023.

It is still on-chain data, but it lives in witness data rather than in fake payment outputs.

Base58 inscriptions put text into the visible address string itself. The address must still satisfy Base58Check rules, including a checksum, so the text often uses substitutions and padding to make a valid-looking address.

These are not reconstructed by byte-decoding the address. The address is the message. Readers are meant to visually parse phrases embedded in strings that begin like ordinary Bitcoin addresses.

This is one of the oldest inscription styles in the catalog. It is expressive for short names, slogans, tributes, and jokes, but it is extremely inefficient and often burns funds to addresses nobody can spend.

AtomSea and EMBII built a higher-level publishing system on top of fake-key-hash style storage. A top-level transaction acts like an index: it contains ordered transaction IDs, length markers, filenames, captions, and sometimes profile or signature metadata.

The linked payload transactions carry the actual object bytes. A single AtomSea object can combine text and media, such as a caption followed by a JPEG, WAV, HTML page, or several files. The decoder has to follow the top-level index, assemble the child payloads, then carve out the declared file.

This is closer to a decentralized publishing protocol than a one-off data trick. The catalog keeps it as its own category because the system has authorship, social features, files, captions, and later trading/listing behavior layered on top of the raw Bitcoin transactions.

Some artifacts are visible or strongly evidenced, but the exact storage recipe is not fully understood yet. The bytes may appear in a recognizable place, or an external index may identify the object, while the original uploader’s ordering, compression, or framing convention remains unclear.

The catalog keeps these entries explicit rather than forcing them into the closest known bucket. That distinction matters: a verified transaction can still have an incomplete technical explanation.

As more patterns are reverse engineered, entries can move from unknown to a precise method with a reproducible reconstruction recipe.