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?
022222222222222222222222222222222222222222222222222222222222222222. It's a valid EC point, but a NUMS point: no one has the corresponding private key.OP_RETURNinstead, given that the project's original rationale for permanence and art is no longer being met?