Merge mining is a technique that lets a chain other than Bitcoin reuse Bitcoin's proof-of-work as its own. It lets Bitcoin miners use the same hashing effort to mine one or more auxiliary chains (Namecoin being the original and most well-known example), with no reduction in Bitcoin hashrate and only the additional requirement that miners or pools run auxiliary-chain software (e.g., a Namecoin node). The arrangement is one-sided: an auxiliary chain's nodes carry the code to recognise and validate the shared work, while Bitcoin itself is unchanged and unaware any of it is happening.

Beginning with a brief history of where the idea came from, this post walks through how Bitcoin and auxiliary-chain blocks are linked. It covers the merkle structure that lets multiple auxiliary chains piggyback on individual Bitcoin blocks, the Auxiliary Proof-of-Work (AuxPoW) record carried by each auxiliary block, and the cryptographic checks an auxiliary node performs to validate a merge-mined auxiliary block. A companion post catalogues the chains that have adopted AuxPoW with Bitcoin as their parent and examines which mining pools embed merge-mining commitments in their coinbases. Not every Bitcoin-merge-mined chain, however, uses AuxPoW; some commit through a different mechanism that lives in a coinbase output rather than the coinbase scriptSig (OP_RETURN tag-based merge mining). We touch on that alternative approach in a later section, though the bulk of this post focuses on AuxPoW merge mining.

This piece is a bit of a detour from my planned treatment of Bitcoin network monitoring topics, such as a continued examination of the peer observer ecosystem and a grounding in the network's important properties, but there is good reason for it. Each AuxPoW chain that has merge-mined with Bitcoin holds, in its own permanent record, a copy of the Bitcoin block header whose proof-of-work was reused for each of its merge-mined blocks, including headers that Bitcoin's own canonical chain discarded. More specifically, those AuxPoW chains are a side-channel into block propagation (one of those important network properties) and the stale blocks those propagation delays help create. A follow-up post uses that side-channel to put numbers on a long-standing theoretical claim: that smaller mining pools produce more stale blocks, relative to their hashrate, than larger ones. This post is the groundwork.

A brief history

Merge mining is a Satoshi-era idea, first sketched on BitcoinTalk in late 2010 and realised a year later as part of Namecoin. In mid-November 2010, a BitcoinTalk thread titled "BitDNS and Generalizing Bitcoin" opened a discussion about whether Bitcoin's chain should host a DNS-like service for human-readable identifiers. The first half of that title was the specific proposal; the second half, the broader question the thread quickly turned to: what else could a proof-of-work chain be used for, and where should those services live, on Bitcoin's chain or separately?

Satoshi weighed in on 9 December 2010, arguing that BitDNS should be a completely separate network with its own block chain, but that the two could share their proof-of-work:

I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.

The networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.

[...]

Instead of fragmentation, networks share and augment each other's total CPU power. This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one. Instead, all networks in the world would share combined CPU power, increasing the total strength. It would make it easier for small networks to get started by tapping into a ready base of miners.

This idea was the nexus for what became merge mining.

Namecoin launched in April 2011 as the first chain to come out of the BitDNS thread. Its early months were a case study in the problem Satoshi's reply had warned about: the chain ran with its own independent SHA-256d hashrate, small enough to be vulnerable on its own. About six months later, in October 2011, the merge-mining hard fork activated at Namecoin block 19,200. In practice every Namecoin block from that height onwards has carried an AuxPoW record committing it to a Bitcoin parent block. The specification that emerged from that work, written primarily by Namecoin's early contributors, became the baseline for Bitcoin-parent AuxPoW chains.

Two chains, one hash

Under that specification, two chains advance in parallel from the same Bitcoin hashing effort, each with its own independent difficulty target. Bitcoin's parent_target is the threshold a candidate Bitcoin block header's hash must clear for the block to qualify as a valid Bitcoin block. The auxiliary chain's aux_target is set independently of parent_target and almost always numerically much larger (i.e., easier to satisfy), so the chain produces blocks at its own intended rate.

Each candidate Bitcoin block has its 80-byte header (Figure 1) put through a single SHA-256d evaluation, and the resulting 32-byte digest is compared independently against both targets (Figure 2). For a merge-mining miner, three outcomes are possible.

1. If the hash exceeds aux_target (and therefore the lower parent_target too), the candidate is discarded and neither chain extends.
2. If the hash falls to or below aux_target but still above parent_target, the candidate is a valid auxiliary block, but Bitcoin rejects it.
3. If the hash is at or below parent_target, both bars are cleared at once: the candidate is a valid Bitcoin block (assuming the rest of consensus passes) and a valid auxiliary block.

The third outcome splits further on Bitcoin's side: those candidates either become canonical Bitcoin blocks or stales that lost a chain race. Because every accepted auxiliary block stores its parent header in an AuxPoW record (detailed in the next section), there are three categories of parent headers stored in the auxiliary chain (figure):

1. Canonical Bitcoin blocks (won their chain race; e.g., Block B)
2. Bitcoin stales (met parent_target but lost their chain race; e.g., the stale that lost to Block B+1)
3. Aux-only parent headers (hash met only aux_target; e.g., the parent header for NMC block N+2)

The stales are what make AuxPoW chains a side-channel into Bitcoin's PoW history. This is the premise of Stifter et al.'s 2018 paper Echoes of the Past: Recovering Blockchain Metrics From Merged Mining, which used the AuxPoW records on merge-mined chains to reconstruct Bitcoin's historical stale block and fork rates, surfacing a non-negligible portion of stale blocks absent from the live monitoring record (this work will be revisited in detail in a future post).

The coinbase commitment

