> There may not be many oversized op returns to begin with

In total, there are about 10**4 op_returns on the blockchain of size 76 bytes

For 77 byte op_returns, the count is also ~10**4 (i.e. ~10k)

For 78 byte op_returns, the count is also ~10**4 (i.e. ~10k)

For 79 byte op_returns, the count is also ~10**4 (i.e. ~10k)

For 80 byte op_returns, the count is slightly higher: ~10**4.1 (i.e. ~13k)

For 81 byte op_returns, the total count is 9. Not 9k, *9 in total.*

That's the data for the last 16 years, which I hope is a long enough time frame for you.

Why do you suppose there is a huge drop from tens of thousands to 9?

Reply to this note

Please Login to reply.

Discussion

I guess what I’m driving at is this: what is the taxonomy of the current near the limit transactions? 76 bytes is say a 4 byte prefix, 32 byte hash and 40 bytes worth of meta data. It’s possible that for the vast majority of transactions using op return these near limit totals are the sweet spot that accomplish something worthwhile and generally need 60-90 bytes to achieve. The filter perhaps drives some near term efficiency but over time the economics determine what happens.

Perhaps the time stamping and 2nd layer anchoring that makes up the the majority of use case for larger than 40 byte op return transactions naturally cluster around this point because it is close to the sweet spot between economic worth whileness and ease of implementation. The economics could be that limit and all the filter does is create a cliff like drop off vs a gradual slop downward that would occur under purely economic pressures. The over all dampening effect of filters may be vastly over stated by your data if it turns out there is not much natural demand for Say 95 byte plus transactions.

If there is ever economic value in 100 byte transactions I expect no amount of filtering will matter. I just don’t think there is a ton of demand above what is being made use of currently.

I don’t know about you but when I look back at my transactions for my early use I cringe at the number of sats I parted with to fees. I think this psychology mechanism will only get amplified as the average user isn’t sitting on large stacks of corn.

> all the filter does is create a cliff like drop off vs a gradual slop downward that would occur under purely economic pressures

This sounds like it is exactly the point I am trying to make. People who say the filters do nothing can't account for the cliff; if the filters did nothing, there would be a gradual slope til you get to about 153 bytes, where inscriptions become cheaper. And those weren't cheaper til segwit, so there would probably be no slope til then. Because there is a cliff, that means there are spammers out there who decided not to go through the trouble of bypassing the filter, and that means the filter worked.

My point was the filters work at some point in time to change some small behaviors, but ultimately it’s economic pressure that determines the long term out come. what is a dozen years to lifespan of the time chain?

Am I mistaken in thinking we would rather have all the garbage in op return vs elsewhere. If filters drive spammers to pollute other parts of the chain can you actually claim that filters have worked?

If people want larger and cheap data storage currently it is my understanding that they wrap data in taproot scripts because the size limits are much larger and the witness discount makes it much cheaper. So is it really op return filtering or is it the economics of taproot that is at issue?

I’m just curious why all the attention is on op return when there are currently higher limit lower fee data storage options.

> Am I mistaken in thinking we would rather have all the garbage in op return vs elsewhere

I don't agree with that. I don't want them to use bitcoin's blockchain to store their spam at all. If the choice *was* "op_return or elsewhere," I would choose "elsewhere," and by it I would mean "somewhere that isn't bitcoin's blockchain." But in fact spammers have another choice: don't post spam anywhere at all. That is the outcome I prefer.

> If filters drive spammers to pollute other parts of the chain can you actually claim that filters have worked?

This is the fallacy of false dichotomy. You act as if spammers have only two choices: spam op_returns or spam more harmful places. But they have another choice: don't post spam on bitcoin at all.

> If people want larger and cheap data storage currently it is my understanding that they wrap data in taproot scripts because the size limits are much larger and the witness discount makes it much cheaper

For values larger than ~153 bytes, yes. But for values lower than that, inscriptions cost more because they require two transactions: the commit tx and the reveal tx. Whereas op_returns only require 1 transaction.

There is another option, malicious actors will spam in every way they can, so opening another door only invites more unwanted spam in total. Old spammers keep using old ways & new spammers come to use the new path.

It's like the devs see trash in the park & so they decide the park should just serve as a dump.

The Devs argument is a surprisingly simple break in logic. But the problem is more significant. The Devs have been easily cooped and have been turned against Bitcoin. An attack vector. They are single greatest risk for Bitcoin. A small group of weak, greedy people, doing fiat things. Too close to the code. How do we remove them from the system?

Cheapest option is IPFS. So for spammers cost is not primary.

I assume spammers are attracted to bitcoin for the same reason most people are.

I think many of them are attracted by the idea of paying a one-time cost for permanent file hosting, and I think that is more advantageous for spammers than it is for people trying to transfer their coins.

The reason blocks are permanent is *supposed to be* for assurance against counterfeits: users can check if the coins they receive are valid by tracing them back to their blocks-of-origin, and from there to the genesis block, and ensuring everything along the way follows the rules. Apart from giving us assurance against counterfeits, permanently storing every transaction only has negative effects, e.g. it is bad for user privacy, and it is a strain on your computer's resources.

So I think spammers have a *different* reason for using bitcoin than most bitcoiners do -- or at least a different reason than I use it. I use bitcoin for assurance against counterfeit money, and I see the permanent data storage as, in all other respects, a downside. But I think spammers use bitcoin for permanent data storage, and see the assurance against counterfeits part as irrelevant.

I understand the desire to have no spam. However without changing the rules as to what a valid transaction looks like and who is allowed to participate I don’t see how spam is preventable. And while we can minimize spam in the op return it will just mean bloat elsewhere.

What are the fixes?

> while we can minimize spam in the op return it will just mean bloat elsewhere

I disagree because some low-effort spammers give up after failing to submit large spam via op_return, e.g. this guy:

https://x.com/AchimWar/status/1975406333584363932

It is not true that a would-be spammer's only choices are "put spam in op_return or put spam in more harmful places." They can also choose "don't put spam on the blockchain at all," and the above example shows that some would-be spammers (namely, low-effort ones) opt for the latter

Surely low effort subscription spam is simply a software problem away.

Sort of like launching a block chain. I think the legend has it that Doge was launched in a matter of hours. Eventually cut and paste blockchains were just a few mouse clicks to launch. Software surely makes any spam avenue low effort at some point.

So gun yo your head where would you put a spam transaction to do the least amount of harm?

> gun yo your head where would you put a spam transaction to do the least amount of harm?

In the spammer's brain -- if he stored the spam in his own memory neurons, and placed it nowhere else, it would do the least damage there

> low effort...spam is simply a software problem away

I'd like to keep it that way

Okay but you are side stepping the issue. You are forced to make a spam transaction that someone will be expecting to see on the Bitcoin chain or your entire family dies. You beg them to let you use bcash or gulp Solana but they refuse. They are btc maxis and will not even load a block explorer that isn’t pure Bitcoin.

Where do you put the spam?

op_return