pull down to refresh
1 sat \ 1 reply \ @tidwell OP 5 May \ parent \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
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?
Will Taproot wizards and other spam companies and projects start using OP_RETURN to put jpegs on the blockchain?
Won't large OP_RETURNs allow people to spam the mempool with 100kb transactions and mess up bitcoin for everyone by bloating the mempool and not allowing legitimate transactions in the mempool?
If we prevent these transaction from going into our mempools doesn't that prevent or delay these spam transactions from being mined therefore discouraging the spammers?
Shouldn't we be fighting spam, why are we making policies less strict, shouldn't we be making them more strict?