Replies (55)
Are witness inscriptions more common than op_return data?
Excellent question for the filters work crowd:
Why do 81 byte op_returns exist?
because some people manage to bypass the filters
There, I've answered your question. Care to answer mine?
I don't know. If you count from genesis, I suspect op_returns are more common, because several popular protocols have used them since like 2012, and a few not-so-popular ones still use them today. Whereas inscriptions have only been used since 2023. But I suspect inscriptions are catching up and have many more *current* users than op_returns do.
Oof 🫣
Inscriptions lead to UTXO bloat. Knots fixes this. Core refuses to fix this, and redefined it from a bug to a feature.
There may not be many oversized op returns to begin with. This statement needs more data, and even then it is at best only valid in a specific time frame.
A filtered 81 byte transaction today is tomorrow’s higher fee 81byte transaction that miners won’t refuse. I think the pro filters crowd tends to think about this issue in too binary a manner.
When people say filters don’t work they mean over a long enough timeline filters aren’t effective and have centralizing effects while rewarding miners most would agree are not long term thinkers. The problem is of course economic pressure puts these short term thinking spam miners in a stronger position.
> 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?
I mean, what point since you just admitted they don't work.
If this was something where less or delay helped you might have a case. Your side made it about CSAM and CSAM is a 100% effective or 100% fail situation.
Can you explain to me how a 1 block delay or costing $300 instead of $150 is going to stop this alleged nation state attacker?
> what point since you just admitted they don't work
On the contrary, I think I proved they do. Their goal is to reduce the spam, and they succeed at that goal
> Your side made it about CSAM and CSAM is a 100% effective or 100% fail situation
I don't think so. If we keep out most CSAM but some makes it through, that's better than not keeping out any
> Can you explain to me how a 1 block delay or costing $300 instead of $150 is going to stop this alleged nation state attacker?
I don't know what allegation you are referring to, but I don't think the spam filters stop high-effort spammers -- they work by reducing the amount of spam from low-effort spammers
OP_RETURN was non-standard until 2014 meaning you literally had to mine the OP_RETURN output you create to get it on chain. They made OP_RETURN standard in Core version 0.9.0. There were OP_RETURN outputs prior but those were never relayed through Gossip.
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.
It is either illegal to run a node or not. You are either serving CSAM or not. The amount that changes that is "any at all" not "less than an alleged alternate reality I made up"
There are way better and cheaper ways to store CSAM just like any other data. The only reason to do it is an attack. This isn't a situation where people will upload their collection anymore than people will upload their MP3 collection.
The path is already there before core 30. All we lack is the motivated attacker.
> It is either illegal to run a node or not. You are either serving CSAM or not.
You seem to be equating these two things but I don't think that's valid. If the blockchain became illegal the moment *any* CSAM entered it, then it would already be illegal, because there is already a small amount of CSAM on it. (source:
https://www.theguardian.com/technology/2018/mar/20/child-abuse-imagery-bitcoin-blockchain-illegal-content)
Since it is not illegal, it must follow that a small amount of CSAM does not make the blockchain illegal. And therefore it is not binary, as you seem to be claiming. Spam filters that help reduce the amount of CSAM are good even if they don't entirely eliminate it.
That's when we had to object, but we let it pass. What was the reason to make it standard? I know I can live without OP_RETURN of any size...
one of the reasons they gave appears in the release notes for v0.9.0
"This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin’s UTXO database. ... Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere."
source:
Bitcoin Core version 0.9.0 released
Illegal and actively prosecuted are different things.
If CSAM legality is not the issue then why not just price out spam by doing more economic transactions?
> why not just price out spam by doing more economic transactions?
one reason why is because to "just" do more economic transactions is to needlessly throw out another helpful mitigation
it is like saying "you should break all your windows -- you can keep your room warm by just exercising constantly"
yeah I suppose I could but that's no reason to smash my windows, which *also* help keep my room warm
Any martial artist knows that defense is a joke. To only defend is to guarantee a loss. As you may have heard it said before, the best defense is a good offence.
Personally I intend to use bitcoin. Other people using it only matters to me if I am trying to transact with them.
As the privacy advocate you have positioned yourself as in the past, I can't see how you square insisting on a node implementation that blocks on chain privacy by default and nosing around in controlling transactions you aren't a party to.
I don't support the changes but Luke's history is very much that of someone who doesn't support privacy or the cypherpunk ethos. I'll just not update or switch to libbitcoin before I follow him.
I doubt you will find any martial artist who agrees with the proposition that defending yourself is a joke
@hal study this thread closely
Miyamoto Mushashi:
"The primary thing when you take a sword in your hands is your intention to cut the enemy, whatever the means. Whenever you parry, hit, spring, strike or touch the enemy's cutting sword, you must cut the enemy in the same movement. It is essential to attain this. If you think only of hitting, springing, striking or touching the enemy, you will not be able actually to cut him."
I'm also a martial artist, though I am less credentialed than Mushashi.
Filters work. Q.E.D.
View quoted note →Bill, this thread was painful to read and i am not a knots guy. You just kept moving the goal post.
Super said reduction of spam is the point of the filters, elimination would be nice, but this is open tech, the only way to eliminate work arounds is to bury it in the dirt.
You should go back and address his actual points otherwise fence sitters like me are going to start leaning towards knots just because of the way yall are approaching this debate.
What benefit does removing the size limit for op returns have as far as making bitcoin better money?
You just need to clarify why they work: because most miners use them and there was not any usecase for big op_returns so far so nobody bothered to go direct to big miners.
The reason is definitely not that enough random dudes spined up knots nodes.
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.
You fell into the same trap as everyone else then.
I'm trying to lead him to the conclusion that he has been trapped in a false dichotomy of knots vs core. Core is a problem and knots doesn't solve it.
We need a third path that has a chance of getting where we want to go.
I'm not the only one who sees it this way because I hear a few mumblings about removing the witness discount.
I'm not a skilled enough dev or a big enough voice to get anything done by myself so I'm left to hassle those who are when they show up in my feed talking about it.
I suppose I am trying to move the goalpost in a way, I see it more as trying to add a new goal and a new team to the game. Core wants to allow crap without limits to any payer which I think is bad. Knots already filters on chain privacy which I think is bad. The future I want for Bitcoin has on chain privacy and all or at least mostly monetary use.
Ok, i get you. I too think we actually need a third option. Seems like the consensus mechanisms need to be abstracted into a separate repo and all of the other stuff be in the various client repos. That would be the biggest win because i feel like a big part of this debate is core actibg holier than thou as the maintainers of the reference client.
Libitcoin.
> there was not any usecase for big op_returns
Storing arbitrary data in the blockchain is the use case today and has been the use case for op_returns since 2014
> 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.
You should disable all email spam filters since some spam still gets through.
Knots filters nothing, it allows users to set whatever filters they want.
but it does have some default settings
100% OFFENSE HUH? OK MR. SEAGAL... STAY IN UR LANE, BETTER YET GO FIND A LANE CUZ YOU DONT SEEM TO UNDERSTAND THE BASICS OF EITHER MMA OR BITCOIN
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.
Oooh, all caps. You showed me.
On my short list to get it running and see what is up.
I don't use spam filters actually. Email alias services give me complete control over who can send me emails instead of half assed sometimes doesn't block spam and sometimes blocks my real email filters.
This is exactly the kind of we need a new path outside the box solution I am saying we need.
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:
X (formerly Twitter)
m Warren ☀🌲 micah-warren.ghost.io (@AchimWar) on X
@SuperTestnet Funny story: I was messing around with my node. I thought I'll do some op return, so I spent about $.30 sent a transaction with abo...
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
I assume spammers are attracted to bitcoin for the same reason most people are.
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?
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.
> 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