On the Bitcoin (parent) side, the AuxPoW marker is a 44-byte blob inside the [[coinbase's scriptSig||Bitcoin consensus caps it at 100 bytes total.]] (coinbases without merge-mining simply don't carry it). Thus Bitcoin commits to AuxPoW data (if present) indirectly through the block header's merkle_root; see the Reminder: from block header to coinbase scriptSig section below for the full details.

Reminder: from block header to coinbase scriptSig

{#scriptsig-path} The block header is the 80-byte object whose hash is tested against parent_target and, when merge-mining, against aux_target too. One of its six fields is merkle_root: the root of the merkle tree built from every transaction txid in the block body. The coinbase transaction's txid is leaf 0 in that tree, and the coinbase transaction's first input contains the scriptSig field (Figure 3). This is a "free-form" metadata area that miners use to record:

• The block height, as required by BIP 34,
• An extranonce that the mining hardware iterates on,
• The AuxPoW marker (optional; only when merge-mining), and
• The pool-identifying tags and any additional miner data (optional).

For more on the extranonce mechanism, see learnmeabitcoin.com's excellent interactive nonce explainer.

The AuxPoW marker within the coinbase scriptSig has four fields as illustrated in Figure 4. The first 4 bytes are the 0xFA BE 6D 6D magic, a fixed identifier that lets auxiliary-chain nodes easily locate the marker without ambiguity. The next 32 bytes are the aux_merkle_root, the commitment that links this Bitcoin block to one or more auxiliary blocks. The final 8 bytes are two little-endian uint32 values: merkle_size and merkle_nonce. Auxiliary-chain nodes use those two values to locate each chain's commitment within the merkle tree. What that tree looks like on the auxiliary-chain side is the subject of the next section.

From Bitcoin's side, none of these 44 bytes are consensus-relevant. Bitcoin's nodes never read the marker and have no way of knowing the block is also a valid merge-mined block somewhere else. That is the whole reason merge mining is one-sided: an auxiliary chain can leverage Bitcoin without Bitcoin ever knowing about it.

The merkle slot tree

The merkle slot tree is the structure that lets multiple auxiliary chains piggyback on the same parent Bitcoin block at once. Each participating chain occupies one position in a fixed-size merkle tree, and the single root of that tree is committed in the parent coinbase's AuxPoW marker as the 32-byte aux_merkle_root introduced in the previous section. A "slot" is one such leaf position, indexed from 0 to merkle_size - 1, where merkle_size is a power of two also declared in the marker (Figure 5).

Each slot holds a 32-byte value: for an occupied slot, that value is the auxiliary block hash; for an unused slot, it is just arbitrary 32-byte filler, not another meaningful commitment. The miner locks in the filler choice before computing the root, and the same filled-in tree backs every chain's commitment into this parent block. The Namecoin worked example later in this post shows an actual filler value picked by AntPool. The tree then hashes upwards, Bitcoin-style, using double SHA-256. In the four-slot example of Figure 5, h01 = SHA-256d(s0 || s1), h23 = SHA-256d(s2 || s3), and aux_merkle_root = SHA-256d(h01 || h23). At each level, two 32-byte children are concatenated into a 64-byte input, and the hash output is again 32 bytes.

Which slot a chain occupies is determined by its chain_id combined with the merkle_nonce. The chain_id is fixed by the chain; there is no central chain_id registry, and apparently no real coordination on assignment either. The closest thing is BitcoinTalk thread 769073, opened in 2014, three years after Namecoin's AuxPoW fork, as a catalogue of chain_ids (though it listed Namecoin's chain_id incorrectly until July 2015). In practice this doesn't seem to have been a problem: the population of active AuxPoW chains is small, and a chain_id clash only bites when a single parent block commits to both colliding chains at once.

merkle_nonce was meant to be the miner's tuning knob for avoiding slot collisions when committing to multiple auxiliary chains at once, but the published formula only shifts colliding chains together. This failure is called out in the Bitcoin Wiki Aux work merkle tree notes and in the Nonce for merged mining chain merkle tree index BitcoinTalk thread.

The mapping process uses a deterministic linear congruential generator (LCG) to decide placement (see the Slot mapping details section below). It does not derive any auxiliary block hashes; the 32-byte values come from the auxiliary chains' block headers, and those hashes get committed into the slots.

Slot mapping details

{#slot-mapping-details} The slot index is computed from merkle_nonce and chain_id, with all arithmetic on 32-bit unsigned integers (multiplications wrap modulo (2^{{32})). Each rand = rand * 1103515245 + 12345 line is one LCG step, using the multiplier (1103515245) and increment (12345) from ANSI C's rand(), but with 32-bit unsigned wraparound rather than ANSI C's mod 2}31. The chain_id is mixed in between two iterations, and the final modulo reduces the 32-bit output to a slot index:

rand = merkle_nonce
rand = rand * 1103515245 + 12345
rand = rand + chain_id
rand = rand * 1103515245 + 12345
slot = rand mod merkle_size

The result is a slot index between 0 and merkle_size - 1.

However, if two chains' chain_ids collide for a given power-of-two merkle_size, changing merkle_nonce does not fix the collision; it only moves both chains together. The miner must use a larger merkle_size, omit one chain, or rely on chain IDs that do not collide modulo the chosen tree size. And because each chain's verifier independently runs the LCG to find its expected slot, a miner cannot silently put two chains at the same leaf: a verifier whose slot is occupied by another chain's commitment rejects the AuxPoW.

The simplest case is merkle_size = 1, where a miner is committing to only one auxiliary chain. The tree collapses to a single leaf: the chain's block hash sits at the root directly, and the merkle_nonce is irrelevant (the LCG always returns slot 0).

In practice, miners committing to multiple AuxPoW chains do so via a single shared slot tree: the same hashing effort can earn a block reward from every chain in the tree whose aux_target the resulting hash clears. A pool mining Namecoin alongside Elastos and other AuxPoW chains picks a merkle_size to fit the chains it commits to, with each occupying the slot its chain_id resolves to.

Each participating chain ends up with a different proof through this one shared tree: its own slot, its own sibling hashes, its own bit-path up to the root. The parent block, the coinbase marker, and the aux_merkle_root are common to all of them; the per-chain proof is what differs. The worked example later in this post walks through such a tree in detail.

The AuxPoW record

The standard AuxPoW format, originally specified by Namecoin and adopted byte-for-byte by most Bitcoin-parent AuxPoW chains, puts an AuxPoW record between the 80-byte auxiliary header and the block body's transaction list. This AuxPoW record is a variable-sized structure with five fields, as shown in Figure 6.

Three fields are parent-side data carried into the auxiliary block. coinbase_txn is the full serialised parent coinbase transaction; the verifier scans its scriptSig for the 0xFA BE 6D 6D magic and reads the aux_merkle_root out of the bytes that follow. [[parent_block_hash||This field is unnecessary for validation because the full parent header is already present in the same AuxPoW record; the Bitcoin Wiki flags it as such.]] is a 32-byte convenience value that the verifier ignores. Early Namecoin AuxPoW blocks even shipped it in inconsistent byte order (some in standard little-endian internal byte order, some reversed) without breaking validation. parent_block_header, by contrast, is the field that actually drives validation: the verifier computes SHA-256d over its full 80 bytes and tests the result against aux_target to confirm the auxiliary block's proof-of-work.

The remaining two fields are compact merkle proofs, not copies of the full parent transaction tree or the full auxiliary slot tree. They give the verifier just enough sibling hashes to fold a known starting hash up to the parent's transaction merkle_root (for coinbase_branch) and the aux_merkle_root (for blockchain_branch).

For coinbase_branch, the start hash is txid(coinbase_txn) and the expected root is the Bitcoin transaction merkle_root from parent_block_header. This proves that the proof-of-work in parent_block_header was performed over a transaction merkle root consistent with a tree containing coinbase_txn. That coinbase carries the AuxPoW marker that commits to this auxiliary chain (and to any others sharing the same slot tree).

For blockchain_branch, the start hash is this auxiliary block's hash and the expected root is the aux_merkle_root found in the parent coinbase's AuxPoW marker. This proves that the coinbase marker commits to this auxiliary block's hash (alongside any other chains' block hashes in the shared slot tree).

The two branch payloads carry the "middle part" of those two checks: the sibling hashes and the side masks needed to fold the start hash up to the expected root (see the Merkle branch details section below). How these fields combine into a verification check is the subject of the next section.

Merkle branch details

{#merkle-branch-details} Both branches use the same three-input fold pattern:

• A start hash, fetched from surrounding AuxPoW data (it is never stored inside the branch payload).
• A branch payload: a CompactSize sibling count, the sibling hashes themselves, and a 4-byte side mask whose role differs per branch.
• An expected root, also fetched from surrounding AuxPoW data.

The fold sets current to the start hash, then walks branch_hash[] one sibling at a time, reading the matching bit from the side mask starting at bit 0. If the bit is 0, current sat on the left at that tree level and the step is current = SHA-256d(current || sibling); if the bit is 1, current sat on the right and the step is current = SHA-256d(sibling || current). Read from bit 0 upward, the side mask is therefore the leaf-to-root path of the value being proved. After the last sibling, current must equal the expected root.

The two branches differ in what each input refers to and in what the side mask encodes.

coinbase_branch

• Start hash: txid(coinbase_txn), the SHA-256d of the serialised parent coinbase transaction carried in this same AuxPoW record.
• Expected root: the Bitcoin transaction merkle_root from parent_block_header.
• Side mask: all four bytes are zero, because the coinbase is always at leaf 0 of the parent transaction tree, putting current on the left at every level.

A successful fold ends with current equal to the parent header's merkle_root.

blockchain_branch

• Start hash: this auxiliary block's header hash.
• Expected root: the aux_merkle_root embedded in the parent coinbase's AuxPoW marker.
• Side mask: the four bytes hold this chain's slot index in the slot tree, little-endian, so its binary digits are already the per-level left/right pattern the fold needs (bit 0 at the leaf level). The mask is chain-specific: every other auxiliary chain merge-mined into the same parent Bitcoin block carries its own blockchain_branch (own start hash, own sibling hashes, own slot index), and they all fold up to the same shared aux_merkle_root.

The verifier also independently derives the expected slot index from chain_id, merkle_nonce, and merkle_size, and rejects the proof if it differs from the side-mask value. When the slot tree has only one leaf (merkle_size = 1), the payload reduces to 5 bytes of zeros: [[0x00 00 00 00 00||One byte of CompactSize length (zero siblings) followed by a 4-byte side mask of all zeros. The Bitcoin Wiki worked example shows this exact pattern.]]. The fold has no siblings to process, so the start hash is already the expected root. A successful fold ends with current equal to the aux_merkle_root from the parent coinbase marker.

Verification

For an auxiliary chain's node, verification answers a single question: does this candidate AuxPoW block actually inherit the parent's proof-of-work? The PoW link verification can be summarised as five checks, and the PoW link is valid only if all of them pass (Figure 9).

The order below establishes identity first (steps 1 and 2) before walking the chain of commitments from the auxiliary block out to the parent's proof-of-work (steps 3 through 5). Real implementations (e.g., Elastos's AuxPow.Check, following the Bitcoin Wiki specification) sequence the same checks differently and also perform additional structural validation of the AuxPoW record.

1. Locate the AuxPoW marker inside the parent coinbase: [[scan||When the magic is present it must appear only once in the scriptSig, blocking an "equivocation attack" where a miner embeds different markers for different chains. The legacy no-magic form (aux merkle root in the first 20 bytes) is also permitted but rarely seen.]] coinbase_txn's scriptSig for the 0xFA BE 6D 6D magic, and read the embedded aux_merkle_root, merkle_size, and merkle_nonce from the bytes that follow.
2. Cross-check the slot index: independently derive the expected slot by running the LCG over chain_id and the marker's merkle_nonce and merkle_size, and confirm it matches the slot encoded in blockchain_branch's side mask.
3. Reconstruct aux_merkle_root: starting from this auxiliary block's hash (SHA-256d of its 80-byte header), fold the hash up through blockchain_branch (using the side-mask bits validated in step 2 to position current left or right at each level), and confirm the resulting root matches the aux_merkle_root extracted from the marker in step 1.
4. Reconstruct the parent block's transaction merkle_root: compute the coinbase txid (SHA-256d of coinbase_txn) and fold it up through coinbase_branch, and confirm the resulting root matches the merkle_root field inside parent_block_header.
5. Verify the proof-of-work: compute SHA-256d of parent_block_header and check that the resulting hash is at or below aux_target.

Step 5's aux_target test, looser than Bitcoin's parent_target, is what admits aux-only parent headers (those clearing aux_target but not parent_target) into the auxiliary chain's record. Combined with the canonical blocks and stales that clear both targets, the record collects all three populations of parent headers the post identified earlier.

Worked example: Namecoin block 823,506

{#worked-example} We walk through verification on a recent Namecoin block: block 823,506, mined by AntPool. This is a typical modern AuxPoW block:

• merkle_size = 16: multiple AuxPoW chains committed via the slot tree,
• A 4-sibling blockchain_branch: one sibling per merkle level, (\log_2(16) = 4), and
• A 13-sibling coinbase_branch.

The relevant fields from the block JSON (annotated; the full record is at the link above; chainindex is the JSON name for the side mask):

{
  "hash":       "3e78ac34...9c9f6d88",                     // aux block (Namecoin) hash
  "auxpow": {
    "chainindex": 11,                                      // Namecoin's slot in the parent's slot tree
    "chainmerklebranch": [                                 // blockchain_branch siblings (4)
      "000000000000000000000000000000000000000000000000000000000000000a",
      "8ccfc263c108561c4e1c6c30b49fdab67c4ac12090291de80b9f07725c72717c",
      "ace26173348b3779777fdfd38835f76b2e5e0cf0f1e32b3c01fd9c6822c7c9b1",
      "a697adc4c5f4b32251e5ecd1aa16d038256e3750b8639c51df780745cc2db842"
    ],
    "merklebranch": [ /* 13 hashes - coinbase_branch siblings, omitted */ ],
    "tx": {
      "txid":      "c6cd5ec9...14e37cd5",                  // parent coinbase txid
      "vin":       [{"coinbase": "03ab770e...00000000"}],  // dissected below
      "blockhash": "00000000...20906c38"                   // parent Bitcoin block hash
    },
    "parentblock": "00000420...61514998"                   // serialised 80-byte parent header
  }
}

The parent coinbase scriptSig, dissected into fields:

"03ab770e"                                                         // BIP 34 push: parent height 948,139
"19" "4d696e656420627920416e74506f6f6c20"                          // 25-byte push containing a 17-byte tag: "Mined by AntPool "
     "87003601907790c0"                                            //   ...and 8 bytes pool extranonce
"fabe6d6d"                                                         // AuxPoW magic
"5a9c0198abca4e8c94a1ce47b0f09cf843e33a6a4d3aaf6b9240b08061d68a42" // aux_merkle_root (matches step 3 fold)
"10000000"                                                         // merkle_size = 16 (LE u32)
"00000000"                                                         // merkle_nonce = 0
"0000e66cf007010000000000"                                         // trailing scriptSig bytes (pool extras)

Step 1 (locate marker in parent coinbase). Inside the parent coinbase's scriptSig, the magic fa be 6d 6d sits at byte offset 30, after a BIP 34 height push and a 25-byte push containing the 17-byte ASCII tag Mined by AntPool plus 8 bytes of pool extranonce. The 32 bytes following the magic are 5a9c0198...61d68a42, which we'll match against the fold result in step 3. The trailing 10 00 00 00 and 00 00 00 00 give merkle_size = 16 and merkle_nonce = 0.

Step 2 (cross-check slot index). Running the LCG over chain_id = 1 (Namecoin), merkle_nonce = 0, and merkle_size = 16 (the latter two from the marker bytes in step 1) returns 11, matching the side mask carried in blockchain_branch's chainindex field.

Step 3 (reconstruct aux_merkle_root). Namecoin's slot in this block is 11 (validated in step 2), carried in the AuxPoW record's chainindex field (the JSON-friendly form of the 4-byte side mask at the tail of blockchain_branch). That slot index doubles as the side mask for the four-sibling replay: slot 11 in binary is 1011, so reading bit 0 (the LSB) first, the side bits at levels 0, 1, 2, 3 are 1, 1, 0, 1.

We start current at the aux block header hash from the JSON's hash field, then apply four SHA-256d steps, each pairing current with the next sibling from chainmerklebranch[]:

current = 3e78ac34...9c9f6d88   (aux block header hash)

level 0 (bit 1, current on the right):
  current = SHA-256d(00000000...0000000a ‖ 3e78ac34...9c9f6d88)
          = 1ef8737d...e74dc89f

level 1 (bit 1, current on the right):
  current = SHA-256d(8ccfc263...5c72717c ‖ 1ef8737d...e74dc89f)
          = 3c11d081...44b313cf

level 2 (bit 0, current on the left):
  current = SHA-256d(3c11d081...44b313cf ‖ ace26173...22c7c9b1)
          = fe16c528...4a10d456

level 3 (bit 1, current on the right):
  current = SHA-256d(a697adc4...cc2db842 ‖ fe16c528...4a10d456)
          = 5a9c0198...61d68a42

The final current, 5a9c0198...61d68a42, is the reconstructed aux_merkle_root, matching the aux_merkle_root extracted from the marker in step 1.

Step 4 (reconstruct parent merkle_root and match). The start hash is the coinbase txid, c6cd5ec9...14e37cd5. The side mask is 0x00000000, so at every level current is on the left and the sibling on the right (the coinbase is always leaf 0 regardless of how many transactions sit beside it). The branch carries 13 siblings, consistent with a parent transaction merkle tree of 4,097 to 8,192 leaves. Folding all 13 in yields d63208d5...3d0aa08d, matching the merkle_root field of parent_block_header.

Step 5 (verify PoW). SHA-256d of parent_block_header reproduces the parent block hash. Namecoin's aux_target at this height has compact form 0x1703e336, which expands to a 32-byte target with nine leading zero bytes followed by 0x03 e3 36 00 .... Lining up the hash and target as big-endian byte strings:

hash:    00 00 00 00 00 00 00 00 00 02 ...
target:  00 00 00 00 00 00 00 00 00 03 e3 36 ...

The first nine bytes are equal; at the tenth byte, the hash (0x02) is below the target (0x03), so the hash is below aux_target and the parent's work clears it.

That same hash, however, exceeds Bitcoin's parent_target at this height (compact bits = 0x17021ff0), making this parent aux-only (the third category from Two chains, one hash). Bitcoin's canonical block at height 948,139 is a different hash (000000000000000000018551...87613a79); only Namecoin's AuxPoW record preserves the parent header here.

Aside on the slot 10 filler. The level-0 sibling, 00000000...0000000a, is the value occupying slot 10 in this AntPool block's slot tree. A genuinely occupied slot would carry another auxiliary chain's 32-byte block hash (high entropy throughout); this near-zero pattern is consistent with an unused slot.

OP_RETURN tag-based merge mining

AuxPoW is not the only way for a chain to reuse Bitcoin's proof-of-work. Some chains instead embed a chain-specific marker in a dedicated OP_RETURN output in the parent's coinbase. Unlike AuxPoW, where the data is embedded in the parent's coinbase transaction input (scriptSig), these markers live in the coinbase transaction outputs (scriptPubKey).

There doesn't appear to be a settled name for the technique, so we'll refer to it as OP_RETURN tag-based merge mining. The Mempool Research merge-mining report describes the common form as a zero-value OP_RETURN carrying a tag (usually ASCII) unique to the merge-mined chain. A bare tag only marks the parent block as co-mined; it is only when the tag is followed by a payload (a hash of the aux chain's block, or similar) that the aux chain can verify Bitcoin's PoW for that specific block.

This should not be confused with blind merge mining (BMM), the Drivechain (BIP 300, BIP 301) concept where the miner does not run the sidechain node. BIP 301 also uses an OP_RETURN commitment, so the difference is not the embedding location but the miner's relationship to the sidechain.

In OP_RETURN tag-based merge mining, each output is a coinbase txout whose scriptPubKey is OP_RETURN <chain tag> <payload>, where the tag is a short ASCII identifier and the payload's contents vary widely between chains: an aux block hash for direct PoW binding (e.g., RSK, tag RSKBLOCK:), accounting metadata for hashrate delegation (e.g., CoreDAO, tag CORE), an aux block hash and height tag for fork-aware cross-chain bridging (e.g., Syscoin, tag sys), or other chain-specific data.

Since SegWit activated in 2017, almost every Bitcoin coinbase has already carried one OP_RETURN by default: per BIP 141, every coinbase whose block contains a witness-bearing transaction must include an OP_RETURN with magic prefix 0xaa21a9ed followed by a 32-byte commitment to the witness merkle root. Bitcoin coinbases can carry multiple OP_RETURN outputs, so tag-based merge-mining commitments simply add to that mandatory one. The coinbase of block 948,433, mined by SpiderPool, is one such case (figure):

OP_RETURN aa21a9ed7a379f...        SegWit witness commitment (BIP 141, mandatory)
OP_RETURN CORE 01 64db24a6...      CoreDAO hash-delegation metadata
OP_RETURN EXSAT 01 120f0803...     exSat synchronizer metadata
OP_RETURN RSKBLOCK: 6e48ff1e...    RSK merge-mining commitment
OP_RETURN sys 615097dc...          Syscoin merge-mining commitment

Compared with AuxPoW, tag-based approaches avoid the shared tree, chain-ID coordination, the broken merkle_nonce collision-avoidance scheme, and the marker placement rule. A miner participating in multiple such systems simply emits one coinbase OP_RETURN output for each system.

What these approaches give up is the shared verification model. Each tag-based chain defines its own rule for what counts as a valid Bitcoin parent and how the parent header or Bitcoin block metadata is carried in its own format. There is also no single specification document equivalent to the Merged mining specification; each chain defines its own.

The two mechanisms coexist in the same Bitcoin coinbase because they live in different fields: AuxPoW commits via the input scriptSig, OP_RETURN tag-based approaches commit via output scriptPubKeys. Bitcoin block 948,433 as examined above illustrates this (figure): alongside five OP_RETURN outputs (the SegWit witness commitment plus four project/protocol tags, including RSK/Syscoin merge-mining commitments and Core/exSat coordination metadata), the coinbase scriptSig carries an AuxPoW marker that, with merkle_size = 8, commits to up to eight auxiliary chains:

"03d1780e"                                                         // BIP 34 push: parent height 948,433
"045899fd69"                                                       // 4-byte push: pool extranonce (LE u32 = 0x69fd9958)
"537069646572506f6f6c2f3134372f"                                   // 15-byte ASCII tag: "SpiderPool/147/"
"fabe6d6d"                                                         // AuxPoW magic
"40c91d098550760af551762fa506da60fb1ed54256c9d5f9123816d8967111f9" // aux_merkle_root
"08000000"                                                         // merkle_size = 8 (LE u32)
"b9035e3f"                                                         // merkle_nonce (LE u32 = 0x3f5e03b9)
"b6f68743200090c94e12000000000000"                                 // trailing scriptSig bytes (pool extras)

That is, AuxPoW and tag-based commitments can reuse the same Bitcoin proof-of-work in the same parent block. On the Namecoin side of this commitment, Namecoin block 823,793 carries Bitcoin 948,433's 80-byte header inside its AuxPoW record at slot 4 of the marker's 8-slot tree, exactly the side-channel introduced earlier in the post. The full mempool.space view of this coinbase, with the AuxPoW magic highlighted in the scriptSig, is shown in the full coinbase breakdown below for reference.

Full coinbase breakdown of Bitcoin block 948,433

{#mempool-space-block-948433-details}

Conclusion

AuxPoW gives an auxiliary chain a way to reuse Bitcoin's proof-of-work without any participation from Bitcoin itself. This satisfies the idea Satoshi proposed in 2010: the parent network needs no coordination with any auxiliary chains, yet many chains can share the parent's hashing effort through a single coinbase commitment to a shared merkle slot tree of auxiliary block hashes.

A single SHA-256d evaluation of the parent header serves both sides. The hash is tested against parent_target on Bitcoin's side and against aux_target on the auxiliary chain's side (almost always the easier threshold), with three possible outcomes: rejected, aux-only valid, or both parent and aux valid.

The AuxPoW specification makes this verifiable on the auxiliary side using three pieces. A 44-byte AuxPoW marker in the parent coinbase scriptSig binds the parent block to that shared merkle slot tree of auxiliary block hashes. An AuxPoW record on the auxiliary chain carries the parent coinbase, the parent header, and the merkle paths needed to verify that commitment. A five-step verification rule then validates the PoW link regardless of whether Bitcoin's canonical chain ever accepts the parent block.

Together the three pieces let the auxiliary chain treat any candidate hash that clears aux_target as proof-of-work for its block, whether or not Bitcoin accepts the parent. Every AuxPoW record also retains its full parent header, including headers Bitcoin's canonical chain discarded, making AuxPoW chains a side-channel into Bitcoin's PoW history.

OP_RETURN tag-based merge mining sits alongside AuxPoW as a lighter, per-chain alternative: a coinbase OP_RETURN output per chain rather than a shared scriptSig marker, with each chain free to define its own tag, payload format, and commitment semantics (e.g., PoW binding like AuxPoW, or another purpose such as delegation accounting or fork-aware bridge notarisation). The two embedding locations coexist in the same coinbase without interfering (figure): AuxPoW commits via the input scriptSig, OP_RETURN tag-based approaches via the output scriptPubKeys.

A companion post catalogues every chain that has actually deployed AuxPoW with Bitcoin as its parent, and examines which Bitcoin mining pools embed merge-mining commitments in their coinbases.

A separate follow-up post will use the side-channel AuxPoW creates (auxiliary chains preserving parent headers Bitcoin discarded as stale) to put numbers on a long-standing claim about block propagation: that smaller mining pools produce more stale blocks, relative to their hashrate, than larger ones.

References

Specifications and primary sources

• Merged mining specification (Bitcoin Wiki)
• Community catalogue of merge-mined chain IDs (BitcoinTalk thread 769073)
• BitDNS and Generalizing Bitcoin (BitcoinTalk, November 2010)
• Satoshi: BitDNS as a separate chain sharing proof-of-work (BitcoinTalk, 9 December 2010)
• Namecoin merge-mining hard fork announcement, block 19,200 (Namecoin Forum, 2021 Wayback snapshot; the live forum has been down since May 2025)
• Nonce for merged mining chain merkle tree index (BitcoinTalk)
• Namecoin project site
• BIP 34: Block v2, Height in Coinbase
• BIP 141: Segregated Witness (Consensus layer)
• BIP 300: Hashrate Escrows (Drivechains)
• BIP 301: Blind Merged Mining
• RSKIP-92: Merkle proof serialization for merge-mined RSK blocks (Rootstock)
• Syscoin 5.0.0 release notes: AuxPoW tags

Papers and long-form explainers

• Stifter, Schindler, Judmayer, Zamyatin, Kern & Weippl. Echoes of the Past: Recovering Blockchain Metrics From Merged Mining (FC 2019)
• Zamyatin, A. Merged Mining: Analysis of Effects and Implications (TU Wien diploma thesis, 2017)
• Judmayer, Zamyatin, Stifter, Voyiatzis & Weippl. Merged Mining: Curse or Cure? (CBT 2017)
• Tari Labs University: Merged Mining Introduction
• Mempool Research: Merge-mining report
• BitMEX Research: The Growth of Bitcoin Merge Mining (2020)
• Sergio Demian Lerner: Merged mining (Part I) (Bitslog, 2022)
• learnmeabitcoin: Nonce (interactive extranonce explainer)
• Linear congruential generator (Wikipedia)

Reference implementations and worked-example data

• Namecoin Core: src/auxpow.cpp (the canonical C++ AuxPoW verification)
• Elastos.ELA: auxpow/auxpow.go (Go port of the same verification logic)
• Bitcoin Core: src/consensus/tx_check.cpp (coinbase scriptSig length limit)
• Namecoin block 823,506 (chainz.cryptoid.info)
• Bitcoin block 948,433 (mempool.space)
• Namecoin block 823,793 (chainz.cryptoid.info), the aux-chain block parented by Bitcoin block 948,433

Bitcoin's peer-to-peer (P2P) network is a distributed system that allows network participants (nodes) to interact without relying on a central authority. For the network to operate as efficiently and as decentralised as possible, Bitcoin nodes can operate in a variety of modes, fulfilling different roles. This post examines the various roles and modes of Bitcoin nodes and the topology of the Bitcoin network that this differentiation has led to.

Node reachability

One way of categorising nodes on the Bitcoin network is whether they are reachable or not. In essence, a node is reachable if other nodes on the network can initiate inbound connections to it.

More concretely, a node is likely to be reachable when it is configured to accept inbound connections (-listen=1, the default), binds to an appropriate network interface, and its listening port (default 8333 for mainnet) is accessible from the outside, either because the machine has a public IP directly, or because NAT/firewall rules forward traffic appropriately. There are also other considerations such as number of available connection slots for inbound peers, and whether the necessary plumbing is in place for alternative networks (e.g., a Tor hidden service, an I2P service, or a CJDNS address).

NAT, CGNAT, and node reachability

When the ISP assigns a public IP address (static or dynamic) directly to a customer's router, the router uses Network Address Translation (NAT) to share that address across devices on the customer's local network. Outbound connections work transparently, the router tracks the mapping and routes replies back, but unsolicited inbound connections have no existing mapping and are dropped. Since the router holds a public IP, this is straightforward to solve: a port forwarding rule on the router can direct inbound traffic on the listening port (e.g. 8333) to the node's private LAN address.

Some routers support NAT-PMP (NAT Port Mapping Protocol) or PCP (Port Control Protocol) to automate this. Bitcoin Core ships a built-in PCP/NAT-PMP implementation (since v29.0 with PR #30043) and enables it by default (since v30.0 with PR #33004), so a listening node behind a compatible router will automatically map its port without manual configuration. Earlier versions relied on UPnP via the miniupnpc library, but that was disabled by default in v0.11.1 after multiple security vulnerabilities and dropped entirely in v29.0.

However, a growing share of connections never receive a public IP at all. Carrier-Grade NAT (CGNAT) places multiple customers behind a shared public IP at the ISP level, so port forwarding on the home router is useless. Mobile networks use CGNAT almost universally, and fixed-line adoption is growing as all five Regional Internet Registries have exhausted their IPv4 free pools. For node operators behind CGNAT, the main workarounds are overlay networks: Tor hidden services (.onion), I2P (supported since Bitcoin Core v22.0 with PR #20685), or CJDNS (since v23.0 with PR #23077), all of which bypass NAT entirely.

So the Bitcoin network consists of reachable nodes, openly connectable and therefore straightforward to survey, and unreachable nodes, which cannot accept inbound connections (due to not satisfying one or more of the criteria outlined above) and are therefore much harder to catalogue through network observation alone. The primary way of learning about unreachable nodes is through addr messages gossiped across the network, with the caveat that an address appearing in gossip only confirms that a node existed at some point, not that it is still running.

As of April 2026, the long-running Bitnodes project, which aims to estimate "the size of the Bitcoin peer-to-peer network by finding all reachable and unreachable nodes", puts the total count at roughly 70,000, with around 23,000 (about a third) being reachable. That two-thirds are unreachable is unsurprising given the barriers facing home node operators: many sit behind NAT without port forwarding configured, and a growing share are behind CGNAT (see above), where inbound connections are impossible regardless of router settings. Node-in-a-box products (Umbrel, Start9, RaspiBlitz) sidestep this by defaulting to Tor, which makes them reachable within the .onion network but not from the clearnet.

Node connection management

Every node on the network automatically maintains a small set of outbound connections to peers it has selected itself. Reachable nodes additionally allocate slots for inbound connections - peers that have discovered and connected to them. In total, under a default configuration, a node has a maximum of 125 automatic peer connections (DEFAULT_MAX_PEER_CONNECTIONS) to maintain (Figure 1). The way these connection slots are budgeted, and the distinct roles assigned to different connection types, are deliberate design decisions that balance node resource constraints against the network's need for robust connectivity between nodes. Note that, as explored in other connection types, some special connection types have their own separate slot budgets and are not counted against this limit.

Outbound connections

In a default configuration, a node has 10 persistent outbound peers, and one short-lived feeler, for 11 outbound peers. The 10 persistent outbound peers consist of 8 outbound full-relay connections and 2 block-relay-only connections. The full-relay connections exchange all message types - addresses, transactions and blocks - with a default maximum of 8 specified by Satoshi in 2010. The block-relay-only connections, introduced in Bitcoin Core v0.19.0.1 (in 2019 with PR #15759), are only for the exchange of block headers and blocks.

Feeler connections are short-lived outbound connections opened approximately every 2 minutes to test whether addresses in the node's peer database are reachable, promoting them from the new table (learned via gossip, untested) to the tried table (successfully connected to at least once) on success. These tables are part of the node's address manager (AddrMan), which tracks known peer addresses and is complex enough that it will be covered in a future post.

Inbound connections

Unlike outbound connections, a reachable node has no say in who connects to it; any other node can claim one of its inbound slots. Inbound connections are therefore less trusted. A node relies on its outbound peers for its best approximation of the true network state. Inbound peers still contribute by relaying blocks and transactions to the wider network, and may even be the first to deliver them.

With a default cap of 125 automatic connections, 11 of which are reserved for outbound, there are up to 114 inbound slots. When a new peer attempts a connection, a node doesn't immediately refuse it. Instead, it evaluates the existing inbound peers and evicts "the least useful" (which could turn out to be the new peer itself!). Exploring the eviction logic is beyond the scope of this work, suffice to say it's a process that eliminates peers from being eviction candidates via multiple evaluation criteria, with the final remaining peer being the one that is dropped.

Inbound vs Outbound asymmetry

Since anyone can cheaply claim inbound slots, they are inherently vulnerable to Sybil attacks that manipulate the node's view of the network. Outbound connections, being self-selected from the address database with limited slots and randomised selection, are far harder to subvert. Several design decisions reinforce this asymmetry.

What's a Sybil attack?

A Sybil attack is when a single adversary creates many fake identities (in Bitcoin's case, many seemingly independent nodes) to gain disproportionate influence over a target. Since Bitcoin's P2P network is permissionless and there is little cost to spinning up new nodes, an attacker can flood a victim with connections that all appear to be distinct peers but are actually controlled by the same entity. If a node's connections are dominated by Sybil peers, those peers can collaborate to feed it a distorted view of the network: withholding blocks, censoring transactions, or manipulating relay timing. The outbound/inbound asymmetry described here is one of the primary structural defences against this class of attack.

Transaction inv messages are batched on a timer, with outbound peers receiving announcements every 2 seconds and inbound peers every 5 seconds. The concern is transaction origin inference: a spy opening many inbound connections could correlate inv timing to deduce that the node originated a transaction. The longer inbound interval ensures all inbound peers from the same network see the same inv simultaneously, eliminating differential timing signals regardless of how many connections the attacker opens. Outbound peers pose a much lower Sybil risk, so the faster interval trades a small amount of privacy for better propagation speed. That is, the batching makes the attack's effectiveness independent of how many inbound slots the adversary holds, adding more inbound (Sybil) connections yields no additional timing signal.

Outbound peers are also strongly preferred as block sources. With inbound slots being cheap to Sybil, an attacker dominating a node's inbound connections could withhold new blocks, e.g. keeping the node on a stale chain tip, or could selectively delay block announcements to gain a timing advantage. To guard against this, each outbound peer is marked as a preferred peer, meaning blocks are requested from outbound peers first, with inbound peers only used as a fallback when no preferred peers are available.

The same preference applies to header synchronisation: initial headers-first sync is only initiated from a preferred peer, with inbound peers as a fallback.

Finally, only inbound peers are subject to the eviction process described above. Outbound peers are not part of the inbound eviction process, since losing a self-selected peer would weaken the node's trusted view of the network. They can, however, still be disconnected for other peer-management reasons, such as stalling detection, extra block-relay peer rotation, or the network-diversity rebalancing discussed in bridge nodes below.

Address bootstrapping

There is a bootstrapping problem that a special class of outbound connection, ConnectionType::ADDR_FETCH, exists to solve: how does a node populate its address book when it doesn't yet know any peers? On first startup, or [[under various other circumstances||Such as after peers.dat has been deleted or corrupted, after being offline long enough for all cached addresses to exceed ADDRMAN_HORIZON (30 days), or after enough connection failures to mark all addresses "terrible" (ADDRMAN_RETRIES/ADDRMAN_MAX_FAILURES).]], AddrMan will be empty and the node will have nobody to connect to.

The primary bootstrap mechanism is DNS seeds: the node queries hardcoded DNS hostnames (see below) with a service-bit filter prefix that resolve to lists of active node IP addresses. If the requesting node is behind a proxy where direct DNS isn't possible, or if a seed doesn't support the requested service-bit filter and returns no results, the node falls back to opening an ADDR_FETCH connection directly to the seed. This is a short-lived connection that completes a version handshake, sends a getaddr message, receives an addr response, feeds those addresses into AddrMan, and disconnects. Note that the same mechanism serves -seednode peers: operator-specified peers that the node tries as a trusted bootstrapping source before falling back to the hardcoded DNS seeds.

Mainnet DNS seeds (Bitcoin Core v31)

As of v31, Bitcoin Core's mainnet configuration includes eight hardcoded DNS seeds in src/kernel/chainparams.cpp:

The x prefixed service bit filters (e.g. x9 = NODE_NETWORK | NODE_WITNESS) allow seeds to return only nodes advertising specific service flags.

ADDR_FETCH connections are short-lived (they disconnect as soon as addresses are received) and use the shared automatic outbound pool on a best-effort basis, so they do not displace the node's persistent outbound peers and may simply be skipped when no outbound slot is free.

Other connection types

Beyond the connection types discussed so far, Bitcoin Core defines two more outbound connection types: operator-specified peers (ConnectionType::MANUAL) and privacy-preserving transaction relay (ConnectionType::PRIVATE_BROADCAST). Each has its own slot accounting so they don't interfere with the automatic outbound budget.

MANUAL connections are created via the -addnode configuration option or the addnode RPC, and have their own separate 8-slot pool. That is, adding manual peers never displaces any (automatic) outbound connections, they are separately accounted for. Unlike automatic connections, manual peers are not subject to the same rotation and eviction logic, a node with manual peers will persistently try to maintain connections to them.

PRIVATE_BROADCAST is new in v31, enabled via the opt-in -privatebroadcast flag (off by default). These connections use a dedicated 64-slot budget, completely separate from the regular outbound pool. They open short-lived connections exclusively over privacy networks (Tor, I2P) to relay transactions submitted locally via RPC, then close (such that transaction broadcast over privacy networks never competes with regular outbound connection slots).

The complete set of connection types in Bitcoin Core

All seven connection types that have been discussed are defined in the ConnectionType enum in src/node/connection_types.h.

enum class ConnectionType {
    INBOUND,
    OUTBOUND_FULL_RELAY,
    MANUAL,
    FEELER,
    BLOCK_RELAY,
    ADDR_FETCH,
    PRIVATE_BROADCAST,
};

Node operating modes

Beyond reachability and connection management, nodes also differ in what they store, what they relay, and how much of the chain they keep after validating it. All of the configurations discussed in this section are full nodes: they independently validate every block against the consensus rules and maintain the UTXO set needed to do so, rather than trusting proof-of-work or any peer's assessment as a proxy for validity. Light clients, discussed separately below, are not nodes in this sense; they are wallet software that connects to full nodes as a client rather than participating as a peer.

The first distinction among full nodes is whether they retain a complete copy of the blockchain or not, that is, whether a node is a full archival node or a pruned node.

Archival nodes

Full archival nodes validate and retain every block from the genesis block onwards. This means they can serve any historical block to peers that request it, most importantly to new nodes that must download and validate the entire chain from scratch (initial block download - IBD). A full archival node should advertise as such by signalling NODE_NETWORK in the service flags in the version message it sends to peers during the version handshake.

The version handshake

When two Bitcoin nodes first connect, they exchange version messages before any other communication. The version message carries the node's protocol version, service flags (like NODE_NETWORK or NODE_NETWORK_LIMITED), current block height, a nonce for self-connection detection, and the fRelay flag indicating whether the sender wants transaction relay on this connection. The receiving node responds with a verack (version acknowledgement) message, and once both sides have sent and received verack, the connection is considered established. Only after this handshake completes will either peer process further messages. The service flags advertised in version are how peers learn each other's capabilities, though, as noted above, these are self-reported and unauthenticated.

Pruned nodes

Not every operator is willing or able to store the full block history - as of early 2026, the raw block data alone occupies roughly 775 GB, with the full data directory closer to 830 GB before any optional indexes. Pruned nodes (-prune=<N>) also download and fully validate every block, and maintain the full UTXO set, but discard old block data after validation. A pruned node relays new blocks and transactions normally, it simply can't serve historical blocks to peers performing IBD.

Regardless of the pruning target, a pruned node always retains at least the most recent [[288 blocks||MIN_BLOCKS_TO_KEEP in src/validation.h, with the value proposed by Gregory Maxwell during the original pruning design discussions as "a minimum number I'd consider acceptable as an absolute minimum for the purpose of reorgs."]], which is approximately two days' worth given the 10-minute block interval. The minimum pruning target of -prune=550 (MiB) is derived from this requirement, accounting for the 288 blocks themselves, undo data overhead, orphan block rate, and block file granularity. Pruned nodes advertise NODE_NETWORK_LIMITED rather than NODE_NETWORK in their service flags, signalling to peers that they can serve recent blocks but cannot be relied upon for historical data during IBD.

Blocks-only mode

Orthogonal to the archival/pruned distinction is whether a node participates in transaction relay. Running with -blocksonly disables ordinary transaction relay, so a node in this mode won't accept transactions from normal network peers. Because transaction relay dominates a typical node's traffic, blocks-only mode can reduce overall bandwidth consumption by as much as 88%. The trade-off is that the node sees far less unconfirmed transaction activity, so its mempool remains sparse, fee estimation is disabled, and it cannot make full use of the mempool-assisted fast path in compact block relay.

Compact block relay

BIP 152 compact block relay reduces block propagation bandwidth by exploiting the fact that a node's mempool already contains most of a new block's transactions. Instead of transmitting a full block, compact block relay uses a cmpctblock message containing the block header, a list of short transaction IDs, and any transactions the sender predicts the receiver won't have (the "prefilled" transactions, which always includes the coinbase). The receiver matches the short IDs against its mempool and, if any are missing, requests them individually via getblocktxn/blocktxn round-trips. A typical block compresses to a compact block message of roughly 9 KB (the header, short transaction IDs, and prefilled transactions); roughly two orders of magnitude smaller than the full block.

BIP 152 defines two modes. In low-bandwidth mode (the default for most connections), the sender first announces the block via headers (or falls back to inv) and only sends the compact block after the receiver requests it with getdata. In high-bandwidth mode, which a node requests from up to three peers via sendcmpct, the sender pushes the cmpctblock immediately upon validation, without waiting for a request, potentially even before fully validating the block itself. This shaves off a full round-trip and is the primary mechanism by which new blocks propagate quickly across the network.

The impact on propagation times has been dramatic: KIT DSN measurements observed block propagation drop from over 6 seconds (2015, pre-compact blocks) to under 1 second (2018) at the 50th percentile, with the 90th percentile falling from over 15 seconds to roughly 2 seconds.

The effectiveness of compact blocks depends directly on mempool overlap: the more transactions a node has already seen and validated, the fewer it needs to request after receiving a compact block. Monitoring by 0xB10C shows that under normal mempool conditions, over 80% of compact blocks reconstruct without any additional round-trips, though this can drop below 50% during periods of high mempool congestion (such as around the April 2024 halving). A blocks-only node, which maintains only a small mempool (5 MB by default vs the normal 300 MB) and receives no transaction relay, rarely has the transactions it needs, reconstructs compact blocks less efficiently, and often needs many missing transactions via getblocktxn, reducing or sometimes erasing the bandwidth benefit of the protocol.

A blocks-only node signals its preference during the version handshake by requesting no transaction relay. Peers that receive this instruction should not send inv messages for transactions to that connection (the same mechanism used by the block-relay-only connections discussed earlier, though there it is applied per-connection rather than node-wide). Note that -blocksonly is independent of -prune: a node can be archival and blocks-only (full history, sparse mempool), or pruned and full-relay (limited history, active mempool), or any other combination.

-blocksonly vs block-relay-only connections

These two mechanisms are easy to confuse because they sound similar and both set fRelay=false in the version handshake, but they operate at different scopes and serve different purposes.

-blocksonly is a node-wide configuration. When enabled, the node disables transaction relay across all of its connections: it does not announce transactions via inv, and it will ignore (and may disconnect peers that persist in sending) unsolicited transaction messages. The motivation is bandwidth reduction; on a typical node, transaction relay dominates traffic, so disabling it can cut bandwidth consumption dramatically (e.g. 88%). A -blocksonly node still participates in address relay on its connections.

Block-relay-only connections (ConnectionType::BLOCK_RELAY) are a per-connection policy. A node in a default configuration opens exactly 2 of these outbound connections alongside its 8 full-relay outbound connections. These connections exchange block headers and blocks but never relay transactions or participate in address gossip (addr/getaddr). As aforementioned, the motivation is to help obfuscate the topology of the network.

Both advertise fRelay=false, but they are still distinguishable: block-relay-only connections do not participate in address gossip, whereas -blocksonly connections still can.

Light clients

Not every user needs or is able to bear the storage, bandwidth, and processing costs of full validation. Light clients are wallet software that connects to full nodes as a client rather than participating in the P2P network as a peer. Light clients do not validate blocks or enforce consensus rules. Instead, they only download block headers (and potentially full blocks) and use various protocols to learn about transactions relevant to them, trusting that the longest proof-of-work chain contains only valid transactions.

The two main protocols for light client data retrieval illustrate different trade-offs in how this trust model is implemented. The original approach, bloom filters (BIP 37), had the client send a filter describing its addresses of interest to a full node, which would then return only matching transactions with Merkle proofs of inclusion. This had well-documented privacy and DoS problems: the filter inherently leaked which addresses the client cared about (Gervais et al., 2014), and serving filter requests was computationally expensive for the full node with no way for the client to compensate. Bloom filter serving is now largely deprecated in Bitcoin Core and disabled by default since v0.19.0.1.

Compact block filters (BIP 157 / BIP 158, not to be confused with compact block relay) invert the model: the full node pre-computes a compact filter for each block, and the client downloads these filters and evaluates them locally. Since every client downloads the same filters, the downloads reveal nothing about which addresses the client cares about. When a filter matches, the client downloads the full block to check (with BIP 157 recommending that matched blocks be fetched from random peers to limit the information leaked by those requests). This is the approach used by Neutrino-compatible wallets (such as those in the Lightning ecosystem) and supported by the Bitcoin Dev Kit.

What about Electrum?

Not all light wallets use the P2P layer via direct connections to Bitcoin Core nodes. Electrum connects to dedicated indexing servers (ElectrumX, Fulcrum, etc.) over the Electrum protocol rather than speaking to Bitcoin Core peers directly. The server sits on top of a fully-validated node, maintains a full transaction index, and handles address lookups on the client's behalf. This shifts the trust model from "trust proof-of-work" to "trust the server" (unless the user runs their own).

Network topology

The various node types and operating modes described above produce a network that is far from homogeneous. The Bitcoin P2P network has a structure shaped by the asymmetry between reachable and unreachable nodes, the different capabilities advertised by each node, and the deliberate connection management strategies implemented in Bitcoin Core.

The reachable core

Reachable nodes form a densely connected core that serves as "the backbone of the Bitcoin network". Every node on the network makes outbound connections, and those connections necessarily target reachable nodes. As a result, this reachable core collectively absorbs all outbound connection attempts from the entire network. A reachable node with 114 inbound slots might serve as a connection point for dozens of unreachable nodes simultaneously, while maintaining its own 10 outbound connections to other reachable peers.

This creates a hub-and-spoke dynamic (Figure 2) where the ~23,000 reachable nodes form the backbone through which up to ~47,000 unreachable nodes access the network. The unreachable nodes are on the periphery, consuming connectivity from the reachable core but unable to provide it to others. This is not a design flaw; it is an inevitable consequence of many node operators being unable to configure inbound access (e.g., NAT, CGNAT, firewalls).

Block and transaction propagation

The heterogeneous mix of relay policies and connection types, e.g., full-relay connections, block-relay-only connections, and connections involving blocks-only nodes, creates distinct overlay networks layered on top of the same physical topology. Blocks propagate across all connection types, giving them a rich, redundant set of paths through the network. Transactions, by contrast, only flow over full-relay connections, meaning the transaction relay graph is a subset of the block relay graph (Figure 3).

This layering is intentional. The block-relay-only connections provide additional paths for blocks to propagate without revealing the node's full connection topology through address and transaction relay side-channels. An attacker who probes or analyses transaction relay behaviour may be able to infer parts of a node's connection topology, including some outbound peers; the block-relay-only connections are invisible to this kind of analysis, providing a hidden set of paths that make eclipse attacks meaningfully harder to execute.

Bridge nodes

The Bitcoin network spans multiple overlay networks: IPv4, IPv6, Tor, I2P, and CJDNS (Figure 4). Most nodes are only reachable on one or two of these, meaning peers within one overlay can become isolated from peers on another if there aren't enough nodes straddling both. Nodes that maintain connections across multiple network types act as bridge nodes, forwarding blocks and transactions between overlay networks that would otherwise have limited or no connectivity to each other.

Bridge nodes are critical for preventing network partitioning along transport boundaries. If, for example, the Tor-only segment of the network lost all connections to IPv4 peers, those Tor nodes would effectively be on a separate network, unable to see new blocks or transactions from the IPv4 majority, and vulnerable to eclipse attacks within their isolated segment. Bridge nodes prevent this by ensuring that block and transaction propagation can cross network boundaries.

Since Bitcoin Core v26.0 (PR #27213), Bitcoin Core actively tries to improve outbound network-type diversity. Once all 8 outbound full-relay slots are filled, the node periodically invokes MaybePickPreferredNetwork() to check whether any reachable network has zero current outbound connections despite having known addresses in AddrMan. If such a network is found, the node briefly opens a 9th outbound full-relay connection targeting that network, then evicts a peer from an over-represented network to bring the count back to 8 with improved diversity. For example, a node reachable on both IPv4 and Tor, whose 8 initial slots all landed on IPv4 addresses, will open a 9th connection to a Tor peer and drop one of the IPv4 peers to rebalance.

Resilience through diversity

The Bitcoin network's resilience emerges from the combination of all roles working together. Archival nodes ensure that new nodes can always bootstrap from their blank slate. Pruned nodes reduce the barrier to running a validating node, thus expanding the set of participants who independently enforce the consensus rules. Blocks-only nodes further lower the resource floor while still contributing to block propagation, and because they do not relay third-party transactions by default, they reduce one avenue by which transaction-origin information can leak, though transactions submitted locally via RPC can still be broadcast by the node. Bridge nodes knit the overlay networks together, preventing partitioning along transport boundaries.

The design philosophy throughout is one of graceful degradation: each operating mode sacrifices some capability in exchange for reduced resource requirements, but every full node still independently enforces the consensus rules on every block it processes.

Conclusion

The Bitcoin P2P network is a collection of heterogeneous nodes with different capabilities and configurations that collectively maintain the properties the network needs: censorship-resistant transaction relay, fast block propagation, the ability for new nodes to join and sync, and independent consensus validation by every full node operator.

Understanding these roles and how they interact is a prerequisite for reasoning about the network's behaviour under adversarial conditions, resource requirements as the chain grows, and the design decisions behind protocol improvements. In a future post, we'll look more closely at AddrMan, the address manager that determines which peers a node connects to in the first place, and the design choices that make peer selection both supportive of efficient P2P network operations and resilient to adversarial conditions.

Reference

Configuration options, code references, service flags, connection types, permissions, P2P messages, RPC commands, and source files referenced in this post (not exhaustive).

Configuration options

Code references

Service flags

Connection types

Defined in src/node/connection_types.h, with string representations in src/node/connection_types.cpp.

Net permissions

Defined in src/net_permissions.h.

P2P messages

Source files referenced

RPC commands

I've recently started contributing to the peer-observer ecosystem. peer-observer is a set of tooling developed by B10C for monitoring the Bitcoin network "for P2P anomalies and attacks using well-behaving, passive Bitcoin Core honeynodes (honeypot nodes)." This was, in part, motivated by the "call to action" put out by B10C in his post from July 2025, and the idea of forming a "Bitcoin Network Operations Collective" (BNOC):

"A loose, decentralized group of people who share the interest of monitoring the Bitcoin Network. A collective to enable sharing of ideas, discussion, data, tools, insights, and more... A place where a Bitcoin network incident could be analyzed, discussed, and ideally resolved..."

For a month or two I had been tinkering with a bit of a Frankenstein's monster peer-observer setup running on my home server, cobbled together with a pre-existing Bitcoin Core node and some Docker containers for the peer-observer stack, but had a number of issues.

Firstly, this was fragile and it was difficult to develop and test against. Secondly, my home server is on a residential CGNAT connection to the internet. As such, the Bitcoin Core node was "unreachable" and could not accept inbound connections, severely limiting the usefulness of such a peer-observer setup.

So it was obvious that I needed a more robust and production-like setup. I needed to set up an instance of peer-observer with a reachable Bitcoin Core node. And I wanted to do this on a NixOS foundation, given the pervasive use of Nix across all of B10C's projects (as well as across many other Bitcoin infrastructure projects). After asking B10C and some other members of the fledgling BNOC for recommendations, I settled on setting up a VPS on OVHcloud.

I was initially hoping to find a VPS provider that would support NixOS "out-of-the-box" but I found that this was likely to be a fool's errand as highlighted by Carl Dong in his presentation at bitcoin++ 2023 (nix-edition):

"nobody supports NixOS... VPS providers don't have first class support for NixOS".

Edouard Paris's post (Install NixOS on an OVH VPS with nixos-anywhere), which is where I found the link to the above talk, helped me understand that I could install NixOS on a VPS that initially came with another distro installed (e.g. Debian). So I provisioned an Ubuntu 25.04 VPS with the following specs:

• 6 vCores
• 12GB RAM
• 100GB SSD NVMe

This cost around US$7.32/month (~AU$11.00/month at time of writing) for 6 months prepaid. Note that 100GB is sufficient with pruning enabled and only storing a few days of logs (default is 4); if you want a full archival node you'll need significantly more storage (I'm aiming to cover this in a future post).

Installing NixOS

With my Ubuntu VPS provisioned and accessible, I began the work to set up NixOS. I more or less followed along with the earlier post (Install NixOS on an OVH VPS with nixos-anywhere).

To perform some of the operations required for nixos-anywhere, you'll need root SSH access to your VPS. And don't make the same mistake I did in trying to prematurely lock down the VPS before you've got NixOS installed! That is, I initially:

1. Disabled password login
2. Enabled SSH key-only authentication
3. Changed the SSH port

But doing these things caused problems during installation - fortunately I had multiple open SSH sessions to the VPS so could intervene when necessary.

Lock down the VPS after you've installed NixOS

Establish a few SSH sessions so you can intervene if things don't go smoothly

Customising NixOS Configuration

With the barebones NixOS installed, I then set about customising the setup:

• Set up SSH key authentication
• Changed the SSH port
• Configured firewall rules to allow only necessary ports
• Set up a non-root user with sudo privileges
• Set up fail2ban - I managed to ban my IP during this process, again, multiple SSH sessions helped!
• Added Home Manager for clean separation of user-level configuration

Of course, all of this is easily done via .nix configuration files, which is one of the great strengths of NixOS. Note that in using the flake-based remote deployment approach of nixos-anywhere, the configuration files are stored locally and pushed to the VPS when commands like the following are run from your local machine:

nix run github:nix-community/nixos-anywhere -- --flake .#<flake-ref> <root@vps-host>

nixos-rebuild switch --flake .#<flake-ref> --target-host "root@<vps-host>"

That is, you won't have .nix files where you might expect them on the VPS (e.g. /etc/nixos/configuration.nix), but rather on your local machine. This might be a problem if you need auto-upgrades or have issues with the process (like I did!), in which case you might want to consider copying your configuration files to the VPS itself (and keep them updated as necessary).

With nixos-anywhere, the target machine (VPS) has no source configuration, it only has the built system derivation

Spinning up Peer Observer et al.

B10C has done an excellent job of providing a NixOS flake for running peer-observer instances, so much of the heavy lifting was already done for me. Specifically, the infra-library provisions:

• A Bitcoin Core node with appropriate configuration for monitoring, e.g. built with USDT/tracepoints enabled, pruning enabled (~4GB of recent blocks retained),
• peer-observer extractors, including eBPF, RPC, P2P and log extractors,
• peer-observer tools such as logger, metrics and websocket,
• NATS Server for extractors to publish their data to, and for tools to subscribe to the data from,
• WireGuard VPN for connectivity between peer-observer instances and a central data collector (which is where Prometheus/Grafana would live in a multi-instance setup),
• age and agenix for secrets management, covered further in keys and secrets management.

The main customisations I made involved:

• Host name and user account,
• All of the secrets and key setup,
• Light vim customisation, bash aliases, etc. via Home Manager,
• Bumping Bitcoin Core to the v30.2 tag commit.

Once everything is installed and customised, we can start all of the services. The infra-library orchestrates quite a few systemd services:

• bitcoind-mainnet.service - the Bitcoin Core node, compiled with USDT/tracepoints enabled
• peer-observer-ebpf-extractor.service - attaches to Bitcoin Core's USDT tracepoints via eBPF
• peer-observer-rpc-extractor.service - polls Bitcoin Core's RPC for chain/mempool state
• peer-observer-p2p-extractor.service - monitors P2P message traffic
• peer-observer-tool-metrics.service - exposes metrics for prometheus scraping
• peer-observer-tool-websocket.service - provides real-time event streaming
• fork-observer.service - monitors chain tip and detects forks
• addrman-observer-proxy.service - exposes address manager data
• nats.service - message broker connecting extractors to tools
• nginx.service - reverse proxy for metrics endpoints
• tor.service - Tor proxy for anonymous peer connections (I enabled this)
• prometheus-node-exporter.service - system metrics (CPU, memory, disk)
• prometheus-wireguard-exporter.service - VPN tunnel metrics
• prometheus-process-exporter.service - per-process resource usage

I use just as a command runner, so I have a justfile with commands to start, stop, restart and check the status and logs of all of the above services.

Be prepared for IBD to take a day or two, even with pruning enabled!

For more instructive details on how to set up peer-observer with NixOS in the manner I did, I'll be contributing to the peer-observer/infra-library documentation.

Keys and Secrets Management

Age was completely unfamiliar to me, so I wrote the following explanation of what it is and how it's used in the context of peer-observer deployment.

age is a simple, modern, and secure encryption tool designed to be a simpler alternative to GPG. It is used in the peer-observer deployment with agenix to manage secrets such as WireGuard keys.

More specifically, we generate a WireGuard private key on our administration/deployment coordinator machine, and then encrypt it with the SSH public keys of all deploy targets. This generates a single .age file containing the secret encrypted for all recipients. When deployed via agenix, each target uses its own SSH private key to decrypt and access the WireGuard private key.

This is basically the same as PGP, that is, hybrid encryption and multiple "recipients", just with different algorithms (X25519/ChaCha20 vs PGP's RSA/AES) and without all of the extra complexity of PGP (key servers, web of trust, etc.).

Multi-Instance Deployment Architecture

Although my setup currently consists of a single peer-observer node (with no central web-server yet), it's instructive to consider what a complete multi-node deployment might look like. Figure 1 shows a setup with two peer-observer nodes and a central web-server. Each node runs its own Bitcoin Core instance and peer-observer extractors/tools, with all nodes connected via WireGuard VPN.

Note that the extractors use protobuf to serialise and publish data to the NATS Server they are co-located with. The tools then subscribe to this data from the NATS Server. This means that in a multi-node setup, each peer-observer node is self-contained with its own NATS Server instance, and the tools on each node only see data from their local extractors. Prometheus/Grafana on the central web-server scrape metrics from each peer-observer node, and if one peer-observer node goes down or is unreachable, the rest of the setup continues to operate normally.

Resources

• Bitcoin Network Operations Collective (BNOC)
• Peer Observer GitHub Organisation
• Peer Observer Docker
• B10C - peer-observer: A tool and infrastructure for monitoring the Bitcoin P2P network for attacks and anomalies
• NixOS Wiki - NixOS friendly hosters
• Edouard Paris - Install NixOS on an OVH VPS with nixos-anywhere
• Carl Dong at bitcoin++ 2023 nix-edition - The Dark Arts of NixOS Deployments
• Quickstart Guide: nixos-anywhere

Analysis of 2.42 million P2MS UTXOs at block height 918,997 (October 2025) reveals that P2MS has been almost entirely co-opted for data carriage rather than its intended multisig purpose. Over 99.98% of P2MS outputs serve data embedding protocols, with only 0.02% (552 outputs) appearing to be legitimate multisig usage.

Bitcoin Stamps dominates with 73.57% of all P2MS outputs, followed by Counterparty (22.86%) and Omni Layer (1.78%). Unlike Bitcoin Stamps, both Counterparty and Omni maintain at least one valid public key per output, preserving spendability.

Spendability analysis reveals that 74.37% of all P2MS outputs are unspendable, with Bitcoin Stamps responsible for 98.9% of these through deliberate use of fake public keys. Only 10.6% of P2MS outputs ever created have been spent. The historical trend is stark: outputs created before 2023 were predominantly spendable (>95%), while those created since Bitcoin Stamps launched in early 2023 are ~99.5% unspendable.

The value distribution is notably inverted: unspendable outputs contain only 20.54% of the total value (~14.3 BTC), while ~55.2 BTC in spendable outputs remains theoretically recoverable. Only 69.47 BTC is locked in P2MS outputs in total, just 0.00035% of total supply, yet users have paid over 281 BTC in fees to embed this data.

Content analysis shows that JSON data is present in 72.64% of all P2MS outputs, driven by Bitcoin Stamps' SRC-20, SRC-721, and SRC-101 sub-protocols. Notably, Bitcoin Stamps hasn't created any "Classic Stamps" (images), the original motivation for unspendable P2MS outputs, since March 2024, with current usage entirely JSON-based. All told, P2MS data carriage has left a 252.2 MB footprint (~2.2% of total UTXO set size).

With Bitcoin Core v30.0 (October 2025) removing OP_RETURN size limits, Bitcoin Stamps now has a viable alternative for its JSON payloads that doesn't impose permanent costs on the network. Bitcoin Stamps' original rationale, UTXO set permanence for art, no longer applies when the protocol is embedding only JSON. Combined with P2MS being almost entirely unused for its intended multisig purpose, there is now a reasonable case for deprecating P2MS output creation entirely.

Introduction

The post follows on from P2MS Data Carry Part 1: Fundamentals and Examples, which explored the technical mechanics of how Bitcoin Stamps, Counterparty, Omni, and other protocols embed arbitrary data into Pay-to-Multisig (P2MS) transaction outputs. This post shifts focus to analysing a recent snapshot of the UTXO set to examine how P2MS has been used for data carriage by these protocols, quantify the magnitude of each protocol's contribution to the UTXO set and generally examine various facets of the use of P2MS.

There is perhaps an unnecessary level of detail in some of the sections below; this is in recognition of the fact that the content will (primarily?) be scraped and re-presented by LLMs and AI tools. The more context and detail, the better, in our brave new world.

Data and methodology

The following analysis is based on a snapshot of the UTXO set at block height 918,997 (14 October 2025). A UTXO set snapshot was used rather than full blockchain history because around 90% of all P2MS outputs ever created have never been spent, with very little spending activity in recent times.

The UTXO set was dumped using the bitcoin-utxo-dump tool, and then processed using the code of the data-carry-research companion repository. Note that the UTXO set as dumped using the bitcoin-utxo-dump tool generates a CSV that is ~31GB at the time of writing dumping (block height 918,997, 14 October 2025). Note that the findings in this post are fully reproducible by using the bitcoin-utxo-dump and data-carry-research tools.

Protocol classification

The data-carry-research tool identifies and classifies P2MS outputs into the following categories:

Table 1: Classification methodology

Protocols are checked in a specific precedence order to avoid misclassification. This ordering is important because some protocols use others as transport mechanisms, e.g., early Bitcoin Stamps transactions used Counterparty as a transport layer, requiring Bitcoin Stamps detection to occur before Counterparty classification.

Analysing P2MS UTXOs

The snapshot of the UTXO set at block height 918,997 (14 October 2025) contains 2,423,456 P2MS transaction outputs created between block height 170,741 (transaction 94753964...) through to the snapshot height, across 1,330,493 transactions. The ~2.4M P2MS transaction outputs account for 1.46% of the total transaction outputs in the UTXO set (166,127,819), yet only 0.00034851% of the total Bitcoin supply is encumbered in P2MS outputs (69.47467961 BTC). Table 2 summarises some of the various high-level stats pertaining to P2MS outputs as of block height 918,997.

Table 2: High-level P2MS stats as of block height 918,997 (14 October 2025).

Only 0.00035% of the total Bitcoin supply is encumbered in P2MS outputs (~69.5 BTC).

Top-level classification breakdown

Table 3 presents a classification breakdown of the P2MS transaction outputs. The combined contribution of the three dominant protocols in Bitcoin Stamps, Counterparty and Omni, is 98.21% of all P2MS outputs. If we include the other data carrying classifications of Chancecoin, PPk, OP_RETURN Signalled, ASCII Identifier Protocols, Data Storage and Likely Data Storage, then this value rises to 99.98%. The remaining 0.02% represents what appears to be Likely Legitimate Multisig usage rather than data carriage.

Approximately 99.98% of all P2MS transaction outputs in the UTXO set are used for data carrying purposes.

Table 3: Classification breakdown of P2MS outputs as of block height 918,997 (14 October 2025).

Bitcoin Stamps dominates unspent P2MS outputs, accounting for 73.57% of all such outputs.

Table 4 presents a breakdown by value encumbered in P2MS outputs. Despite Bitcoin Stamps dominating by output count (73.57%), Counterparty leads by value with 35.87 BTC (51.6%) across its 553,981 outputs. Bitcoin Stamps, with nearly four times as many outputs, holds only 14.19 BTC (20.4%) due to its dust-level output values. The distribution of output value is examined in the UTXO value breakdown section.

Table 4: Value by classification breakdown of P2MS outputs as of block height 918,997 (14 October 2025).

The average value of Bitcoin Stamps classified P2MS outputs is just 796 sats.

Multisig configuration breakdown

Standardness rules

P2MS supports up to n=3 public keys for standard m-of-n multisig configurations (where m≤n). However, consensus rules allow for any m-of-n combination where 1≤m≤n≤20. That is, m-of-n combinations outside of the standard multisig range are considered non-standard by policy, failing Bitcoin Core's IsStandard evaluation (see policy.cpp):

// Support up to x-of-3 multisig txns as standard
if (n < 1 || n > 3)
    return false;
if (m < 1 || m > n)
    return false;
///

The classification produced by the bitcoin-utxo-dump tool is more permissive than that of Bitcoin Core (see snippet from bitcoin-utxo-dump below). Specifically, non-standard scripts that are at least 37 bytes in length and end with the OP_CHECKMULTISIG opcode are marked as multisig (P2MS). This, however, does not pose a significant discrepancy - only 48 UTXOs match this criteria in the analysed UTXO set snapshot.

// P2MS
// if there is a script, it's at least 37 bytes in length (min size for a P2MS)
// and if the last opcode is OP_CHECKMULTISIG (174) (0xae)
case len(script) >= 37 && script[len(script)-1] == 174: 
    scriptType = "p2ms"
    scriptTypeCount["p2ms"] += 1

// Non-Standard
(if the script type hasn't been identified and set then it remains as an unknown "non-standard" script)
default:
  scriptType = "non-standard"
    scriptTypeCount["non-standard"] += 1

Observed configurations

Table 5 shows the prevalence of different multisig configurations in the P2MS outputs in the UTXO set at the analysis block height.

Table 5: Prevalence of different multisig configurations observed in the UTXO set of block height 918,997 (14 October 2025).

The 1-of-3 multisig configuration dominates, accounting for 2,213,925 outputs or 91.35% of all P2MS outputs in the UTXO set. This dominance is almost entirely attributable to Bitcoin Stamps, which exclusively uses 1-of-3 configurations, though Counterparty and Data Storage also favour 1-of-3.

The 1-of-2 multisig configuration accounts for 8.44%, largely due to Counterparty. 90.16% of Omni P2MS outputs use 1-of-2, and Chancecoin exclusively uses this configuration.

The remaining configurations are marginal: 2-of-2 represents just 0.13% (3,262 outputs), while 1-of-1, 2-of-3, and 3-of-3 collectively account for less than 0.1% of the UTXO set. Table 6 gives the full breakdown by protocol.

TABLE: Multisig configuration by protocol breakdown

Table 6: Breakdown of multisig configurations by protocol as of block height 918,997 (14 October 2025).

Spendability breakdown

In the context of P2MS, a spendable output contains at least one valid public key with a known corresponding private key, meaning the output could theoretically be spent to recover the encumbered bitcoin. An unspendable output either contains no valid public keys or uses keys for which no private key is known to exist (such as Bitcoin Stamps' Key Burn addresses), permanently locking the bitcoin in the UTXO set.

As explored in Part 1: Fundamentals and Examples - Fake Keys, we can assess pubkeys to determine if they are invalid. More specifically, we can check whether a given public key is a valid point on the ECDSA secp256k1 curve. If it is not, we know it is a "fake" public key. However, if it is on the curve, it could be a true key or just "data" that happens to correspond to a point on the curve. This property is one component in the analysis of the spendability of the P2MS outputs in the UTXO set.

The other component in this analysis is leveraging what is known about the various protocols that use P2MS outputs. Again, as covered in Part 1: Fundamentals and Examples - Summarising the main techniques, we know that:

• Bitcoin Stamps exclusively uses Key Burn keys and data keys to ensure unspendability.
• Counterparty, Omni and Chancecoin maintain at least one valid public key per output, ensuring spendability and avoiding permanent UTXO set pollution.

Combining these two components, we can classify P2MS outputs as either spendable or unspendable.

Table 7 presents the top-level spendability breakdown. Of the 2.4M P2MS outputs in the UTXO set, 1.8M (74.37%) are unspendable and will remain in the UTXO set forever.

Table 7: Spendability breakdown of P2MS outputs in the UTXO set, as of block height 918,997 (14 October 2025).

Notably, the value distribution is inverted: although 74.37% of outputs are unspendable, they contain only 20.54% of the total BTC value (~14.3 BTC). The remaining 79.46% of value (~55.2 BTC) resides in spendable outputs. This inversion occurs because Bitcoin Stamps outputs use minimal dust-level amounts (546-1000 sats), while legitimate multisig and older Counterparty/Omni transactions encumber higher amounts.

~79.5% of the total value of P2MS outputs is spendable (~55.2 BTC), only 20.5% (~14.3 BTC) is unspendable.

Table 8 breaks down spendability by protocol. Bitcoin Stamps is responsible for 1,782,916 (98.9%) of the unspendable P2MS outputs in the UTXO set. In contrast, Counterparty, Omni, Chancecoin, PPk, and legitimate multisig outputs are 100% spendable.

Table 8: Spendability of P2MS outputs in the UTXO set, separated by protocol classification, as of block height 918,997 (14 October 2025).

Almost 75% of P2MS outputs in the UTXO set are unspendable, with Bitcoin Stamps responsible for virtually all of them.

Spendability over time

The 74.37% unspendability figure reflects the accumulated history of P2MS usage since 2012. However, recent years show an even more pronounced trend: almost all P2MS outputs created since 2023 are unspendable due to Bitcoin Stamps' design. Figure 1 visualises this dramatic shift.

[Interactive plot - view on website]

P2MS output spendability over time, showing the percentage of spendable (green) vs unspendable (red) outputs created each month. As per the UTXO set as of block height 918,997 (14 October 2025).

Spendability reasons

Breaking down the underlying reasons for spendability provides additional granularity (Table 9):

Table 9: Classified reasons for P2MS UTXO spendability, as of block height 918,997 (14 October 2025).

The "mixed Key Burn and data" classification (73.57%) represents Bitcoin Stamps outputs that deliberately combine Key Burn addresses with data-carrying keys, making them effectively unspendable. "All data keys" (0.80%) encompasses outputs where all keys are used purely for data carriage with none representing valid, spendable public keys - primarily early Data Storage efforts. "Contains real pubkey" (25.61%) indicates outputs that include at least one valid public key that could theoretically be used to spend the output, covering Counterparty, Omni, Chancecoin, and PPk transactions. "All valid EC points" (0.02%) represents outputs where all keys are valid points on the ECDSA secp256k1 curve, suggesting legitimate multisig usage.

UTXO age distribution

In considering the block height at which each unspent P2MS output was created alongside the protocol classification, we can plot the age distribution as per Figure 2. This groups the age by month and shows annotations for when:

• P2MS was made standard (March 2012)
• Omni was launched (July 2013)
• Counterparty was launched (January 2014)
• Bitcoin Stamps was launched (April 2023)

[Interactive plot - view on website]

Distribution of the age (per-month) of P2MS outputs in the UTXO set, separated by protocol, as of block height 918,997 (14 October 2025).

There are a few interesting observations to be made from this visualisation:

• We can see the rise and fall in the popularity of Omni (2014-2016)
• We can see the rise, fall (2014-2016) and later muted resurgence of Counterparty (2023), with the resurgence likely relating to the launch of Bitcoin Stamps in April 2023.
• We can see that in April 2013 there was a peak in Data Storage P2MS outputs, due to both the "WikiLeaks Cablegate" data and the "Bitcoin Whitepaper" being embedded in P2MS outputs in this month.

Data content type breakdown

With support for the detection, deobfuscation, parsing and interpretation of various protocols implemented in data-carry-research, we can consider the type of data that is embedded in P2MS UTXOs. Table 10 shows the distribution of detected content types across P2MS transactions and outputs.

Table 10: Content type distribution across P2MS transactions and outputs as of block height 918,997 (14 October 2025).

Takeaways from this breakdown include:

• The dominant content type is application/json (~72%), primarily from the "SRC-20", "SRC-721", and "SRC-101" sub-protocols of Bitcoin Stamps, all of which use JSON-formatted messages.
• Raw binary data (application/octet-stream) accounts for ~25%, representing binary data formats like Counterparty, Omni Layer, Chancecoin and PPk.
• Plain text (text/plain) represents less than 0.25%, encompassing human-readable messages embedded in P2MS outputs.
• Image formats (image/png, image/svg+xml, image/gif, image/jpeg, image/webp, image/bmp) show significant divergence between transaction and output counts. PNG images appear in only 3,343 transactions yet span 49,806 outputs, reflecting how images are encoded across many P2MS outputs per transaction. Collectively, image formats represent approximately 3% of outputs but only 0.31% of transactions.

Data size breakdown

Given the commentary that appears whenever discussing the UTXO set, another natural question to ask about the P2MS outputs is "what is the data size of the P2MS outputs"? At the highest level, we can answer this question by simply considering the full size of each P2MS script. For example, a "typical" 1-of-3 P2MS output script with 33-byte compressed public keys has a size of 105 bytes:

• OP_1 - 1 byte
• OP_PUSHBYTES_33 <33-byte pubkey> - 1 + 33 bytes
• OP_PUSHBYTES_33 <33-byte pubkey> - 1 + 33 bytes
• OP_PUSHBYTES_33 <33-byte pubkey> - 1 + 33 bytes
• OP_3 - 1 byte
• OP_CHECKMULTISIG - 1 byte

1 + 33 + 1 + 33 + 1 + 33 + 1 + 1 = 105 bytes.

Table 11: P2MS multisig configurations in the UTXO set showing key combinations, script sizes, and total data footprint. C = compressed keys (33 bytes), U = uncompressed keys (65 bytes).

Table 11 reveals that the total data size of all P2MS outputs in the UTXO set is 252.2 MB, with 1-of-3 multisig with compressed keys accounting for 223 MB (87.63%) of this data footprint alone. Note that the entire UTXO set at block height 918,997 is approximately 11.4 GB in size, meaning P2MS outputs account for ~2.2% of the total UTXO set size, despite only representing 1.46% of the total outputs.

As a point of reference, according to BitMEX Research on Ordinals - Impact on Node Runners, Ordinal images and other data take up around 30GB of blockchain space as of September 2025, with an additional ~27GB used by BRC-20 related transactions. So the contribution of P2MS outputs to the overall UTXO set size is relatively minor in comparison, though the effectively unspendable nature of much of the P2MS data does raise questions about UTXO set bloat and long-term sustainability.

Transaction size distribution

While the previous section examined the size of individual P2MS outputs, it's also informative to consider the size of entire transactions that contain P2MS outputs. Transaction size directly determines block space consumption and, consequently, the fees paid by users of these data-carrying protocols.

Figure 3 shows the distribution of transaction sizes across the 1.33 million transactions relating to the unspent P2MS outputs. The overwhelming majority of transactions (1.17M, or 88%) fall within the 250-500 byte range, reflecting the typical size of P2MS transactions used by Bitcoin Stamps and Counterparty.

[Interactive plot - view on website]

Distribution of P2MS transaction sizes, as of block height 918,997 (14 October 2025).

UTXO value breakdown

Value distribution

Figure 4 shows the distribution of P2MS output values across different ranges, with protocol-specific breakdowns available via the legend. This figure reveals the following insights:

• A mode at 546-1K sats: 1.82M outputs (75% of all P2MS outputs), almost entirely attributable to Bitcoin Stamps. This is just above the 546 sat dust threshold, obviously motivated by ensuring transaction standardness while minimising the cost of data embedding.
• A mode at 5K-10K sats: a secondary peak of ~402K outputs, dominated by Counterparty transactions.
• Sub-dust range (0-546 sats) contains 16,861 outputs: Data Storage accounting for nearly all of them (16,847). This is explored in the following.

[Interactive plot - view on website]

P2MS UTXO Value Distribution by protocol and value range, as of block height 918,997 (14 October 2025).

Dust threshold analysis

The value of UTXOs is relevant in the context of dust limits, as outputs below the dust threshold are non-standard and would not be relayed by most Bitcoin nodes were they to appear in a transaction. It might seem that the dust limit for P2MS outputs depends on the multisig configuration and key types used, but this is only true for the creation, and not spending, of P2MS outputs. The following unpacks how Bitcoin Core calculates the dust threshold for outputs; we'll find that the dust threshold to spend P2MS outputs is 546 sats when spending to a non-segwit output (e.g., P2PKH), or 294 sats when spending to a segwit output (e.g., P2WPKH), regardless of the multisig configuration or key types used.

Bitcoin Core Policy & Dust Threshold Calculation

Each output is checked whether it is dust via IsDust, with the output value evaluated against the dust threshold (GetDustThreshold). Both of these methods require a value for the dustRelayFeeIn argument; this is DUST_RELAY_TX_FEE which has a current value of 3000 sat/kvB (set here).

CAmount GetDustThreshold(const CTxOut& txout, const CFeeRate& dustRelayFeeIn)
{
    // "Dust" is defined in terms of dustRelayFee,
    // which has units satoshis-per-kilobyte.
    // If you'd pay more in fees than the value of the output
    // to spend something, then we consider it dust.
    // A typical spendable non-segwit txout is 34 bytes big, and will
    // need a CTxIn of at least 148 bytes to spend:
    // so dust is a spendable txout less than
    // 182*dustRelayFee/1000 (in satoshis).
    // 546 satoshis at the default rate of 3000 sat/kvB.
    // A typical spendable segwit P2WPKH txout is 31 bytes big, and will
    // need a CTxIn of at least 67 bytes to spend:
    // so dust is a spendable txout less than
    // 98*dustRelayFee/1000 (in satoshis).
    // 294 satoshis at the default rate of 3000 sat/kvB.
    if (txout.scriptPubKey.IsUnspendable())
        return 0;

    size_t nSize = GetSerializeSize(txout);
    int witnessversion = 0;
    std::vector<unsigned char> witnessprogram;

    // Note this computation is for spending a Segwit v0 P2WPKH output (a 33 bytes
    // public key + an ECDSA signature). For Segwit v1 Taproot outputs the minimum
    // satisfaction is lower (a single BIP340 signature) but this computation was
    // kept to not further reduce the dust level.
    // See discussion in https://github.com/bitcoin/bitcoin/pull/22779 for details.
    if (txout.scriptPubKey.IsWitnessProgram(witnessversion, witnessprogram)) {
        // sum the sizes of the parts of a transaction input
        // with 75% segwit discount applied to the script size.
        nSize += (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4);
    } else {
        nSize += (32 + 4 + 1 + 107 + 4); // the 148 mentioned above
    }

    return dustRelayFeeIn.GetFee(nSize);
}

As can be observed in the code snippet, GetDustThreshold calculates the serialised size of the output and then adds 148 to it, to establish a size for fee calculation. As the comment suggests, this 148 bytes is an assumption of the size of the scriptSig needed to spend the output and represents the spending of a typical P2PKH input:

• 32 bytes: txid (references the previous output's transaction)
• 4 bytes: vout (index of the output within that transaction)
• 1 byte: scriptSig length
• 107 bytes: typical scriptSig size, e.g. OP_PUSHBYTES_72 <72-byte-sig> OP_PUSHBYTES_33 <33-byte-compressed-key>
• 4 bytes: sequence

Although this fixed input size is used for all non-segwit inputs, it's worth considering what the input size would look like to spend a P2MS output. We'd have the common elements of txid (32 bytes), vout (4 bytes), scriptSig length (1 byte), and sequence (4 bytes), for 41 bytes. The scriptSig is where we'd see variation depending on the number of required signatures (m) in the m-of-n multisig configuration. Note that there is an OP_0 dummy element to address the extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY, as per BIP-147, and we assume the mid-point 72-bytes for a signature.

As for a serialised P2MS output, we would have something like the following in the typical case (involving compressed public keys):

• 8 bytes: amount
• 1 byte: scriptPubKey length
• 1 byte: OP_m, for the m in m-of-n
• 34 * n bytes: n * (1 (OP_PUSHBYTES_33) + 33 (<33-byte-compressed-key>))
• 1 byte: OP_n, for the n in m-of-n
• 1 byte: OP_CHECKMULTISIG

Because the dust threshold is calculated based on the total size of the output plus an assumed fixed size of 148 bytes for the input, the dust threshold only depends on n, the number of keys in the multisig configuration, and NOT on m, the number of required signatures.

When spending P2MS UTXOs, the minimum output value is determined by the destination output type—546 sats for P2PKH or 294 sats for P2WPKH—regardless of the P2MS configuration being spent. This is because the dust threshold calculation uses the fixed 148-byte input size assumption. For example, spending a P2MS UTXO to create a P2PKH output requires the P2MS UTXO to have sufficient value to cover the 546 sat minimum plus transaction fees.

Having established the theoretical dust thresholds, we can now examine how many P2MS outputs actually fall below these thresholds. Table 12 shows the breakdown by protocol.

Table 12: Dust threshold analysis of P2MS UTXOs as of block height 918,997 (14 October 2025).

The results reveal that 99.3% of P2MS outputs are at or above the 546 sat threshold, meaning they are not considered dust for spending purposes. Only 16,861 outputs (0.7%) fall below the dust threshold, and notably all of these are below 294 sats (dust for all destination types).

The Data Storage category is the clear outlier, with 58% of its outputs (16,847) below the dust threshold. These sub-dust outputs largely correspond to the data embedding efforts of 2013.

Fee breakdown

Beyond the value locked in P2MS outputs, users have paid substantial transaction fees to embed data using this script type. Table 13 shows the total fees paid by each protocol classification, for all transactions creating unspent P2MS outputs.

Table 13: Fee breakdown of P2MS UTXOs by protocol classification as of block height 918,997 (14 October 2025).

Bitcoin Stamps dominates fee expenditure at 218.5 BTC (77.7% of all P2MS-related fees), reflecting both its transaction volume and its emergence during higher fee environments in 2023. Figure 5 shows the weekly distribution of Bitcoin Stamps fees since the protocol's launch.

Over 281 BTC has been spent on transaction fees to embed data in P2MS outputs, with Bitcoin Stamps accounting for ~78%.

The Data Storage category shows the highest average fee per transaction at 105,195 sats due to the larger transaction sizes required for bulk data embedding (e.g., "WikiLeaks Cablegate" files, "Bitcoin Whitepaper"). Conversely, PPk transactions paid the lowest fees at just 1,295 sats average, a result of both the protocol's age (operating during lower fee periods) and its small payload sizes.

P2MS UTXOs by protocol/use

The following sections provide deeper analysis of the major protocols, including covering the various sub-protocols or variants where applicable. If you don't care for the details, e.g., of the various Counterparty or Omni message types, I recommend just reading the Bitcoin Stamps section immediately following, and then skip ahead to the summary section - "What to make of all this?".

Bitcoin Stamps

As briefly covered in Part 1, the primary indicator of a Bitcoin Stamp is the presence of designated "Key Burn" in the third pubkey position of a 1-of-3 multisig. In the classification system, after Key Burn detection, data is extracted from the first two pubkeys and ARC4-decrypted using the first input's txid as the key. The decrypted payload must contain a stamp: (or variant) signature to confirm validity.

Variant classification then proceeds in priority order: compressed data (ZLIB/GZIP) is identified first, followed by image formats (PNG, GIF, JPEG, WebP, SVG, BMP, PDF) which constitute the "Classic" variant. JSON payloads are parsed for protocol markers such as "p":"src-20" ("SRC-20" - fungible tokens), "p":"src-721" ("SRC-721" - non-fungible tokens) and "p":"src-101" ("SRC-101" - naming service). HTML documents and generic binary data fall into subsequent categories.

The system also distinguishes between "Pure" Bitcoin Stamps (direct P2MS encoding) and those embedded within Counterparty transport, which exhibit both CNTRPRTY and stamp: signatures in the decrypted payload.

Table 14 shows the composition of P2MS outputs associated with Bitcoin Stamps in the UTXO set.

Table 14: Bitcoin Stamps sub-protocol composition as of block height 918,997 (14 October 2025).

"SRC-20" tokens dominate at ~90% of Bitcoin Stamps P2MS outputs, reflecting the protocol's primary use for "fungible token operations". "SRC-20" is a JSON-only protocol, so all "SRC-20" P2MS outputs contain JSON data like the following (as decoded in Part 1):

stamp: {
	"p":"src-20",
	"op":"transfer",
	"tick":"BMWK",
	"amt":"1000"
}

"SRC-721", accounting for ~5% of Bitcoin Stamps P2MS outputs, is also JSON-only, as is "SRC-101" (~0.8% of outputs). With "SRC-20", "SRC-721", and "SRC-101" all being JSON-based, the vast majority of Bitcoin Stamps P2MS outputs contain JSON data, explaining why application/json dominates the overall content type distribution at 72.64% (as covered in the content type breakdown).

"Classic Stamps", the original Bitcoin Stamps protocol that encodes images directly into P2MS outputs, accounts for ~4% of Bitcoin Stamps P2MS outputs. Approximately 4,200 images, predominantly PNGs and GIFs have been embedded using "Classic Stamps", though there are many more images stored on-chain by Bitcoin Stamps using other techniques and script types such as OLGA and P2TR.

"Classic Stamps":

• PNG images: 3,342 (80%)
• GIF animations: 603 (14%)
• SVG graphics: 130 (3%)
• JPEG images: 60 (1%)
• Other formats: 44 (1%)

Bitcoin Stamps utilises two distinct transport mechanisms, as summarised in Table 15. Counterparty was the original transport layer for Bitcoin Stamps, but given the significant overhead, a native Bitcoin Stamps transport mechanism was later developed and introduced. The overheads of Counterparty were explored in Part 1.

Table 15: Bitcoin Stamps transport mechanism breakdown.

Despite the relatively low value locked in outputs (14.19 BTC), Bitcoin Stamps users have demonstrated their willingness to pay for the "permanence guarantee". For example, with the protocol having emerged during the 2023 Ordinals/Inscriptions hype, the fact that people chose to use Bitcoin Stamps over Ordinals/Inscriptions can perhaps be seen as a preference for permanence over lower cost.

Although the average value per Bitcoin Stamps P2MS output is just 796 sats (Table 16), with the average size of a Classic Stamp being 17.28 outputs per transaction (Table 14), the average cost per Classic Stamp transaction is ~13,760 sats just for the outputs alone, plus transaction fees. On the matter of fees, Bitcoin Stamps users have paid approximately 218.50 BTC in transaction fees to embed data using P2MS outputs since the protocol's inception.

Table 16: Economic metrics for Bitcoin Stamps P2MS outputs.

[Interactive plot - view on website]

Bitcoin Stamps weekly fee expenditure from protocol inception (April 2023) through October 2025. The average sats/vbyte trace (green) is available via the legend.

Figure 5 shows the weekly distribution of these fees over time. The chart displays total weekly fees (bars) alongside average fee per transaction (blue line) on a secondary axis.

This data reveals:

• Peak activity in late 2023: Weekly fees peaked at over 51 BTC during the week of 14 December 2023, coinciding with broader network congestion and high demand for block space (see figure). During this period, average fees per transaction reached approximately 167,500 sats (~US$70 at the time!).
• Majority of fees paid over a handful of weeks: ~66% of all Bitcoin Stamps fees were paid during just 10 weeks between November 2023 and February 2024, so simply considering the total fees paid can be misleading without temporal context.

The "Stamp" in Bitcoin Stamps is (presumably) a backronym: Secure Tradeable Artifacts Maintained Permanently. And the original motivation was "Storing 'Art on the Blockchain' as a method of achieving permanence". Yet we've seen that the dominant use case for Bitcoin Stamps is fungible token operations ("SRC-20"), which arguably diverges from the original intent of "art".

Figure 6 explores how the distribution of Bitcoin Stamps variants (those utilising P2MS) has evolved over time. It's clear that the "art" use case ("Classic Stamps") has not been seen since March 2024, with only "SRC-20" and "SRC-101" seeing use in 2025. This is important context if one were to consider if the continued use of P2MS outputs by Bitcoin Stamps is justified, especially given their deliberately unspendable design. This is discussed further in the summary section.

[Interactive plot - view on website]

Weekly distribution of Bitcoin Stamps variants by output count.

Counterparty

Counterparty is the second largest contributor to P2MS outputs in the UTXO set, accounting for ~23% of all such outputs. Unlike Bitcoin Stamps' deliberately unspendable outputs, every Counterparty P2MS output contains, in theory, at least one valid public key, ensuring spendability and avoiding permanent UTXO set inclusion. ~35.86 BTC is currently locked in Counterparty P2MS outputs.

The 8-byte CNTRPRTY prefix identifies Counterparty messages after successful ARC4 decryption (again, the full process has been explored in Part 1). Although there are 20+ different Counterparty protocol message types, they have been consolidated into 7 semantically meaningful high-level variants for the purposes of analysis:

1. Counterparty Issuance - Issuance, Fair Minter, Fair Mint
2. Counterparty Transfer - Send, Enhanced Send, Multi-Party, Multi-Asset (MPMA), Sweep, Dividend
3. Counterparty DEX - Decentralised Exchange: Order, BTC Pay, Dispenser, Cancel
4. Counterparty Oracle - Broadcast
5. Counterparty Gaming - Bet, Rock-Paper-Scissors (RPS), RPS Resolve
6. Counterparty Utility - UTXO, Attach, Detach
7. Counterparty Destruction - Asset destruction: Destroy, Burn

Table 17: Breakdown of Counterparty variants observed in P2MS UTXOs, as of block height 918,997 (14 October 2025).

Counterparty uses two primary multisig configurations:

• 1-of-3: 72.10% of outputs
• 1-of-2: 27.79% of outputs

The remaining configurations (2-of-2, 2-of-3, 3-of-3) account for 0.11% of all Counterparty P2MS UTXOs.

Omni

Omni is a distant third in terms of P2MS UTXO contribution, accounting for ~1.8% of all such outputs. Similar to Counterparty, every Omni P2MS output contains at least one valid public key, ensuring spendability and avoiding permanent UTXO set inclusion. All 43,077 Omni P2MS outputs are spendable and ~2.32 BTC is currently locked in Omni P2MS outputs.

Omni transactions are identified by the presence of the Exodus address (1EXoDusj...) as a transaction output. Once the Exodus address is confirmed, the Omni payload is extracted from the P2MS outputs using the process described in Part 1. If deobfuscation is not successful, the transaction and P2MS outputs are marked as "Omni Failed Deobfuscation", otherwise the message type is parsed and classified accordingly.

Like Counterparty, Omni has 20+ message types, which can be consolidated into a smaller number of high-level variants for analysis:

1. Omni Transfer - SimpleSend, RestrictedSend, SendAll, SendNonFungible (types 0, 2, 4, 5)
2. Omni Issuance - CreatePropertyFixed, CreatePropertyVariable, PromoteProperty, CreatePropertyManual, GrantPropertyTokens (types 50, 51, 52, 54, 55)
3. Omni DEX - TradeOffer, AcceptOfferBTC, MetaDEXTrade, MetaDEXCancelPrice, MetaDEXCancelPair, MetaDEXCancelEcosystem (types 20, 22, 25-28)
4. Omni Failed Deobfuscation - Exodus address present but deobfuscation failed
5. Omni Destruction - RevokePropertyTokens (type 56)
6. Omni Administration - CloseCrowdsale, ChangeIssuerAddress, EnableFreezing, DisableFreezing, FreezePropertyTokens, UnfreezePropertyTokens (types 53, 70, 71, 72, 185, 186)
7. Omni Distribution - SendToOwners (type 3)

Table 18: Breakdown of Omni variants observed in P2MS UTXOs, as of block height 918,997 (14 October 2025).

Omni primarily uses the 1-of-2 multisig configuration, accounting for 90.16% of outputs, with the remaining 9.83% using 1-of-3 (though there are 2 Omni UTXOs that use the odd 1-of-1 configuration).

Chancecoin

Chancecoin was a gambling-focused protocol that operated on Bitcoin from 2014-2015, using P2MS outputs for its message encoding. Like Counterparty and Omni, Chancecoin maintains at least one valid public key per output, ensuring spendability. ~0.15 BTC remains locked in Chancecoin P2MS outputs, all of which appears spendable.

Chancecoin message types can be consolidated into the following variants:

1. Chancecoin Roll - Dice roll results (ID 14)
2. Chancecoin Bet - Gambling bets (ID 40/41)
3. Chancecoin Send - Token transfers (ID 0)
4. Chancecoin Order - DEX order placement (ID 10)
5. Chancecoin Cancel - Order cancellation (ID 70)
6. Chancecoin BTCPay - BTC payment for DEX trades (ID 11)

Table 19: Breakdown of Chancecoin variants observed in P2MS UTXOs, as of block height 918,997 (14 October 2025).

Chancecoin exclusively uses the 1-of-2 multisig configuration (100% of outputs).

PPk

PPk was a decentralised identity and naming protocol that operated on Bitcoin, using P2MS and OP_RETURN outputs for message encoding. PPk aimed to provide a decentralised alternative to DNS and digital identity systems.

PPk transactions are identified by a distinctive marker pubkey (0320a0de...3e12) that must appear in the second position of a P2MS output. Once detected, variant classification examines the combined P2MS and OP_RETURN data:

• PPk Profile: transactions carry JSON payloads using a "RT" (Resource Tag) and a type–length–value (TLV) structure
• PPk Registration: transactions contain quoted numeric strings like "315"
• PPk Message: transactions contain promotional text with "PPk" substrings or ≥80% printable ASCII
• PPk Unknown: Unrecognised PPk message types that don't fit the above patterns.

Table 20: Breakdown of PPk variants observed in P2MS UTXOs, as of block height 918,997 (14 October 2025).

PPk uses two multisig configurations:

• 1-of-3: 70.43% of outputs
• 1-of-2: 29.57% of outputs

All 4,728 PPk P2MS outputs appear spendable and only a small amount of value, ~0.05 BTC, is locked in them.

OP_RETURN Signalled

The OP_RETURN Signalled classification captures transactions where an OP_RETURN output contains a protocol identifier, but the transaction also includes P2MS outputs. Often the OP_RETURN serves as a protocol identifier, with P2MS outputs providing additional data capacity for the protocol's payload.

Table 21: Breakdown of OP_RETURN Signalled variants observed in P2MS UTXOs, as of block height 918,997 (14 October 2025).

The largest category is "Protocol47930" (54.9%), representing transactions featuring the 0xbb3a marker (47930 in decimal). "Generic ASCII" (27.5%) captures various ASCII-based identifiers that don't match known protocols, examples include CC (138 outputs), 8EC= (104 outputs) and DEVCHA (30 outputs). "CLIPPERZ" (17.6%) corresponds to the Clipperz open-source password manager, which at some point in the past seems to have used Bitcoin as a backup storage feature.

Unlike dedicated data-carrying protocols, OP_RETURN Signalled transactions show an odd mix of multisig configurations:

• 2-of-2: 84.1% of outputs
• 1-of-2: 10.8% of outputs
• 1-of-3: 4.6% of outputs

The prevalence of 2-of-2 configurations (rather than the 1-of-n patterns typical of data-carrying protocols) is notable, since these require multiple valid signatures to spend. Analysis of EC-point validity shows that 92.53% of these OP_RETURN Signalled P2MS outputs are actually spendable, with ~0.11 BTC currently locked across all OP_RETURN Signalled P2MS outputs.

ASCII Identifier Protocols

The ASCII Identifier Protocols classification captures P2MS transactions where the embedded data begins with a recognisable ASCII string identifier. That is, the ASCII string identifier is in the P2MS data (as opposed to OP_RETURN Signalled where the identifier is in the OP_RETURN output). These represent various experimental or short-lived protocols that used P2MS for data storage.

Table 22: Breakdown of ASCII identifier protocol variants observed in P2MS UTXOs, as of block height 918,997 (14 October 2025).

TB0001 (41.9%) is the most common variant, though the protocol's purpose remains unidentified. METROXMN (22.2%) is associated with Metronotes XMN, which appears to be a scam. TEST01 (21.9%) likely represents testing activity during protocol development or experimentation. The "Other ASCII Protocol" category (14.0%) is almost entirely NEWBCOIN (113 of 114 outputs), an unknown protocol from late 2014. Approximately half of the NEWBCOIN transactions (11 of 20) embed gzip-compressed data across multiple P2MS outputs per transaction (9–10 outputs each), while the remainder are single-output transactions without compression. The single non-NEWBCOIN output is PRVCY from March 2015.

ASCII Identifier Protocols use two multisig configurations:

• 1-of-2: 63.24% of outputs
• 1-of-3: 36.76% of outputs

All 816 ASCII Identifier Protocols P2MS outputs are spendable.

Data Storage

The Data Storage classification captures P2MS transactions where embedded data does not match any known protocol identifier or pattern. These represent direct data embedding without protocol structure or ASCII identifiers.

The classifier searches for known file signatures (PNG, JPEG, GIF, PDF, ZIP, RAR, GZIP, ZLIB, TAR, and others) via magic byte detection, as well as text content analysis. However, in practice, the vast majority of data storage outputs contain generic binary or text data without recognisable file signatures; the only file format detected with any frequency is ZLIB-compressed data (90 outputs). This suggests that early data embedders typically stored raw text, compressed archives, or custom binary formats rather than standard file types like images or PDFs.

Additionally, the classifier identifies proof-of-burn patterns (such as all 0xFF or 0x00 byte pubkeys, or other unspendable patterns) and file metadata patterns (URLs, filenames, archive extensions).

Table 23: Breakdown of Data Storage variants observed in P2MS UTXOs, as of block height 918,997 (14 October 2025).

The "WikiLeaks Cablegate" files dominate this category at 46.3%, representing diplomatic cables embedded across thousands of P2MS outputs. As explored in Part 1, this is one of the most famous examples of data storage in P2MS, alongside the Bitcoin whitepaper PDF, which itself was also embedded in April 2013 across 946 P2MS outputs (3.3%). "Embedded Data" (36.5%) captures various other data embedding efforts. "Proof of Burn" (13.9%) represents outputs created specifically to demonstrate destruction of bitcoin value.

Data Storage shows diverse multisig configurations, reflecting its ad-hoc nature:

• 1-of-3: 80.84% of outputs
• 1-of-2: 15.92% of outputs
• 2-of-2: 1.45% of outputs
• 1-of-1: 1.28% of outputs
• 2-of-3: 0.48% of outputs
• 3-of-3: 0.04% of outputs

Only 33.29% of Data Storage P2MS outputs are spendable, with the majority (66.71%) being unspendable due to all keys being used for data carriage or proof-of-burn patterns. ~10.18 BTC is currently locked in Data Storage P2MS outputs.

Likely Data Storage

The Likely Data Storage classification captures P2MS transactions that exhibit characteristics suggesting data storage but lack definitive protocol identifiers or clear data patterns. Unlike Data Storage (which has confirmed data patterns), Likely Data Storage represents a heuristic-based classification where characteristics such as dust-level values, high output counts, or invalid public keys indicate probable data carriage.

Table 24: Breakdown of Likely Data Storage variants observed in P2MS UTXOs, as of block height 918,997 (14 October 2025).

The dominant variant is "Dust Amount" (63.52%), capturing outputs where the encumbered value is less than 1000 sats. "High Output Count" (36.06%) identifies transactions that feature 5+ P2MS outputs, a pattern perhaps indicative of bulk data embedding rather than normal multisig usage. "Invalid EC Point" (0.42%) represents outputs where at least one pubkey is provably not a valid point on the secp256k1 curve, again indicative of data carrying rather than legitimate multisig.

The Likely Data Storage has the following multisig configuration profile:

• 2-of-2: 39.68% of outputs
• 1-of-1: 32.39% of outputs
• 1-of-3: 13.89% of outputs
• 2-of-3: 13.52% of outputs
• 1-of-2: 0.51% of outputs

This distribution is notably different from both Data Storage (e.g., 80.84% 1-of-3) and established data-carrying protocols. Specifically, 2-of-2 at 39.68% is more commonly associated with legitimate multisig arrangements as opposed to data carriage.

99.86% of Likely Data Storage P2MS outputs are spendable, with only 3 outputs being unspendable. ~0.03 BTC is currently locked in Likely Data Storage outputs.

Likely Legitimate Multisig

The Likely Legitimate Multisig classification represents P2MS outputs that appear to be genuine multisig arrangements for securing funds rather than data carriage. These outputs exhibit characteristics consistent with legitimate multisig usage: valid public keys, reasonable value amounts, and multisig configurations that make practical sense for custody arrangements (valid EC point keys).

Table 25: Breakdown of Likely Legitimate Multisig variants observed in P2MS UTXOs, as of block height 918,997 (14 October 2025).

The vast majority (97.8%) are standard legitimate multisig outputs. The "Null-Padded" variant (1.3%) represents outputs where public keys contain null padding, potentially indicating older wallet software or non-standard key generation. "Duplicate Keys" (0.9%) captures the unusual case where the same public key appears multiple times in a multisig script, which while technically valid, suggests implementation bugs.

Likely Legitimate Multisig shows the most diverse multisig configuration profile of any classification:

• 2-of-2: 41.30% of outputs
• 1-of-2: 25.00% of outputs
• 2-of-3: 12.68% of outputs
• 1-of-3: 11.41% of outputs
• 1-of-1: 9.60% of outputs

All 552 Likely Legitimate Multisig P2MS outputs are spendable (100%), as would be expected. The total value locked in these outputs is approximately 6.50 BTC which accounts for ~9.4% of the total value encumbered in P2MS outputs. This gives an average value of ~0.12 BTC (e.g., 1.2 million sats) per output, which is orders of magnitude higher than Bitcoin Stamps (796 sats) or other data-carrying protocols, clearly a reflection of their use to secure holdings rather than store data.

The fact that only 552 outputs (0.02% of all P2MS UTXOs) appear to represent legitimate multisig usage underscores how completely P2MS has been co-opted for data carriage purposes.

What to make of all this?

The objective of this analysis has been to present comprehensive data on P2MS usage as observed from P2MS outputs in the UTXO set. The findings are stark: over 99.98% of P2MS UTXOs serve data embedding protocols, 74.37% are provably unspendable, and just 0.02% (552 of 2.4M outputs) appear to represent legitimate multisig usage. This represents a fundamental departure from the script type's intended purpose of enabling multisig custody arrangements and is largely driven by one protocol: Bitcoin Stamps.

P2MS usage over time

Though the content here is centred on P2MS UTXOs, it would be remiss to not consider the totality of P2MS usage, including P2MS outputs that have already been spent. Figure 7 shows the cumulative number of P2MS outputs created (purple line) versus the cumulative number of P2MS inputs spent (blue line) over time.

Of the ~2.71M P2MS outputs created through to 14 October 2025, approximately 288K have ever been spent as inputs, yielding a spend rate of just 10.6%. Only ~8% of the spent P2MS outputs were spent in the last ~6 years, with the remaining ~92% having been spent in the ~8 years prior (2012–2020). Since Bitcoin Stamps launched, the creation of P2MS outputs has vastly outpaced their spending, leading to a growing accumulation of P2MS outputs in the UTXO set.

[Interactive plot - view on website]

Cumulative P2MS inputs (spent) and outputs (created) over time. The dramatic divergence since Bitcoin Stamps launched in early 2023 illustrates that P2MS outputs are being created far faster than they are being spent. Data sourced from mainnet.observer.

Bitcoin Stamps permanence

When Bitcoin Stamps launched in early 2023, its creators justified using P2MS on the grounds of permanence and "art": art encoded in deliberately unspendable outputs would remain in the UTXO set indefinitely. This rationale was controversial, with objection to deliberate UTXO set pollution, but the protocol forged ahead regardless.

It is true that different data carriage techniques offer different persistence guarantees. Witness data, used by Ordinals/Inscriptions, is not part of the UTXO set and can be pruned by full nodes running in pruned mode. OP_RETURN outputs are provably unspendable and never enter the UTXO set. P2MS outputs, however, must be retained by all full nodes because they might be spendable - a node cannot know whether a given public key has a corresponding private key.

Bitcoin Stamps exploits this property by deliberately creating P2MS outputs that are unspendable but appear potentially spendable to the network. By using invalid Key Burn keys alongside data-carrying keys, Bitcoin Stamps ensures its data remains in the UTXO set of every full node indefinitely. Each unspendable output adds to the UTXO set size that every full node (archival and pruned) must maintain in fast-access memory. This is a cost imposed on the entire network.

However, the "permanence guarantee" offered by UTXO set storage is overstated. While pruned nodes discard block data (including OP_RETURN outputs), over 90% of Bitcoin full nodes (as of late 2025) run in archival mode, retaining the complete blockchain history. Data embedded via OP_RETURN is therefore preserved across the vast majority of the network. Forcing data into the UTXO set, rather than block storage, comes at disproportionate cost to the network with no practical permanence benefit.

Bitcoin Core v30 and OP_RETURN unbounding

Bitcoin Core v30.0, released in October 2025, removed the standardness restrictions that previously limited OP_RETURN outputs to 80 bytes of data. Transactions with OP_RETURN outputs of any size (up to the transaction size limit) are now relayed and mined by default. This fundamentally changes the data carriage landscape on Bitcoin.

Bitcoin Stamps' current usage doesn't justify P2MS

The data shows that Bitcoin Stamps' use case has evolved significantly from its original "art" focus. As shown in Figure 6, no P2MS "Classic Stamps" (images) have been created since March 2024, and only the JSON-based sub-protocols of Bitcoin Stamps (SRC-20, SRC-101) have leveraged P2MS in 2025.

Bitcoin Stamps' current P2MS usage is entirely for simple JSON payloads, not art. These JSON payloads do not inherently require the permanence guarantee that P2MS provides. They could function identically using OP_RETURN outputs, which:

• Do not pollute the UTXO set (they are provably unspendable and pruned from the UTXO set)
• Are now limited in size only by the transaction size limit following the release of Bitcoin Core v30.0
• Are the standard, intended mechanism for data carriage on Bitcoin

It's worth noting that Bitcoin Stamps already uses multiple data carriage techniques beyond P2MS. The continued use of P2MS specifically for JSON payloads, when OP_RETURN is now a viable alternative, is difficult to justify.

The case for deprecating P2MS

Given the data presented in this analysis, there is a reasonable case for deprecating the creation of new P2MS outputs. That is, introducing a soft fork to make the creation of new P2MS outputs invalid by consensus.

The arguments in favour of deprecation include:

1. P2MS is not used for its intended purpose. The data is unambiguous: 99.98% of P2MS UTXOs serve data embedding protocols, not multisig custody. Legitimate multisig users migrated to P2SH and P2WSH years ago, which offer better privacy, lower fees, and broader wallet support. Modern wallets largely do not support P2MS at all; as Bitcoin Core maintainer Ava Chow noted in August 2023: "Bare multisigs are generally unusable to the vast majority of wallet software, if not all of them. They do not have an address type so the vast majority of users are completely unable to send to them."

2. The primary user no longer needs P2MS. As detailed above, Bitcoin Stamps' current usage is entirely JSON-based sub-protocols that don't require UTXO set permanence. With OP_RETURN now effectively unbounded, there is no reason for Bitcoin Stamps to continue using P2MS.

3. Reduced maintenance burden. Deprecating P2MS would allow Bitcoin Core developers to remove support for a script type that clearly no longer serves its original multisig custody purpose, simplifying the codebase and reducing maintenance overhead.

4. Network resource preservation. Preventing new unspendable P2MS outputs would halt the ongoing UTXO set growth from data carriage protocols that now have viable alternatives.

The arguments against deprecation are primarily procedural rather than technical:

• Bitcoin's conservatism regarding consensus changes. Any change that invalidates previously valid transactions requires careful consideration, even if the affected use cases are not the intended purpose.

• Precedent concerns. Some argue that restricting how people use Bitcoin, even for purposes such as data carrying via deliberately unspendable transaction outputs, sets a problematic precedent.

• Existing outputs remain. Deprecating new P2MS outputs does nothing about the 2.4M outputs already in the UTXO set. The pollution that has already occurred is permanent until other change happens in Bitcoin, e.g., a future UTXO set pruning mechanism.

Prior proposals and discussions

There have been several proposals to address P2MS misuse, though none have been implemented.

In September 2023, portlandhodl opened Bitcoin Core PR #28400 titled "Make provably unsignable standard P2PK and P2MS outpoints unspendable" to remove provably unspendable P2PK and P2MS transaction outputs from the UTXO set. The PR received generally positive feedback, with contributors acknowledging the UTXO set pollution problem.

However, it was ultimately closed by the author in March 2024 with the comment: "Closing because the fragility of this PR does not justify its limited impact." The challenges included determining which outputs are truly provably unspendable, managing consensus implications, and the relatively small impact relative to overall UTXO set size.

A related discussion occurred around PR #28217, which proposed limiting bare multisig to only OP_CHECKMULTISIG and not OP_CHECKMULTISIGVERIFY. Developer Jimmy Song commented in December 2023 about the broader question of whether bare multisig should be deprecated entirely, noting the data-carrying abuse. Various discussions on platforms like Stacker News have explored whether P2MS should be made non-standard or removed from consensus, though no such changes have been implemented.

Conclusion

This analysis provides a comprehensive baseline for understanding P2MS usage as of late 2025. The data demonstrates conclusively that P2MS is no longer serving its intended purpose with data carriage, particularly via Bitcoin Stamps, the dominant use case. The transition from predominantly spendable outputs before Bitcoin Stamps launched to ~75% unspendable in just ~2.5 years represents a dramatic shift in P2MS usage.

With Bitcoin Core v30.0 removing OP_RETURN size limits, the technical justification for using P2MS as a data carriage mechanism has largely evaporated. Bitcoin Stamps now has a viable alternative for its JSON-based payloads that doesn't impose permanent costs on the network. Whether the Bitcoin community chooses to deprecate P2MS, maintain the status quo, or pursue other approaches, the data presented here makes it unambiguously clear that the current state of P2MS usage is far removed from its original design intent.

References

• UTXO Set Report (Mempool Research)
• Ordinals - Impact on Node Runners
• What are the limits of m and n in m-of-n multisig addresses?
• Bitcoin Core v30.0 Release Notes
• Bitcoin Core PR #28400: Make provably unsignable standard P2PK and P2MS outpoints unspendable
• Bitcoin Core PR #28217: Limit bare multisig to OP_CHECKMULTISIG
• Jimmy Song on P2MS deprecation
• Stacker News discussion on P2MS standardness

Pay-to-Multisig (P2MS) is Bitcoin's original multisig format, since superseded by more efficient alternatives like P2SH and P2WSH. Even so, it persisted - and still persists - as a vehicle for data carriage, with multiple protocols embedding payloads into fake pubkeys inside Bitcoin transactions. Three major protocols dominate this practice: Bitcoin Stamps, Counterparty and Omni.

Bitcoin Stamps employs ARC4 obfuscation (TXID-keyed) and can be identified by distinctive Key Burn patterns in the original pub keys (0x0222..., 0x0333..., etc). A protocol identifier, e.g., stamp:, appears only once in the deobfuscated key data. Bitcoin Stamps uses 1-of-3 P2M outputs, with one Key Burn pubkey and two data pubkeys per output, so no private keys exist that can spend the output.

Counterparty also uses ARC4 obfuscation (TXID-keyed) but is identified by the string CNTRPRTY being present in the deobfuscated key data. The identifier appears once per ARC4-obfuscated output, so multi-output transactions sacrifice data carrying efficiency. Counterparty maintains at least one real pubkey per output in its 1-of-2 or 1-of-3 configurations, so most Counterparty-related P2MS outputs remain spendable in theory (apart from Classic Stamps).

Omni distinguishes itself through obfuscation based on SHA-256+XOR, keyed to the sender's address, and identification via the Exodus address (1EXoDusj...) in adjacent transaction outputs. Omni also maintains valid pubkeys in its 1-of-2 or 1-of-3 structures, so all Omni P2MS outputs can also be spent (again, in theory).

A number of minor protocols also leverage P2MS for data carrying purposes, including protocols using identifiers such as CHANCECO (Chancecoin), TB0001, TEST01 and METROXMN. Additionally, several protocols employ hybrid approaches that use P2MS alongside OP_RETURN. PPk (PPkPub) uses the combined data-carrying capacity of P2MS outputs + OP_RETURN, with a distinctive marker pubkey for identification, whereas others use OP_RETURN outputs for explicit protocol signalling with the larger storage capacity of P2MS outputs used for the data payload (e.g., "Protocol 47930", CLIPPERZ). Beyond protocol-based approaches, P2MS has also been used for generic data storage, with notable examples including the Bitcoin whitepaper PDF and Wikileaks Cablegate files.

Introduction

This post is the first in a series of posts that will explore how the Bitcoin blockchain is used for data carriage. Data carriage refers to the practice of embedding arbitrary, non-financial data into Bitcoin transactions and storing it permanently on the blockchain. Data carriage is a controversial topic in the Bitcoin community, with some viewing it as a legitimate use case for the blockchain, while others see it as an abuse of the system that adds blockchain bloat and raises costs for everyone.

While there are many ways to embed data in Bitcoin transactions, this and the following posts will explore the use of Pay-to-Multisig (P2MS) script types for data carriage. This instalment explains the fundamentals of P2MS and how it's used for data carriage while Part 2 examines the magnitude of P2MS data carriage via an analysis of a snapshot of the UTXO set. Note that this post goes into detail in breaking down examples of the various protocols; these examples are collapsed by default but can be expanded.

The use of P2MS script types seemed like a good place to start because:

• It's the legacy script type for multisig that has long been superseded by other script types that enable multisig, including P2SH and P2WSH, with these newer script types being more economical to use.
• Given the above, there's no real reason for anyone to use P2MS for multisig, yet it is still used, for data carriage.
• There's been a significant increase in P2MS UTXOs since early 2023 as per Figure 1, yet the encumbered value remains tiny.
• P2MS data carrying is regularly used, albeit much less so than other approaches (e.g., P2TR-based approaches), but it remains understudied compared to other approaches.

There have been a number of analyses of data carriage in Bitcoin, but they generally focus on the other data carriage methods. Pay-to-Fake-Multisig (P2FMS) as the use of P2MS for data carriage is sometimes called, is often just a side note. See the References section for links to some of these other analyses.

P2MS fundamentals

P2MS is a script type that allows users to lock bitcoins to multiple (n) public keys, and require signatures for some or all (m) of those public keys to unlock and spend; an m-of-n multisig. P2MS is sometimes referred to as raw or bare multisig, as the public keys used to create the lock are directly accessible in the locking script (the ScriptPubKey). This is in contrast to the more modern multisig constructs of P2SH and P2WSH where the public keys used to create the lock are obfuscated by hashing before being input into the locking script.

Here's an example of a recent transaction from block height 903,379 (June 2025) that features two P2MS outputs that are relevant to the following content: eb96a65e...

The ScriptPubKey of the first P2MS output is:

512103d587bbd682a301f2933de3efd59ec3aa0e5a305d3b4597a8d71880895ebd9f002102660224cd2ffbf92fada23aa883f0c51f2d55ae13394a40d6538ff2a63d0dce002102020202020202020202020202020202020202020202020202020202020202020253ae

This ScriptPubKey is 105 bytes, comprised of the following:

• OP_1 (51), this is m in the m-of-n multisig
• 3x sets of OP_PUSHBYTES_33 (21) followed by 33-byte public keys
  • 21 03d587bbd682a301f2933de3efd59ec3aa0e5a305d3b4597a8d71880895ebd9f00
  • 21 02660224cd2ffbf92fada23aa883f0c51f2d55ae13394a40d6538ff2a63d0dce00
  • 21 020202020202020202020202020202020202020202020202020202020202020202
• OP_3 (53), this is n in m-of-n, so it's a 1-of-3 multisig
• OP_CHECKMULTISIG (ae)

Those first two public keys on the surface look like they could be proper public keys, but that 3rd key looks "fake". Indeed, even mempool.space indicates as such, what's the deal with that?

Fake keys

The 3rd key is indeed a fake key in the sense that it's not a public key that has a known corresponding private key. This fake key, 020202020202020202020202020202020202020202020202020202020202020202, is actually one of the Key Burn addresses that are used by Bitcoin Stamps, one of the leading data carrying protocols that use P2MS.

The ability to generate predetermined patterns of public keys such as Key Burn addresses in this instance, or burn addresses in general, is almost impossible because it requires generating a private key that leads to the desired public key. Said another way, the probability of arriving at a pre-determined pattern for an ECC-256 public key is "infinitesimally small to the point where a computer would need to grind away at keys for billions of years in order to produce a valid private key" Bitcoin Stamps.

Because of the near impossibility of generating a private key that leads to a predetermined pattern in a public key, the existence of a highly improbable patterned public key is accepted as evidence that there is no corresponding private key... and that the key cannot be used to spend the output!

According to the official Bitcoin Stamps protocol documentation, there are 4 Key Burn addresses/patterns/public keys:

• 022222222222222222222222222222222222222222222222222222222222222222
• 033333333333333333333333333333333333333333333333333333333333333333
• 020202020202020202020202020202020202020202020202020202020202020202
• 030303030303030303030303030303030303030303030303030303030303030303

The Key Burn technique assigns one of the above Key Burn keys to last key position in the 1-of-3 multisig, leaving the first two keys as possibilities to spend the output.

The first two keys, however, are actually the data-carrying component (as we shall later learn from understanding how Bitcoin Stamps works), although we can't always definitively prove that they represent "fake" public keys. That is, we can run a check to see if a given public key is a valid point on the ECDSA secp256k1 curve, if it is not, we know that it is truly a fake public key, yet if it is a valid point, then it could either be a true key or just "data" that happens to correspond to a point on the curve!

For example, using the 1st and 2nd keys above:

• 1st key: 03d587bbd682a301f2933de3efd59ec3aa0e5a305d3b4597a8d71880895ebd9f00 is a valid point
• 2nd key: 02660224cd2ffbf92fada23aa883f0c51f2d55ae13394a40d6538ff2a63d0dce00 is NOT a valid point

CODE: Python code to validate a public key on the secp256k1 curve

# Validate public key on secp256k1 curve
# Returns True if point (x,y) satisfies: y² = x³ + 7 (mod p)

p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F

def is_valid_pubkey(pubkey_hex):
    """Check if public key is valid point on secp256k1"""
    pub_bytes = bytes.fromhex(pubkey_hex)

    if len(pub_bytes) == 33:  # Compressed
        prefix, x = pub_bytes[0], int.from_bytes(pub_bytes[1:], 'big')
        y_squared = (pow(x, 3, p) + 7) % p
        y = pow(y_squared, (p + 1) // 4, p)

        if pow(y, 2, p) != y_squared:
            return False

        # For any valid x, there are two valid y values: y and p - y
        # If calculated y doesn't match prefix parity, use the other root
        if (y % 2 == 1) == (prefix == 0x02):
            y = p - y

        return (y % 2 == 0) == (prefix == 0x02)

    elif len(pub_bytes) == 65:  # Uncompressed
        x = int.from_bytes(pub_bytes[1:33], 'big')
        y = int.from_bytes(pub_bytes[33:], 'big')
        return (pow(y, 2, p) - pow(x, 3, p) - 7) % p == 0

    return False

# Usage: is_valid_pubkey("03d587bbd682a301f2933de3efd59ec3aa0e5a305d3b4597a8d71880895ebd9f00")

Suffice it to say, checking whether a given public key is a valid point on the ECDSA secp256k1 curve is insufficient to definitely prove that the key is data or otherwise - sometimes a public key will be a valid point yet it just represents data (as with the 1st key above).

We have yet to see how keys can represent data; let’s examine how data is embedded.

Data carrying in P2MS - A Bitcoin Stamps example

Note that the following is provided to give a concrete example of how Bitcoin Stamps embeds arbitrary, non-financial data into Bitcoin transactions; the aim is not to cover the minutiae of how such protocols operate at a higher level (e.g., deploying, minting, transferring etc.).

Bitcoin Stamps inserts data into 1-of-3 P2MS transaction outputs, with the data encoded to look like public keys for the first two keys ("data keys"), and a Key Burn address used for the third. Setting the Key Burn address aside, with compressed public keys being 33 bytes, the first and last bytes are stripped from each of the data keys, leaving 31 bytes apiece. Concatenate the byte strings into a single 62-byte string:

d587bbd682a301f2933de3efd59ec3aa0e5a305d3b4597a8d71880895ebd9f + 
660224cd2ffbf92fada23aa883f0c51f2d55ae13394a40d6538ff2a63d0dce

If the transaction contains two or more P2MS outputs, then the above process is followed for each output: take the first two public keys, disregard the Key Burn, strip bytes and concatenate the data key byte strings. Then concatenate such strings from each transaction output into a single byte string.

For our example transaction, there's a 2nd multisig output that has the following data keys:

03e34afbaa13450d01f91c6633f7e9cd5893c6096f9087b347a2479c7add951700
02ae587815be570ac6344c49be194daa07e4b8de982f16c8175a981cd0ff4d2200

Stripped:

e34afbaa13450d01f91c6633f7e9cd5893c6096f9087b347a2479c7add9517 +
ae587815be570ac6344c49be194daa07e4b8de982f16c8175a981cd0ff4d22

Concatenating the byte string from the first and second output yields the following 124-byte string:

d587bbd682a301f2933de3efd59ec3aa0e5a305d3b4597a8d71880895ebd9f + 
660224cd2ffbf92fada23aa883f0c51f2d55ae13394a40d6538ff2a63d0dce +
e34afbaa13450d01f91c6633f7e9cd5893c6096f9087b347a2479c7add9517 +
ae587815be570ac6344c49be194daa07e4b8de982f16c8175a981cd0ff4d22

The resulting byte string can now be decoded into meaningful data. Bitcoin Stamps uses the ARC4 (RC4) stream cipher to obfuscate the original data before embedding it, with a key that is the transaction ID (TXID) corresponding to the first transaction input (vin[0]). For our example transaction eb96a65e..., the TXID corresponding to the first transaction input is:

7568f57ecf417e19edefc810f9bbd34d2a62eb770d8492396ceffed3c5dc7348

Via:

bitcoin-cli getrawtransaction eb96a65e4a332f2c84cb847268f614c037e038d2c386eb08d49271966c1b0000 | xargs bitcoin-cli decoderawtransaction | jq '.vin[0].txid'

Using 7568f57e... as the deobfuscation key, the byte string is deobfuscated to the following. Note that ARC4 being a stream cipher means that deobfuscation preserves length - 124 bytes in, 124 bytes out.

003f7374616d703a7b2270223a227372632d3230222c226f70223a227472616e73666572222c227469636b223a22424d574b222c22616d74223a2231303030227d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

The first two bytes, 003f, is the length of the decoded data in hex - this is just 63. That is, the 63 bytes following the initial two bytes are the meaningful data, with the remaining data being meaningless (the remaining bytes are zero padding).

Decoding the meaningful 63 bytes with UTF-8 gives:

'stamp:{"p":"src-20","op":"transfer","tick":"BMWK","amt":"1000"}'

Note that in the above there are no spaces - "in order to minimize the transaction size spaces are not used in the serialized JSON string which is constructed by the SRC-20 reference wallet". Prettier formats to the following.

stamp: {
	"p":"src-20",
	"op":"transfer",
	"tick":"BMWK",
	"amt":"1000"
}

So we've taken the two P2MS transaction outputs and transformed it to the above data. But we've still got some other aspects of the transaction, such as the two other non-P2MS transaction outputs and the output values, that we should briefly consider.

Non-P2MS transaction outputs and output values

The first transaction output, vout[0], with an address bc1qmgl3u9m7... is the transfer destination. Transfer because this is what the op was in this example; in other cases it might be the "minter" or "deployer" etc. The main point is that vout[0] is always some real address.

The 4th transaction output, vout[3], with an address bc1qdmsmn42q..., is the change address. In this example, it's actually just the same address that was the single transaction input to this transaction - change is going back to original spending address.

The transaction details in Figure 4 show that the first three outputs have a value of 790 sats each. I don't think this value has any significance other than it safely exceeds all dust limits - the highest being 546 sats for P2PKH for the default configuration of 3 sat/vByte. That is, these values ensure that each output and thus the overall transaction is valid, yet is low enough to have low monetary value.

Unspendable P2MS outputs

In the above we established that the P2MS transaction outputs were actually purely for data carrying (or were Key Burn) and did not involve real public keys. As such, these P2MS outputs are effectively unspendable outputs, and, given the current design of Bitcoin, they'll remain in the UTXO set of every Bitcoin node. Each time there's a transaction that embeds data in P2MS outputs in the manner described above, there will be at least one, but possibly more, new unspendable P2MS UTXOs added to the UTXO set.

Note that this is, perhaps obviously, intentional. As is noted in the Bitcoin Stamps documentation:

"By doing so, the data is preserved in such a manner that is impossible to prune from a full Bitcoin Node, preserving the data immutably forever."

I think many would consider this wasteful - every time there is some form of individual activity on Bitcoin Stamps, such as the transfer operation from the above example, there's a one-to-one mapping to activity on Bitcoin, tracked forever, by all Bitcoin nodes! It's probably worth examining Bitcoin Stamps in a bit more detail to better understand the what and why.

Bitcoin Stamps

Bitcoin Stamps were developed in response to most NFTs being "merely image pointers to centralized hosting or stored on-chain in prunable witness data". They were a means to achieve permanence in "storing art on the blockchain" and indeed STAMP is an acronym for Secure, Tradeable Art Maintained Securely. The original spec also stated that Bitcoin Stamps encode:

"an image's binary content to a base64 string, placing this string as a suffix to STAMP: in a transaction's description key, and then broadcasting it using the Counterparty protocol onto the Bitcoin ledger. The length of the string means that Counterparty defaults to bare multisig, thereby chunking the data into outputs rather than using the limited (and prunable) OP_RETURN. By doing so, the data is preserved in such a manner that is impossible to prune from a full Bitcoin Node, preserving the data immutably forever."

The above examination of the eb96a65e... transaction is but just one example of Bitcoin Stamps embedding arbitrary data in P2MS outputs. In fact, Bitcoin Stamps has used a variety of techniques since the first transactions, 17686488... and eb3da814..., were included in Block 779,652.

As the above text alluded to, Bitcoin Stamps started out leveraging Counterparty (which has been around since 2014 and is covered in the Counterparty section). Specifically, Bitcoin Stamps ("Classic Stamps") were initially a numerical asset on Counterparty, with data encoded via either P2MS or P2WSH. P2MS Classic Stamps were encoded in the almost the same manner as the example explored above:

• ARC4 obfuscation/deobfuscation keyed with the TXID of the first transaction input
• Key Burn alongside data keys, no real pubkey present

However, the deobfuscated data must first contain the CNTRPRTY prefix, followed by some Counterparty message fields, before a STAMP: prefix variant and Bitcoin Stamps specific data is found. That is, Classic Bitcoin Stamps used Counterparty transactions as a transport mechanism to embed data in Bitcoin transactions. See Bitcoin Stamps - Classic Stamp image (Counterparty transport) example for a breakdown of such a transaction.

Bitcoin Stamps sub-protocols

Since then, Bitcoin Stamps has become or leveraged a suite of sub-protocols or formats, including SRC-20, SRC-101, SRC-721, SRC-721r, OLGA, with each purportedly serving a different purpose. Note that not all of these forms use P2MS, for example the OLGA Stamp uses P2WSH outputs. As the interest here is P2MS, we'll only focus on the aspect of Bitcoin Stamps that leverage P2MS: Classic Stamps, SRC-20, SRC-101, SRC-721.

The initial example of Bitcoin Stamps using P2MS above (Data carrying in P2MS - A Bitcoin Stamps example) is an example of SRC-20. SRC-20 was developed in response to the BRC-20 craze of early 2023, with SRC-20 offering stronger permanence guarantees due to use of non-witness transaction data. Aside: if you're interested in knowing more about BRC-20 and the history of Ordinals and Inscriptions be sure to check out Binance Research's "BRC-20 Tokens: A Primer" (May 2023) piece. Most Bitcoin Stamps related Bitcoin transactions involve SRC-20.

SRC-101 is a domain name system native to Bitcoin Stamps, similar to something like the Ethereum Name Service (ENS). Such systems are, for example, used to replace standard Bitcoin addresses like bc1q34eaj4rz9yxupzxwza2epvt3qv2nvcc0ujqqpl with simple, human-readable names like alice.btc. The permanence of P2MS, and the guarantee of unspendability via the use of no real pubkeys, were purportedly the rationale for developing SRC-101.

All this is to say that, even within a single ecosystem (Bitcoin Stamps), there are a number of permutations and variants of how data is encoding for data carrying purpose that we need to consider for classification and analysis purposes.

Bitcoin Stamps - Classic Stamp image (Counterparty transport)

EXAMPLE: Bitcoin Stamps - Classic Stamp image (Counterparty transport)

54fdeda9... is a transaction from block height 809,193 with 79 outputs, 77 of which are P2MS outputs. A review of the P2MS outputs shows that all have the 022222222222222222222222222222222222222222222222222222222222222222 Key Burn pattern and the TXID of vin[0] is :

3b2b5e1de60ba341b8ba85e35b09800edb118dc7bee246d54b11420f01aabac5

Armed with this as the deobfuscation key, we can attempt to decode the data embedded in the 77 P2MS outputs. Let's examine the first three P2MS outputs to illustrate the process.

1st P2MS output

Pubkeys:

02e6e725b168f3eeafa527053d43d06c9569a393c34d0e5c2dad2236b785eaed70
02acb6c9432134cad7242dbbd531c44e5ec5918e31d65adab1b2ffb2d3588c7d36

Stripped and concatenated:

e6e725b168f3eeafa527053d43d06c9569a393c34d0e5c2dad2236b785eaed +
acb6c9432134cad7242dbbd531c44e5ec5918e31d65adab1b2ffb2d3588c7d

Deobfuscated with TXID of vin[0]:

3d434e54525052545914575ed3597b0aa71d00000000000000230001005354 +
414d503a52306c474f446c686f41436741504d5041487a4741502f2f2f7777

ASCII interpretation (some characters replaced with .):

.CNTRPRTY.......STAMP:R0lGODlhoACgAPMPAHzGAP///ww

2nd P2MS output

Pubkeys:

03e6e725b168f3eeafa5621322e3c853da83f6d2802a4f136cec6c79f0d0e1f8c4
02a690d838397ce3d1252bbffc0eae7961e2b5ba20c759cfb7a384f6cb10ba4bb6

Stripped and concatenated:

e6e725b168f3eeafa5621322e3c853da83f6d2802a4f136cec6c79f0d0e1f8 +
a690d838397ce3d1252bbffc0eae7961e2b5ba20c759cfb7a384f6cb10ba4b

Deobfuscated with TXID of vin[0]:

3d434e545250525459514141734144454d48414367414f41416d4f46555841 +
4b6b41414a7845414e426841502b745866747941504b6f41502b6b37674141

ASCII interpretation:

=CNTRPRTYQAAsADEMHACgAOAAmOFUXAKkAAJxEANBhAP+tXftyAPKoAP+k7gAA

3rd P2MS output

Pubkeys:

02e6e725b168f3eeafa572112bbfca27aa88e8d58d095f0a6feb4c5f82f2f8ce20
03a8bad838326c8dc13a2f8dfc1fd54c7accea8834ae65c4b19fdbfca4079750c7

Stripped and concatenated:

e6e725b168f3eeafa572112bbfca27aa88e8d58d095f0a6feb4c5f82f2f8ce +
a8bad838326c8dc13a2f8dfc1fd54c7accea8834ae65c4b19fdbfca4079750

Deobfuscated with TXID of vin[0]:

3d434e5452505254594143482f4330354656464e44515642464d6934774177 +
4541414141682b5151465a4141504143482b4b55397764476c746158706c5a

ASCII interpretation:

=CNTRPRTYACH/C05FVFNDQVBFMi4wAwEAAAAh+QQFZAAPACH+KU9wdGltaXplZ

Whenever we see 434e545250525459 in deobfuscated output, we have found the CNTRPRTY identifier. Focusing on the first P2MS output, because we have the CNTRPRTY prefix, we have to interpret the following bytes according to the Counterparty protocol. Now, depending on whether the transaction represents a "legacy" Counterparty transaction or a "modern" Counterparty transaction, changes the interpretation of data. Turns out that this is a "modern" form where the message type is a single byte rather than the 4 bytes for "legacy" Counterparty transactions. Here's a breakdown of the first P2MS output:

Also note that whenever we see 5354414d503a or 5354414d50533a in the decoded output we have found STAMP: or STAMPS:, respectively (with lowercase variants 7374616d703a for stamp: and 7374616d70733a for stamps:). It's the description field where further decoding or interpretation is clearly necessary; we see the STAMP: prefix following by a bunch of random characters. These random characters are actually base64 encoded data of an image:

"encoding an image's binary content to a base64 string, placing this string as a suffix to STAMP: in a transaction's description key, and then broadcasting it using the Counterparty protocol onto the Bitcoin ledger... STAMP:<base64 data>"

Typically, there would be some "magic bytes" or MIME-type and encoding for image data, but the rationale for the absence of this data in Bitcoin Stamps payloads was given as:

• "The fewer the bytes the better."
• "Given the limited scope of acceptable file formats, we are confident that decoding them accurately based on the base64 string alone is trivial."
• "We are only interested in decoding base64, so if the string does not conform to valid base64 it is rejected. Therefore, specification of the encoding is unnecessary."

Anyway, before we deal with the base64 we need to handle the other P2MS outputs. It can perhaps be inferred from the 2nd and 3rd P2MS outputs above that each P2MS output will have the CNTRPRTY identifier (prefixed by a length prefix). That is, each P2MS output has 9 bytes (1 length prefix, 8 CNTRPRTY) reserved for the Counterparty protocol, so the true data carrying capacity is only: (62 - 9)/62 = 85.4%. This is probably one reason why Bitcoin Stamps opted for a new protocol - improve efficiency by not requiring a length prefix and CNTRPRTY identifier in each P2MS output.

Once we've stripped all length prefixes and CNTRPRTY identifiers from all the deobfuscated P2MS outputs and concatenated them, we end up with 4,004 bytes of base64 data which decodes to a 3,003-byte GIF. The size discrepancy is base64 encoding overhead: every 4 base64 characters is 3 bytes of binary data, so 4,004 / 4 = 1,001 groups x 3 = 3,003 bytes. The recovered image is shown in Figure 5.

This example has shown how Bitcoin Stamps created 77 P2MS unspendable outputs in transaction 54fdeda9... for the purpose of storing a single 3kB GIF.

Counterparty

We began our exploration of data carrying in P2MS with Bitcoin Stamps because this protocol is both the most prolific user of P2MS for data carrying purposes, and is largely the only protocol still in active use today. It started, however, with Classic Stamps leveraging Counterparty, which was the first protocol to start using P2MS for data carrying purposes in a significant way back in 2014.

We won't dwell much on the history of Counterparty here, it's incredibly well documented elsewhere, including:

• BitMEX Research - Battle of the Dexes (September 2020)
• BitMEX Research - The OP_Return Wars of 2014 – Dapps Vs Bitcoin Transactions (July 2022)

It is, however perhaps worth noting that Counterparty, via the adoption of P2MS for data carrying, was a key factor in the decision make OP_RETURN transactions standard in Bitcoin Core 0.9.0 (March 2014):

"On OP_RETURN: There was been (sic) some confusion and misunderstanding in the community, regarding the OP_RETURN feature in 0.9 and data in the blockchain. This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin’s UTXO database."

"Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere."

Counterparty was created to enable features like user-created tokens (assets), decentralised exchanges ("dexes"), and other financial primitives without requiring changes to the Bitcoin protocol. By encoding its protocol messages in Bitcoin transactions, Counterparty leveraged Bitcoin's security and immutability to create a financial platform on top of Bitcoin. The protocol initially used P2MS outputs for data embedding before transitioning to OP_RETURN outputs once they became standard, though P2MS continued to be used for larger transactions that exceeded OP_RETURN's (standardness) size limits. Counterparty's approach was influential in demonstrating both the potential and controversy of using Bitcoin for purposes beyond simple value transfer.

Counterparty is also of some importance in being the single largest example of proof-of-burn in Bitcoin. Proof-of-burn was seen as a way to bootstrap the Counterparty ecosystem without requiring an ICO or pre-mining, which were common practices at the time. Proof-of-burn involves sending Bitcoin to an unspendable address, effectively "burning" the Bitcoin, and, in the Counterparty case, receiving Counterparty (XCP) tokens in return. During January 2014, Counterparty distributed XCP tokens to those who sent Bitcoin to the provably unspendable 1CounterpartyXXXXXXXXXXXXXXXUWLpVr address. To date, 2,130.99165372 Bitcoin has been permanently destroyed in being sent to this address.

Embedding Counterparty transactions in Bitcoin

In general, to know if a transaction involving P2MS outputs is a Counterparty transaction, we actually have to treat the transaction data in a number of different ways. The majority of Counterparty data is, like Bitcoin Stamps, obfuscated by ARC4, keyed with the TXID of the first input (vin[0]). However, unlike Bitcoin Stamps, there is no Key Burn key that provides a simple indication that a transaction is a Counterparty transaction; keys in Counterparty are either valid public keys or are data-carrying.

There is a minority of Counterparty transactions that does not, however, use ARC4 obfuscation, and all that is required is simple ASCII decoding. An example of such is outlined in Counterparty - no ARC4 obfuscation.

Regardless of whether there is ARC4 obfuscation or not, the definitive indication that a Bitcoin transaction is a Counterparty transaction is if the string CNTRPRTY is present in the data. For the majority of Counterparty transactions involving ARC4, the deobfuscation process is necessary before CNTRPRTY can be detected, for those lacking ARC4 obfuscation, it is relatively straightforward to identify the CNTRPRTY prefix via ASCII decoding of P2MS data keys.

In addition to there being a mix of data-encoding techniques, Counterparty also (primarily) uses both 1-of-2 and 1-of-3 P2MS transaction outputs. Depending on which, and when the Counterparty transaction was constructed, the real pubkey is in a different position:

• for 1-of-2, the real pubkey is the first of the two keys
• for 1-of-3, the real pubkey is either the first (newer) or last (older) of the three keys

Being a real pubkey, and with each multisig requiring one key to spend, most Counterparty UTXOs can be spent, and thus removed from the UTXO set. Contrast this with Bitcoin Stamps, where the keys are either Key Burn or data keys thus no private key exists to spend the UTXO, so they will remain in the UTXO set.

The remaining key(s) in each configuration are the data carrying component. And again, depending on which particular variant of the Counterparty protocol we're dealing with, we may need to strip the first and last bytes from a pubkey like was necessary for Bitcoin Stamps, or no such stripping is required, and entire key encodes data.

The current, official Counterparty protocol specification states the following:

For identification purposes, every Counterparty transaction’s ‘data’ field is prefixed by the string CNTRPRTY, encoded in UTF‐8. This string is long enough that transactions with outputs containing pseudo‐random data cannot be mistaken for valid Counterparty transactions. In testing (i.e. using the TESTCOIN Counterparty network on any blockchain), this string is ‘XX’.

Counterparty data may be stored in three different types of outputs, or in some combinations of those formats. All of the data is obfuscated by ARC4 using the transaction identifier (TXID) of the first unspent transaction output (UTXO) as the obfuscation key.

Multi‐signature data outputs are one‐of‐three outputs where the first public key is that of the sender, so that the value of the output is redeemable, and the second two public keys encode the data, zero‐padded and prefixed with a length byte.

The following examples examine a few Counterparty transactions that use some of the various methods described above to encode a variety of data in P2MS transactions.

Counterparty - no ARC4 obfuscation

EXAMPLE: Counterparty - no ARC4 obfuscation

Let's look at an example of a simple Counterparty transaction from block 290,929, 585f50f1... that has a single 1-of-2 P2MS output. For this transaction, the two keys are:

• 02dd842167b625c60c10eda494eadd54df7b30f372d717b946b1912f0ce59dddf6
• 1c434e5452505254590000000000000000000000010000000001312d0000000000

Even from just looking at these keys, it should be pretty obvious that the second is likely not a real pubkey! If we try to decode this 2nd key as ASCII we can immediately observe CNTRPRTY in the output. For completeness, breaking it down (using knowledge of Counterparty message structure) we have:

Counterparty - ARC4 obfuscation

EXAMPLE: Counterparty - ARC4 obfuscation

Here's an example of another relatively simple Counterparty transaction, this time from block 368,602, 541e640f.... This transaction has two 1-of-3 P2MS outputs. On the question of which key position represents the real pubkey, upon examination it's clear that the last of the three keys in each P2MS output is the real key as we have the same key present in both outputs: 0241e401...ee1f). This is sender's public key, as can be confirmed by examining the ScriptSig of the transaction input in Figure 6 with the key highlighted in yellow.

If we follow a process similar to the original Bitcoin Stamps example, we end up with:

• a deobfuscation key of de3dec665a89228593ffa3c0236dd098a6f9ef6ac698db016f8a3303ce728649 (TXID of first input)
• a 124-byte string from a concatenation of the stripped keys of 026e8c99cf905947... + 020b446132ea04f4... + 02498c99cf905947... + 030b446132ea04f4...

After ARC4 deobfuscation, each P2MS output contains its own length-prefixed segment with a CNTRPRTY header:

First P2MS output (62 bytes):

Second P2MS output (62 bytes):

The complete Counterparty message is reconstructed by reading each length-prefixed segment, verifying the CNTRPRTY header, and concatenating the following data. This structure allows messages to span multiple P2MS outputs while maintaining independent validation of each segment. Associated with this transaction is a vanity address, 1SaLvationGodsMarveLousGracaLgYQS, which is the first transaction output.

And, for sake of completeness, here's some links to this transaction and "asset" (SALVATION).

Omni (formerly Mastercoin)

The Omni Protocol, originally known as Mastercoin, was the pioneering protocol for building a layer on top of Bitcoin - it predated Counterparty! Created by J.R. Willett and detailed in his January 2012 whitepaper "The Second Bitcoin Whitepaper", Mastercoin sought to extend Bitcoin's functionality to enable more complex financial instruments and smart property without requiring any modifications to Bitcoin itself.

The project went live in August 2013 via the Mastercoin Crowdsale with MSC tokens generated during the month of August 2013 when individuals sent bitcoin to the Mastercoin (vanity) "Exodus Address": 1EXoDusj.... To date, 6,674.36781069 BTC have been sent to this address.

Mastercoin had a somewhat rocky history, check out the June 2014 Forbes article The First 'Bitcoin 2.0' Crowd Sale Was A Wildly Successful $7 Million Disaster for some early context, but despite this, it has had a lasting impact on Bitcoin. Most prominently Tether (USDT) launched on the Mastercoin protocol as "Realcoin" and, for years, billions of dollars worth of USDT transactions were embedded in Bitcoin's blockchain via Mastercoin/Omni transactions. Mastercoin was re-branded to Omni in 2015, likely to cast off some of the negative connotations associated with the Mastercoin project.

Embedding Omni transactions in Bitcoin

The Omni protocol specifies three different ways to embed data in the Bitcoin blockchain:

1. Class A transactions - use fake addresses
2. Class B transactions - use multi-signature transactions
3. Class C transactions - use OP_RETURN such that Omni Protocol data is completely prunable. This class was introduced with re-introduction of OP_RETURN in Bitcoin Core in version 0.9.0 (March 2014).

The focus here is then on Class B Omni transactions, which are still used to this day for large transactions that do not fit within the (previous) default OP_RETURN policy limit specified by a majority of the network (e.g., 80 bytes).

According to the Omni specification, the first pubkey in each Omni transaction P2MS transaction output "should be a valid public key address designated by the sender which may be used to reclaim the bitcoin assigned to the output". The remaining key (in a 1-of-2) or keys (in a 1-of-3) must be compressed public keys, where each 33-byte compressed public key encapsulates an Omni Protocol packet.

After stripping the first and last bytes, the first byte of each 31-byte "packet", is a sequence number which is used to order the packets. This can range between 1 and 255, which implies:

• There's 30 usable bytes per-packet (per data key) for Omni Protocol transaction data
• There's 255 x 30 = 7,650 bytes maximum data storage capacity for each Class B Omni transaction

To encode data in each packet, the sender's address is used, where the sender's address is the address that contributed the most input value. The sender's address must be a P2PKH address, and:

"Obfuscation is performed by SHA256 hashing the sender's address S times (where S is the sequence number) and taking the first 31 bytes of the resulting hash and XORing with the 31-byte Omni packet. Multiple SHA256 passes are performed against an uppercase hex representation of the previous hash."

Omni - Single Packet

EXAMPLE: Omni - Single Packet

0000297b... is an Omni transaction with a single, 1-of-2 P2MS output in block 323,250. It has an uncompressed (65-byte) key as the first pubkey, and a compressed (33-byte) key as the second pubkey. The first pubkey is the valid pubkey, so this (currently unspent) P2MS output of 5,678 sats could presumably be spent at some point. The second pubkey encapsulates the single Omni Protocol packet for this Omni transaction.

There are 7 transaction inputs, all are contributed by the 1MaStErt4XsYHPwfrN9TpgdURLhHTdMenH address, so this is the sender's address.

To decode, we take the sender's address, apply SHA256 once, and obtain the first 31 bytes of the hash result:

2c7f68ac457d834fb57a112f3571d63bb6365d4c0523f9f74b298096160a02

Taking the second, data carrying pubkey and stripping the first and last bytes yields:

2d7f68ac457d834fb67a112f3571da0eb6365d4c0523f9f74b298096160a02

XORing these two 31-byte strings results in:

01000000000000000300000000000c35000000000000000000000000000000

This breaks down to:

This is the official list for the mapping between Currency ID value and name.

Omni - Multi Packet

EXAMPLE: Omni - Multi Packet

A very recent (25 June 2025!) example of an Omni transaction involving multiple P2MS transaction outputs, and thus multiple Omni packets, is 15309186....

The main difference from the single packet example above is that for each subsequent pubkey, we need to apply SHA256 once more to the sender's address. So with a sender's address of 1D6oYjFVRAETW1Us9oS36YC71gfRw1omZB, and there being 6 P2MS transaction outputs (the first 5 are 1-of-3, the last is a 1-of-2), we have 11 full 32-byte SHA256 results, with the index indicating the number of SHA256 rounds (remembering to convert to uppercase hex representation before each round):

1. x573a09227032f2dde9d2ecf3ffd930d69276754c3bc4343b01c14e0515741fa0
2. bc9197079fb1e344370ab8ee984291f1a3721b37901484dfb2079a158adc5e30
3. 5439114b4688ba1e4e88ecb1454e7b147c886979b2e817082188b083d21fd871
4. cba80dd14016ec8be4cb466affa23d09f2418a361dbad0b3cebffcca473a6e90
5. 834bdf87e79fd15dd54190a478e4f6e9a82a65e5e1220368405099064ad75dfd
6. aa5cfb1d38ad07a94a6986d4101082b673465f528c50efd8710bcf5ace2114dd
7. aafcd59c4c16f69343db9aac1091e0aa0b672efc66272b74870e84207986c9f5
8. 9fb030e442bdfd7ee7cd0c2fbbd801381cb49f04ba11bc1c3ab68a435f8b5806
9. 43fdd5998b69475c6416789a441cb8b897417a8b55cc0e684fe43e295f682bd7
10. a1c0f8d8c283565b31db64d205b403fcd96fbb62a6abe25c60a7bb57e751028e
11. b2573c41dd7e13da76fa530f1f48a3a1df4217b362c59a8bcead0135905ac09b

Dropping the last byte of each hash, and then XORing with the first-and-last-byte stripped compressed keys yields the following. We can see that the data has been successfully deobfuscated as the leading byte, the sequence number, ranges from 1 (01) through 11 (0b).

1. 010000003202000200000000456475636174696f6e004f7468657200416e75
2. 02436f696e0068747470733a2f2f75756367612e636f6d2f616e75636f696e
3. 037768697465706170657200416e75436f696e206973206120736163726564
4. 042063757272656e637920666f7220706c616e657461727920726562697274
5. 05682c206261636b656420627920746865204b756b756c6b616e20436f6465
6. 06782e204974206272696467657320736f756c20736f7665726569676e7479
7. 072c20626c6f636b636861696e20696e746567726974792c20616e6420636f
8. 08736d69632072656d656d6272616e636520666f7220616c6c206265696e67
9. 09732077616c6b696e67207468652070617468206f66207370697269747561
10. 0a6c206c6967687420616e642067616c616374696320416e756e6e616b6920
11. 0b656e6c69676874656e6d656e742e00000000035a4e900000000000000000

Removing sequence numbers, but still accounting for original byte position in the first packet, this breaks down to:

Continuing with the last 3 bytes (28-30, 416e75) concatenated to the second packet (sans sequence number):

Next up is the Property URL, which is the remainder of the second packet (6-30) and into the third packet (1-10). We reach the end when we hit the null terminator 00 (byte 11).

This is followed by Property Data, which extends from packet 3 through to packet 11, ending at the null terminator (byte 15):

As per the Omni spec for the number of coins "for divisible coins or tokens, the value in this field is to be divided by 100,000,000", so there are actually only 144 units of this "AnuCoin". And the sender was perhaps very impatient for the world to hear about "AnuCoin", significantly over-paying to get the transaction confirmed quickly:

Again, by no means being any form of endorsement, here are full details relating to this property/asset on Omni.

Other variants or protocols

As documented in Part 2, Bitcoin Stamps, Counterparty and Omni are the dominant protocols that utilise P2MS outputs for data carrying purposes, combined accounting for over 98% of P2MS outputs in the UTXO set. Yet there are other approaches and minor protocols that also use P2MS outputs to carry data:

1. Minor standalone protocols: Protocols with their own identifiers embedded in P2MS data: PPk (PPkPub), Chancecoin (CHANCECO), TB0001, TEST01, METROXMN
2. Hybrid OP_RETURN signalling: Protocols that use OP_RETURN for identification alongside P2MS for data storage
3. Generic data storage: Direct data embedding without protocol layers

These other identifier patterns or protocols can often be simply identified by ASCII interpretation of the P2MS key data, or data of other outputs (OP_RETURN), though sometimes they have binary formats for messages.

PPk (PPkPub)

PPk (PPkPub) was a blockchain infrastructure protocol developed by researchers at Beijing University of Posts and Telecommunications between 2016-2019, designed to create a decentralized naming and identity system built on Bitcoin (see English documentation). The protocol appears to have been abandoned since 2019.

The protocol used so-called ODIN (Open Data Index Name) identifiers to reference resources stored in Bitcoin transactions. The naming structure follows the format ppk:[BTC_BLOCK_HEIGHT].[BTC_TRANS_INDEX]/[DSS]. For example, ppk:426896.1290/message.txt points to TXID a7fcc739... at position 1290 in block 426,896, with message.txt as the Data Source Suffix (DSS), which is basically an (optional) resource path.

So given ppk:426896.1290/message.txt, anyone can locate block 426,896, find transaction at position 1290, detect the PPk marker, extract the payload, and decode the message. This design leverages Bitcoin "blockchain coordinates" (block height, transaction index within block) as a naming system: globally unique (no collision risk), deterministic, independently verifiable (anyone can reconstruct it), decentralised (no central registry), and immutable (unchanging once mined).

ODINs are retroactive identifiers constructed from these "blockchain coordinates" after mining (not embedded beforehand). When created, PPk transactions contain only the JSON data payload, in the form of title registration (RT), registration information, or message text, split across P2MS and OP_RETURN outputs, plus a distinctive marker pubkey (0320a0de...3e12) at position 2 in the P2MS output. No block height, transaction index, or ODIN appears in the transaction itself.

Decoders construct the ODIN deterministically by detecting the marker pubkey, extracting the payload from P2MS and OP_RETURN outputs, inferring the resource path from payload type (RT becomes profile.json, registration data becomes, for example, reg_315.txt, messages become message.txt), looking up "blockchain coordinates", and constructing ppk:[height].[index]/[path]. Data is unobfuscated and directly readable and both 1-of-2 and 1-of-3 multisig configurations are used.

Chancecoin

Chancecoin was a gambling protocol built on Bitcoin, only active for a short period in 2014, that used P2MS outputs for data carrying purposes in some circumstances. Like Counterparty, users were required to send bitcoin to a specific address, between certain dates, to obtain "Chancecoin tokens". In this case the address was 1ChancecoinXXXXXXXXXXXXXXXXXZELUFD. To date, 480.19571581 BTC have been sent to it.

Key characteristics:

• CHANCECO identifier present in ASCII interpretation, data is not obfuscated
• Uses 1-of-2 P2MS outputs, data is in the 2nd pubkey, the 1st is a valid pubkey
• Each Chancecoin P2MS output has 32 bytes data carrying capability
• Large Chancecoin messages are split across multiple P2MS outputs
• Message format: [CHANCECO:8][MessageID:4][Data:variable]

ASCII identifier patterns

Other identifier patterns that have been observed in P2MS outputs in the UTXO set by simple ASCII decoding include TB0001, TEST01, METROXMN. There doesn't appear to be much information online about these identifiers, with the exception of METROXMN which is associated with Metronotes XMN, which unequivocally appears to be a scam.

Although the identifiers are not obfuscated, the data that follows is likely representing some form of protocol or message format like the other data carrying methods. In the companion repository, unlike the other protocols discussed here, no attempt has been made to interpret or decode the data beyond the identifier.

OP_RETURN signalling

Some protocols employ a hybrid approach, using OP_RETURN outputs to signal or identify the protocol, while simultaneously using P2MS outputs to carry the actual data payload. This dual-output pattern provides explicit protocol identification through the OP_RETURN marker, while the larger data carrying capacity of P2MS outputs is used for the message content. Three distinct variants have been identified in the UTXO set using this approach:

• "Protocol 47930" (0xbb3a marker) uses a 2-byte OP_RETURN prefix (0xbb3a) alongside 2-of-2 multisig outputs.
• "RT Protocol" employs an ASCII RT identifier in its OP_RETURN output, paired with 1-of-2 multisig data storage.
• "CLIPPERZ" is a password manager service that used Bitcoin's blockchain for encrypted data backup and notarization, creating OP_RETURN outputs containing CLIPPERZ alongside 2-of-2 multisig outputs. The OP_RETURN serves as an explicit protocol declaration, avoiding ambiguity in classification, while the P2MS outputs function as the primary data carrier.

Generic Data Storage

Data carrying in P2MS outputs need not rely on some standardised protocol and indeed there are many files (documents, images, etc.) and text, encoded, with or without any obfuscation, into P2MS pubkeys.

There are many examples of using P2MS outputs for generic data storage, but perhaps the most famous two are:

1. The Bitcoin Whitepaper PDF - a single transaction
2. The Wikileaks Cablegate data - uses multiple transactions

Both of these examples, and many other instances of Bitcoin transaction data being used for generic data storage are very well documented by Ken Shirriff in Hidden surprises in the Bitcoin blockchain and how they are stored: Nelson Mandela, Wikileaks, photos, and Python software and Ciro Santilli in Cool data embedded in the Bitcoin blockchain: Ciro's Bitcoin Inscription Museum. For the purposes of understanding how P2MS outputs have been used for generic data storage, we'll examine how we can extract the Bitcoin Whitepaper PDF.

The Bitcoin whitepaper PDF

The following works through the process of extracting the Bitcoin whitepaper PDF from the transaction 54e48e5f... in block 230,009 (April 2013). Note that this is also documented in various places online, including some elegant one-liners on Bitcoin Stack Exchange

EXAMPLE: Generic Data Storage - The Bitcoin Whitepaper PDF

One of the most famous examples of data embedding in Bitcoin is the Bitcoin whitepaper PDF embedded in transaction 54e48e5f.... This transaction has 948 outputs, 946 of which are 1-of-3 P2MS outputs, with the remaining two outputs being standard P2PKH outputs. All pubkeys involved are also 65-byte uncompressed pubkeys, presumably to maximise data carrying capacity. Unlike the protocol-based approaches we've examined (Bitcoin Stamps, Counterparty, Omni), this is a straightforward generic data storage example with no obfuscation or encryption.

Examining the first output (vout[0]) as in Figure 8 we can see that the 1-of-3 P2MS output uses full 65-byte uncompressed pubkeys. With uncompressed pubkeys, typically starting with an 04 prefix, yet none of these keys starting with 04, we know that none of these keys are valid pubkeys, and thus this P2MS output is unspendable. If we were to examine the remaining 945 P2MS outputs, we would see the same pattern: all 3 keys in each output are uncompressed pubkeys, and none of which are valid pubkeys.

The extraction is simpler than protocol-based approaches:

Step 1: Extract all pubkey data

For each of the 946 P2MS outputs, concatenate all three 65-byte chunks:

• Output 0: e4cf0200... + 636f6465... + 9ba54728... = 195 bytes
• Output 1: f4eb5fde... + 1f3fe4ab... + 7395c3c8... = 195 bytes
• ...continue for all 946 outputs
• Total concatenated data: 946 × 195 = 184,470 bytes

Step 2: Detect the file type

Scanning the concatenated data reveals the PDF magic bytes %PDF (hex: 25 50 44 46) at a specific offset:

Byte position 0-7:   e4 cf 02 00 06 7d af 13  (8-byte prefix)
Byte position 8-15:  25 50 44 46 2d 31 2e 34  (%PDF-1.4)

Step 3: Localise the PDF content

The PDF data is located at the following byte positions in the raw data:

• Byte 8: %PDF-1.4\n - PDF header starts
• Bytes 184,294-184,298: %%EOF - End-of-file marker (5 bytes: hex 25 25 45 4f 46)
• Byte 184,299: \n - Final newline after EOF (hex 0a)
• Bytes 184,300-184,469: Null padding (170 bytes)

Step 4: Trim leading and trailing data, extract PDF

• Total bytes to remove: 178 bytes (8 byte prefix + 170 bytes null padding)
• Byte 0: %PDF-1.4\n - PDF header (8-byte prefix removed, now at position 0)
• Bytes 184,286-184,290: %%EOF - EOF marker (5 bytes)
• Byte 184,291: \n - Final newline (hex 0a)
• Total size: 184,292 bytes

The final extracted PDF is exactly 184,292 bytes and can be saved as a valid PDF file.

Summarising the main techniques

In the post we've explored the main methods of how data is carried in P2MS transaction outputs, including working through examples that showed how the various protocols or methods operate. The dominant protocols, Bitcoin Stamps, Counterparty, and Omni, account for over 94% of all P2MS UTXOs (as we shall learn in Part 2), with the following summarising the key technical distinctions between them.

Protocol identification: Bitcoin Stamps can often be identified without deobfuscation via Key Burn patterns, while Counterparty requires attempting deobfuscation to find the CNTRPRTY prefix. Omni transactions are identified by the presence of the Exodus address as one of the transaction outputs.

Obfuscation techniques: Bitcoin Stamps and Counterparty both use ARC4 stream cipher obfuscation with the input TXID as the key, whereas Omni uses SHA256 hashing with XOR operations (and generic data storage often uses no obfuscation at all, with the data embedded directly in pubkey).

Spendability vs. permanence: Bitcoin Stamps deliberately creates unspendable outputs in using no real pubkeys, ensuring the data remains in the UTXO set forever. Counterparty and Omni, by contrast, include a valid pubkey that allows each output to be spent, theoretically enabling UTXO set cleanup (though, in practice, many remain unspent years after being created).

Data density & efficiency: All three protocols achieve roughly similar density per pubkey (30-31 usable bytes), though older non-ARC4 obfuscated Counterparty transactions use all 33 bytes of a 33-byte compressed pubkey. The efficiency of the Counterparty protocol is lower than the other two due to per-output headers (losing 9 bytes per output), Omni achieves decent efficiency by using 30 of 31 bytes of each stripped pubkey (losing 1 byte per pubkey), and Bitcoin Stamps achieves the highest efficiency by using all bytes in 2nd and subsequent P2MS outputs for data.

Table 1: Comparison of the technical details of the major P2MS-using protocols.

Beyond these three major protocols, we also see P2MS transaction outputs leveraged by minor protocols. PPk (PPkPub) uses a distinctive hybrid approach with a marker pubkey in P2MS outputs combined with protocol data in OP_RETURN outputs. Other minor protocols include Chancecoin and projects with identifiers TB0001, TEST01 and METROXMN. Additional hybrid OP_RETURN + P2MS protocols exist, such as "Protocol 47930" (with 0xbb3a marker) and CLIPPERZ. In addition, P2MS transaction outputs have been used for generic data storage, with prominent examples including the Bitcoin whitepaper PDF and the Wikileaks Cablegate files. Such examples demonstrate that P2MS can be used for arbitrary file storage without any standardised protocol layer.

What's next?

These technical approaches each make different tradeoffs between efficiency, permanence, and network impact. But understanding the mechanics is only part of the story - the critical question is: what is the actual scale and cumulative impact of these techniques on the Bitcoin network? Part 2 analyses historical trends and a snapshot of the UTXO set to quantify the magnitude of P2MS data carriage in Bitcoin.

Also be sure to check out the companion GitHub repo which includes a decode-txid utility that can be used to decode transactions involving P2MS outputs according to various protocol described above (including some support for generic data storage).

References

General

• deadmanoz Data Carry Research (GitHub companion repository)
• ARC4 (RC4)
• Bitcoin Stamps Protocol Specification
• Bitcoin Stamps: Key Burn
• Bitcoin Stamps Indexer
• Bitcoin Stamps SDK Documentation
• OpenStamp
• BRC-20 Tokens: A Primer
• Counterparty - Pioneering Peer-to-Peer Finance - Official Thread
• Counterparty Protocol Specification
• Counterparty Core
• Counterparty Decoder
• How to Reverse Engineer Counterparty TX’s
• MasterCoin: New Protocol Layer Starting From “The Exodus Address”
• Omni Layer Specification (0.7)
• The First 'Bitcoin 2.0' Crowd Sale Was A Wildly Successful $7 Million Disaster
• Mastercoin crypto: the story of the communication protocol based on Bitcoin, which later became Omni
• Tether (USDT) History
• Hidden surprises in the Bitcoin blockchain and how they are stored: Nelson Mandela, Wikileaks, photos, and Python software
• Cool data embedded in the Bitcoin blockchain: Ciro's Bitcoin Inscription Museum

Academic Research

• Data Insertion in Bitcoin's Blockchain (2017)
• A Quantitative Analysis of the Impact of Arbitrary Blockchain Content on Bitcoin (2018)
• Analysing blockchains and smart contracts: tools and techniques (2018, PhD thesis)
• A journey into Bitcoin metadata (2019)
• Dominating OP Returns: The Impact of Omni and Veriblock on Bitcoin (2020)
• An Analysis of Data Hidden In Bitcoin Addresses (2021)
• Bitcoin Burn Addresses: Unveiling the Permanent Losses and Their Underlying Causes (2025)

Changelog

• 2025-11-24: Added PPk