#### Nirvana argument: this change is being pushed by people who believe the lack of a perfect solution to fight arbitrary data storage onchain means we should give up fighting it altogether. No. This change is proposed to remove a perverse incentive for applications that want

#### Boiling frog: Core developers are trying to gradually make Bitcoin a universal database instead of just money, one step at a time. This is an unfounded accusation attempting to harm the very people who have been maintaining the Bitcoin network for the past >15 years. By

#### Antoine Poinsot paid Peter Todd to open the pull request to Bitcoin Core. Neither myself, nor any other Bitcoin Core contributor pay Peter Todd to open the Github pull request to Bitcoin Core changing the `OP_RETURN` standardness limits (#32359: https://github.com/bitcoin/bit... I

#### The way this is being rushed is a red flag. None of this is being rushed. Peter Todd initially proposed this change 2 years ago (in https://github.com/bitcoin/bit... My email to the mailing list was on April 17th (@protonmail.com). class="text-blue-500 hover:underline" target="_blank" rel="noopener noreferrer">https://gnusha.org/pi/bitcoind... It received some amount of discussion in

#### While provably unspendable outputs are preferable to dust outputs in some contexts, the absence of any guardrails could make it easier for bad actors to stress the network, especially in combination with existing vulnerabilities. Without a clear definition of what the

#### The `-datacarrier` option should be kept on Bitcoin Core regardless of whether the default is changed. Essentially the argument goes like: > You say that once the default is changed, setting `-datacarrier` on my node will have no observable effect at the network level.

#### I am also concerned that in the future we might see a large scale bypassing of the Core standarness rules, but it’s unclear whether we’ve reached that point yet. We can always reconsider dropping the OP_RETURN limit once it becomes truly problematic - but, and this is a

#### If you don't upgrade Core devs are going to accuse you of censorship. This is a baseless accusation. It cannot be accepted as an argument against raising the standardness limit on the size of `OP_RETURN` outputs. This claim assumes that if newer version of Bitcoin Core

#### Relay filters have historically been successful at preventing "spam". The Bitcoin Core standardness rules have historically matched the demanded usage(s) of the Bitcoin network. There is no evidence of any unwanted usage that was stiffled by tightening standardness rules.

#### Filtering will reduce supply and therefore suppress demand for inscriptions by increasing the cost of using them. This argument posits that 1) additional standardness rules in Bitcoin Core would significantly reduce the availability of inscriptions and 2) that the

Really, if you can you should read it on Delving (it's public). The formatting on here is horrible. https://delvingbitcoin.org/t/a...

@darosior Many recent inscriptions types and metaprotocols (Stamps, BRC-20) are marketed as different "tech" to create market (somewhat artificial) differenciation in an attempt to usher demand for them. How could we expect that alleviating standardness rules for OP_RETURN will not

@theomogenet > it is rather likely that this would incentivize new non-monetary use cases on top of existing ones This remains to be shown. > instead of changing how the current ones are carried out. This is not the goal of the proposal. > instead of reviving their overhyped ponzi by

@darosior One other thought. I don't think it should be Bitcoin's goal to be presenting the most friendly API to developers, or to otherwise try and increase developer activity on chain. Changes should only be made if they are necessary to facilitate Bitcoin's success as sound money.

@RIPreason This is about Bitcoin Core, not Bitcoin. Bitcoin already permits it. This is not an attempt "to increase activity". Unsure how you could ever get that from my post. The activity *will happen regardless* and this is about making it less harmful.

@darosior I have read through most of this thread, although I was fading towards the end. I have some minor quibbles with some arguments made later, but nothing major. However, what I'm seeing here is an argument to raise the limits on OP_RETURN to the maximum of whatever can be currently

@RIPreason Yeah. I think we should remove the paternalistic limits as per the second section, but it is true that there is no known usage for any large OP_RETURN outputs. Enabling them does not hurt though (for large amounts of data people use the witness anyhow) and has the benefit of

@darosior Could you talk to an attack vector made easier by increasing OP_RETURN? The premise is a bad actor determined to slow down acceptance of Bitcoin could flood the network with child porn. What happens?

@flaming_hodl Sure. One good argument is the one raised by @wk057: since the data in an output needs not be chunked, someone could store a child porn image in an OP_RETURN in order to get nodes to store them on their disk. However, this is already possible today and is the reason why Bitcoin

@darosior Not reading this broccoli hair

@darosior "In any case, the limit is not preventing those new applications from relaying their transactions through the public network. They just modify their transactions and use fake public keys instead." How much data are these transactions currently storing in fake public keys

@darosior I have an objection to removing the user's ability to configure limits on OP_RETURN. First of all, just to review, the default value of OP_RETURN will affect whether a developer chooses to take advantage of OP_RETURN for his application, assuming it is a time-sensitive one. As

@darosior @bitschmidty Can you give examples of economic time-sensitive transactions which suffer today from the existing limit?

@darosior > These may be acceptable options for people willing to store arbitrary data, but not for time-sensitive transactions as typically used by Bitcoin scaling solutions I fundamentally disagree with catering to “time-sensitive”designs that require contentious changes like this.

@darosior Thank you for your work Antoine

@darosior So, questions for you Antoine: 1. At best, though op return could be used instead of fake pubkey, this is ultimately only a partial fix correct? This is only effective if all potential user of fake pubkeys instead use op return. 2. Is it truly best to set no limit to op

@darosior This may well addresses technical concerns but completely ignores wider environment Bitcoin operates in. Current reality (not desirable long term) is that there is a handful of mining pools constructing blocks. If this dynamic persists realisting number of entities applying

@darosior They really should just make it a user setting option since none of it is required. Default set to 0.

@darosior Thanks for taking the time to write this up.🙏 It was pretty clear in your original post, and ensuing conversation with other devs, what the intention and reasoning was. It been quite infuriating to see the misrepresentation of it all!

@darosior Thanks for this!

@darosior Thank you for the clarification. Best 👍