pull down to refresh
385 sats \ 14 replies \ @tidwell OP 12 May \ parent \ on: A Comprehensive OP_RETURN Limits Q&A Resource to Combat Misinformation bitcoin
@LibreHans
If you were to ask "is core allowing more spam by removing OP_RETURN limits?" I think they would not agree they are.
Do me a favor, look at questions 2,4,9,19,20,26,27,28.
Is there anything you disagree with in ref to the answers? I would love to make this constructive instead of a "us vs them" sort of thing. Likely we all want something very similar.
question 19 is:
Will Taproot wizards and other spam companies and projects start using OP_RETURN to put jpegs on the blockchain?
Probably closest to really drilling into this and getting the perspective of Udi and Rijndael both active in that question.
:)
Let's not let Murch's work be in vain! Having a common set of facts will only benefit our understanding of the truth and lead to more meaningful conversations. Please share individual links to these threads, where applicable, to help clear up misinformation.
I would argue that the sentiment "it was rushed" is misleading and incorrect. As described, this was discussed on the mailing list, and opening a PR doesn't mean the code is merged or ready. There's also been a misconception that opening a PR means the code is already integrated and the change guaranteed.
I'll add that I verified off-band with someone notable that represents the "Fix the Filters" cause.
The gist I gathered for Fix the Filters:
Adjust relay/mempool policies on nodes to hinder spam on the blockchain without removing existing, functioning filters.
A concern from x from a technical bitcoiner:
"If we open the shitcoin floodgates, which is what removing the opreturn limits does, then fees will go high and stay high forever, drowning out all legitimate onchain activity.
Bitcoin will be impossible to use permissionlessly at that point."
Murch please address this concern.
Culture is what protects Bitcoin from external forces, shouldn't non-technical arguments be valid when considering these types of changes?
Shouldn't we debate the controversy of this PR on Github since it's where the code gets merged to make these changes?
Is it possible to stop the abuse of payment outputs (i.e., bare multisig, fake pubkeys, and fake pubkey hashes) that are used to embed data, thereby creating unprunable UTXOs that bloat the UTXO set?
Is it possible to stop abuse of witness data? If so, how? (i.e ordinal theory inscriptions, "jpegs").
Was this PR initially proposed because of Citrea BitVM needs? If so don't they only need a slight bump in OP_RETURN size, why is it being proposed to make the size unrestricted?
Is allowing standardness for larger OP_RETURNs a slippery slope? If we allow this won't we continue to allow things that make bitcoin less for money and more for arbitrary data?
A similar PR was proposed by Peter Todd 2 years ago, why was it rejected then? What has changed since then, why would this get approved now?