P2MS Data Carry Part 2: UTXO set analysis

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

// 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

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);
}

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.

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.

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.

"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.

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.

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 6). 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 7 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.

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

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)

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)

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.

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.

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.

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).

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.

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).

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 8 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.

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 7, 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