pull down to refresh

P2MS Data Carry Part 2: UTXO set analysis - @deadmanoz deadmanoz.xyz/posts/p2ms-data-carry-2

438 sats \ 12 comments \ @Scoresby 15h bitcoin

zaps forwarded to @deadmanoz (100%)

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.

I suppose this was obvious. I mean, who is using P2MS any more? But it's very cool to see someone look at the actual numbers.

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.

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

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

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.

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.

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.

Very interesting read! Check out the whole post.

Also, I had not visited @deadmanoz's site before: it's awesome!

view all related items

2357 sats \ 1 reply \ @deadmanoz fwd 9h

Thanks @Scoresby, I was gonna post this on here today!

0 sats \ 0 replies \ @Scoresby OP 9h

It's excellent research! Sorry to steal your thunder, but I was really interested in this!

323 sats \ 3 replies \ @Murch 14h

The perfidious aspect of Stamps is that they are spendable. They’re 1-of-3 bare multisigs, where the first public key is an actual key and the other two public keys are used to embed data. They cannot be pruned, because they could be spent later, and when they are, the network may be split if nodes evaluate the spend inconsistently as valid or invalid.

21 sats \ 2 replies \ @Scoresby OP 14h

How would one know the difference between a 1-of-3 bare multisig where no keys are real and where 1 key is real?

223 sats \ 1 reply \ @Murch 13h

Secp256k1 is defined over a finite field. Only most, but not all of the 32-byte numbers are valid x-coordinates of public keys. If all three public keys were not on the curve, it would be obvious that the TXO is unspendable, but alas, if the key is on the curve, we cannot distinguish whether the private key is known or not.

So, for most we cannot, but my understanding is that the way stamps are interpreted according to those that wear these particular colored glasses, they only read the latter two public keys as data.

123 sats \ 0 replies \ @deadmanoz fwd 8h

Hey @Murch, you're right — I thought I had tidied up all the misuse of provably unspendable but I must have missed some. My apologies! Stamps are not provably unspendable, but they are deliberately unspendable by design. In each 1-of-3:

1 key is the "Key Burn" e.g., 022222222222222222222222222222222222222222222222222222222222222222. It's a valid EC point, but a NUMS point: no one has the corresponding private key.
2 keys are data-carrying. These may or may not be valid EC points. In Part 1, I show an example where one data-carrying point is valid and the other is not.

The point is not about validating keys - there's been extensive discussion on this, and we know key validation is insufficient for determining whether a point is data-carrying. But we do know that Bitcoin Stamps are deliberately unspendable by design, and we can incorporate this into our analysis.

The other relevant observations are:

Empirically, P2MS no longer serves its original purpose of multisig custody.
Bitcoin Stamps is almost exclusively the only user of P2MS since early 2023.
Since early 2024, Stamps' use of P2MS has been for JSON payloads only.

I am not advocating for touching existing P2MS outputs, confiscation, or anything of the sort.

I'm simply presenting how data-carrying protocols have leveraged P2MS, their design decisions, and what the data shows about how P2MS has been, and continues to be, used.

From this, I'm asking:

Is P2MS serving its intended purpose?
Is the observed use worth maintaining the status quo, or do we consider P2MS for deprecation?
And more pointedly, should we encourage Bitcoin Stamps to consider using OP_RETURN instead, given that the project's original rationale for permanence and art is no longer being met?

102 sats \ 2 replies \ @standardcrypto 9h

no no no.

It's the exact opposite of what you would think with all this pearl clutching.

the utxo set should be spammed as hard as possible as fast as possible for 2 key reasons -- secure hashrate by paying miners when demand for vanilla monetary transactions is low (less important) -- demonstrate that utxo bloat is in practice unavoidable and force bitcoin to adapt to it asap, rather than pretending that this issue is solvable (more important)

10 sats \ 1 reply \ @deadmanoz fwd 8h

I don't own any pearls!

How about Bitcoin Stamps use OP_RETURN instead of P2MS for their JSON payloads?

0 sats \ 0 replies \ @standardcrypto 4h

OP_RETURN doesn't bloat the utxo set as much, so it's not doing god's work.

Or, I guess to say it less provacative, it's not doing god's work as effectively.

165 sats \ 0 replies \ @047b99aa4d 14h

Would you look at that? A reasoned and fact based investigation of an issue and a sensible and cautious plan to find concensus around deprecating a feature that is damaging to the Bitcoin network that minimizes side effects. What a radical idea...

0 sats \ 1 reply \ @Filiprogrammer 10h

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.

Yes! And should also probably include P2PK.

10 sats \ 0 replies \ @deadmanoz fwd 8h

A separate matter, but yes!