Replying to Avatar calle

This is a long post that hopefully bridges some gaps between technical people (devs) and non-technical users and how they look at spam prevention in Bitcoin. I hope that it clarifies why I think that there is such a huge misunderstanding between both camps.

I'll preface this post with first disqualifying any malicious attempts to misrepresent the motives of either camp. Everybody wants to improve Bitcoin as money. Money is Bitcoin's use case. It's not a data storage system. If you think otherwise, there are countless shitcoins to play with.

Alright, let's get into it.

I have worked on anonymous systems for over a decade. I have read tons of research on spam detection, rate-limiting, and I've implemented spam prevention techniques in the real world.

I am very confident to say that there is not a single known method to prevent spam in decentralized anonymous open networks other than proof of work.

This is what Satoshi realized when he designed Bitcoin and it's why only transaction fees can reliably fight spam without sacrificing any of Bitcoin's properties.

Let me explain.

Spam prevention is a cat and mouse game. As a system's architect, your goal is to make the life of a spammer harder (increase the friction). This is why, on the web, you see captchas, sign-ups, or anything that can artificially slow you down. Slowing down is key. This is why Satoshi turned to proof of work.

Let's contrast this to other methods for spam prevention. This is not an exhaustive list but it illustrates the design space of this problem, other methods are often derivatives of these:

CAPTCHAS are a centralized form of proof of work for humans: Google's servers give you a hard-to-solve task (select all bicycles) that will slow you down so that you can't bombard a website with millions of requests. It requires centralization: you need to prove Google that you're human so that you can use another website. If you could host your own CAPTCHA service, why would anyone believe you're not cheating?

LOGINS with email and passwords are most popular way to slow down users. Before you can sign up, you need to get an email address, and to get an email address, you often need a phone number today. The purpose of this is, again, to slow you down (and to track you to be honest). It only works well when emails are hard to get, i.e. in a centralized web where Google controls how hard it is to get an email account. If you could easily use your own email server, why would anyone believe you're not a bot?

The next one is the most relevant to Bitcoin:

AD BLOCK FILTERS are another form of spam prevention but this time the roles are reversed: you as a user fight against the spam from websites and advertising companies trying to invade your brain. Ad blocking works only under certain conditions: First you need to be able to "spell out" what the spam looks like, i.e. what the filter should filter out. Second, you need to update your filters every time someone circumvents them. Have you ever installed a youtube ad blocker and then noticed that it stops working after a few weeks? That's because you're playing cat-and-mouse with youtube. You block, they circumvent, you update your filters, repeat.

The fact that you need to update your filters is critical and that's where it ties back to Bitcoin: Suppose you have a mempool filter for transactions with a locktime of 21 because some stupid NFT project uses that. You maybe slow them down for a few weeks, but then they notice it and change their locktime to 22. You're back at zero, the spam filter doesn't work anymore. What do you do?

You update your filter! But where do you get your new filter from? You need a governing body, or some centralized entity that keeps updating these filters and you need to download their new rules every single day. That's what ad blockers in your web browser do. They trust a centralized authority to know what's best for you, and blindly accept their new filters. Every single day.

I hope you see the issue here. Nobody should even consider this idea of constantly updating filter rules in Bitcoin. This would give the filter providers a concerning level of power and trust. It would turn Bitcoin into a centrally planned system, the opposite of what makes Bitcoin special.

This is why filters do not work for decentralized anonymous systems. They require a central authority. Until now, these rules were determined by Bitcoin Core, but they have realized that these rules do not work anymore. Transactions bypass the filters easily and at some point, carrying them around became a burden to the node runners themselves. Imagine you're using an outdated ad blocker but instead of filtering out ads, it now also filters out legitimate content you might be interested in. That's what mempool filters do, and that's why Bitcoin Core is slowly relaxing these filters. This has been discussed for over two years, it's not a sudden decision.

The goal of this change is not to help transactions to slip through more easily. The goal is to improve your node's prediction of what is going to be in the next block. Most people misrepresent this part. They say "it's to turn Bitcoin into a shitcoin" but that is just a false statement at best, or a manipulation tactic at worst.

Let's tie it back to proof of work and why fees are the actual filter that keeps Bitcoin secure and prevents spam reasonably well: Satoshi realized that there is no technique that could slow down block production and prevent denial of service attacks in a decentralized system other than proof of work. Fees prevent you from filling blocks with an infinite number of transactions. All the other options would introduce some form of trust or open the door for censorship – nothing works other than proof of work.

He was smart enough to design a system where the proof of work that goes into block production is "minted" into the monetary unit of the system itself: You spend energy, you get sats (mining). This slows down block production. How do you slow down transactions within those blocks? You spend the sats themselves, original earned form block production, as fees for the transactions within the block!

This idea is truly genius and it's the only reason why Bitcoin can exist. All other attempts of creating decentralized money have failed to solve this step. Think about it: without knowing who you are, whether you're one person pretending to be a thousand, or a thousand people pretending to be one. Bitcoin defends itself (and anyone who runs nodes in the Bitcoin system) from spam by making you pay for your activity.

People sometimes counter this by saying: the economic demand for decentralized data storage is higher than the monetary use case. First of all, I think that's just wrong. There are way cheaper ways to store data (there are shitcoins for this), and the value of having decentralized neutral internet money is beyond comparison.

However, there's a much deeper concern here. If you truly believe this, I ask you: what is Bitcoin worth to you? If you think Bitcoin can't succeed as money (i.e. be competitive), why do you even care? If you're not willing to pay fees for the use case that we all believe Bitcoin is designed for (money), and you believe that no one is willing to pay for it, how can it even persist into the future?

You can't have it all. If Bitcoin is money (which I believe it is), then we need to pay the price to keep it alive. There is no free lunch.

Either we centralize, or we pay the price of decentralization. I know where I stand.

Peace.

Yes. Needed to read this. Totally agree, bitcoin is a monetary network, not a storage system for shitty jpgs and etc. Take that elsewhere.

Reply to this note

Please Login to reply.

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.

Im sorry, but there are too many false equivalencies in your argument to make sense to me.

It’s not Core’s or anyone’s job to play whack-a-mole with spammers. That’s a fool’s errand.

Agree. Leave the code alone.

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

The ability to modify the settings will still be available

They are still deprecating the option.

And there is no need to make this change now.

Core messed up and lost a lot of trust. Maybe less trust is good tho