Yes. Needed to read this. Totally agree, bitcoin is a monetary network, not a storage system for shitty jpgs and etc. Take that elsewhere.
Discussion
Is that your only takeaway from this?
No, it’s also that transaction fees are the only visible spam prevention mechanism for bitcoin to preserve its decentralized nature.
Yes, the critical misunderstanding is that the Core update isn’t being done to turn bitcoin into a shitcoin-friendly system, it’s an acknowledgement that the desire by some to shitcoin on bitcoin is so persistent that they will always bypass any arbitrary centralized prevention methods, and only a fee market can effectively price them out.
But not by making it easier…
It doesn’t. It just removes the arbitrary method that doesn’t work and is commonly bypassed.
If it’s bypassed it works by definition. If the Core Devs honestly wanted to reduce spam, they should have worked on plugging the holes used when bypassing. For now run Knots to send a message while we need to work on plurality of versions.
> If it (the relay filter) is bypassed, it (the relay filter) works by definition
If by "work", you mean "kill the small miners so that a small cabal of large miners have control of Bitcoin", then I agree that it "works"
You might think I'm being unnecessarily sarcastic here, but for many of us the priority is to keep mining decentralised. Miner decentralisation requires:
- keeping the UTXO set small
- accurate prediction of what the next block will be, to enable small miners to stay at the tip and to enable their blocks to be quickly accepted by everyone else
There are lots of issues to consider, and trade offs, but miner decentralisation is critical and must be part of every debater's calculus.
How is Core keeping the UXTO set small given the witness discount?
Lifting OP_RETURN limits doesn't address the fact that embedding arbitrary data in the witness script is cheaper, meaning that the network would have to rely on the good intentions of the "spammers" to rearrange their higher level protocols to fetch data from the witness script of the transaction instead of from the OP_RETURN output.
You mention the witness discount, but you don't make a clear point
Are you advocating for a fork to remove, or perhaps just decrease, that discount?
I'm open minded about different *realistic* plans to improve the chain - e.g. decreasing the size of the UTXO set - but your response didn't include any practical plan
I was not trying to propose a way forward in that regard to be honest, but I bring it up in relation to the removal of the 80 bytes limits.
I don't think It can be argued that lifting the OP_RETURN limit serves the purpose of mining decentralization thanks to a leaner UTXO set, precisely because of it being more expensive to embed larger arbitrary data in outputs.
Historical developments in Bitcoin Core make me suspicious of the argument that OP_RETURN should have no limits in order to protect the UTXO set. Had this been the goal, Core devs would have tried to somehow contain the effects of ordinals. Since this didn't happen, I can only conclude that v30 is removing this relay policy fllter for other reasons which I do not at this point understand.
With regards to mining decentralization, I think the community should focus its time and energy on StratumV2, but this entails talking to miners and convincing them of the benefits of block template selection etc etc
> Core devs would have tried to somehow contain the effects of ordinals
Be practical. What do you mean here?
Do you mean a fork should have been rushed out to make ordinals non-consensus-valid? If yes, how do you define an 'ordinal'? For the most part, those transactions looked like normal (Taproot) transactions.
In fact, the 'epic ordinals' are simply the first satoshi mined after each halving.
In order to filter out the epic ordinals, *you would have to filter out the coinbase transaction after each halving*!
If you research ordinals, you'll realise there was no quick fix. And even if there was, it's not responsible to rush out a node upgrade every week to try to squash the latest silly hack. It was somewhat obvious that ordinals (and NFTs and so on) were just fads
> Core devs would have tried to somehow contain the effects of ordinals. Since this didn't happen, I can only conclude ....
It *could* be an evil Core-munist conspiracy. Or it could be that the topic of Ordinals requires more subtle thought ...
(Epic ordinals, and other ordinal stuff, are discussed in detail here: https://www.nervos.org/knowledge-base/guide_to_inscriptions)
I was implicitly referring to inscriptions when mentioning ordinals, sorry for the confusion here. What I meant is that when inscriptions became a thing and the PR to filter them was proposed by luke-jr by matching against OP_FALSE OP_IF, why did not Core propose relaxing the OP_RETURN limits then? I'd expect that to have been the rational thing to do given the arguments with respect to UTXO set bloat
I don't think there is any conspiracy on the part of Core, and I appreciate that filtering spam is not some easy task to be carried out over the weekend, but I don't understand the timing for this proposal, unless this is entirely explained by Citrea as its catalyst.
> unless this is entirely explained by Citrea as its catalyst.
You say this as if it's some evil conspiracy
Even though I keep hearing about Citrea, it's difficult to get people to speak factually and with evidence. I've included a screenshot of what appears (after my limited research) to be the link between Citrea and OP_RETURN
We can't just magic away usages of Bitcoin that we don't like. From what I can see, Citrea will either use a large OP_RETURN, or a small OP_RETURN combined with two unspendable outputs. I don't think we can block them from both options; the most we can do is nudge them towards the one that we find less harmful
When relays are strict about filtering, then it means that Citrea will either use unspendable outputs (increasing the size of the UTXO sets) or will pay large miners out-of-band for large OP_RETURNs. Both of those are bad for miner centralization
Again, be practical, and share practical plans and alternatives, bearing in mind that some of us put miner decentralization very high on the list of priorities. Spreading paranoia about complex systems isn't helping anybody

https://blockspace.media/insight/everything-you-need-to-know-about-the-op_return-data-limit-debate/
> You say this as if it's some evil conspiracy
I really am not, in fact I welcome developments such as Citrea and Strata by Alpen Labs. I mentioned Citrea in relation to my other point, which is that I don't understand the timing of this relaxation in relay policy.
Given that preventing the UTXO set from increasing is one of the goals, I am trying to understand how come OP_RETURN limits were not dropped in 2023 when inscriptions were rapidly increasing the UXTO set. Things are complex and I understand that there is not necessarily an answer here, but I am far from suggesting that something shady is going on behind the scenes as an attempt to overthrow Bitcoin or other such things
Thanks for your quick response, and also for being constructive
I think I'm getting tired of other people and their conspiracies, and therefore I'm quick to assume (incorrectly sometimes) that everybody is being irrational.
[I love conspiracies sometimes, and Bitcoin is too important to be based on naivete. We should verify, not trust]
Anyway, to return to the topic:
Inscriptions require *two* transactions usually (or maybe always). Witness data can be attached only to inputs, not outputs. So, in order to attach some witness data (indirectly) on an output, you have to have a second transaction - taking that output as an input - and then attaching the witness data to the second transaction.
I mention this complexity because it might have been another factor in the topic. The Inscriptions folks might have been willing to do this. But maybe more recent use cases require a single-transaction approach and therefore the witness data is unusable and therefore the choice is between a large op_return or unspendable outputs.
[Again, I might be missing some details here. I think I know a lot of these details, but I'm kinda inferring things from multiple different blog posts. I would be happier if a really high quality document about all of this already existed]
My guess is that the truth is something like this: Witness data is the cheapest way to get arbitrary data in the block. But, as it requires two transactions - not just one - it is sometimes impossible for certain use cases. The single-transaction use cases therefore have to choose between a large op_return and unspendable outputs. Reluctantly, in this case we must large op_returns in the mempool if we are serious about miner decentralization.
He said that- nice words, while making excuses for removing a spam filter