can definitely agree there, but again you are now assuming that the next shitcoin group won’t pop up and find a new non-standard abuse to exploit.
we should not accommodate these behaviors and introduce an incentive to attack bitcoin to get devs to ack changes that are “technically sound”
That just makes no sense.
You just dislike shitcoins more than you want to protect bitcoin
low key fire and I will self reflect on this..
To be fair eventually P2WSH can be used for data storage. Or P2WPKH. Or P2SH. Or P2anything.
What I still don’t understand is:
- What’s the point of OP_RETURN size increases? Inscriptions are cheaper.
- Why not disable P2MS?
Which is why we should make op return the best way to do it because we can actually prune the data
Okay, we can prune the data. But why do Stamps exist? Exactly because P2MS is not disabled, and people want it to be unprunable…
And Inscriptions are cheaper and prunable as well
Op return is the least destructive way to store data. Sure other ways exist but we should make it so people use the least destructive version
but you aren’t “making it so”.
you are encouraging it.
shitcoiners will abuse what they can still abuse.
They are going to abuse it either way, we can't stop them. So make them do it in a better way
People will not use it until we disable P2MS because it’s a similar cost, but one is “unprunable” so they of course want to do P2MS.
Anyone that cares about cost also uses inscriptions. Those will not switch to OP_RETURN for 4x.
We should at least give them the option
Are we sure anybody is actually doing P2MS because it's unprunable, and not because of the datacarrier limit? (and/or to be jerks)
Yes
What protocol(s) are doing that?
stamps
Fair enough, but stamps uses counterparty, and the counterparty FAQ says this about OP_RETURN and prunability: https://docs.counterparty.io/docs/basics/faq/#what-happens-if-and-when-op_return-data-is-auto-pruned
> Counterparty only needs some Bitcoin full nodes somewhere to have an unpruned copy of the blockchain. As every Counterparty full node is also a Bitcoin full node, this is easily done.
stamps references the counterparty behavior as the reason why stamps uses bare multisig and says
https://github.com/mikeinspace/stamps/blob/main/BitcoinStamps.md
> 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.
Since counterparty refutes/denies the pruning argument, it's IMHO safe to conclude that stamps is actually using bare multisig because of the datacarrier limit anyway.
“prunable OP_RETURN”
That’s the end.
why does citrea exist and not use colored coins?
it’s an observation of path dependency.
citrea abuses the current set of standardness, which only exists because of past ‘exploits’.
changing standards to “fix” this just leads to the next abuse, which leads to the next “fix”.
this is ETH. we don’t want ETH.
