Bitcoin Core or Bitcoin Knots, the OP_RETURN debate

[Wind_FURY]

Aaron van Wirdum wrote the best article about the block size debate entitled, "The Long Road To Segwit. Currently he has another article about another debate/drama that's currently happening in the Bitcoin community entitled, "Bitcoin Core or Bitcoin Knots: What The OP_RETURN Debate Is Actually About".

Every pleb in BitcoinTalk should read/understand the issue, and if you need to, you should express your opinion/viewpoint.

A new default setting in the upcoming Bitcoin Core release, Bitcoin Core 30.0, has caused a rift through segments of the Bitcoin community. Some users have indicated they won’t upgrade to the new release of Bitcoin’s most-used client, or switched to running Bitcoin Knots: a software fork of Bitcoin Core maintained by OCEAN CTO Luke Dashjr, a vocal critic of the change.

The debate is quite technical, about a seemingly minor issue. Bitcoin Core 30.0 will start to relay transactions across the network with bigger OP_RETURN outputs: transactions that embed arbitrary data (like text or images) in a specific way. This appears to be a minor change because Bitcoin Core (and Bitcoin Knots) nodes do already accept these transactions once they’re included in a block, while they also relay transactions that store arbitrary data in other ways.

But the update has caused a rift because it reflects deeper concerns.

The “Bitcoin Knots perspective”

Bitcoin Knots proponents generally dislike that transactions can contain arbitrary data, or as they usually call it, “spam”. But so far, most have begrudgingly accepted this as an unfortunate side effect of the Bitcoin protocol.

They do believe this type of usage should be discouraged, however. When Bitcoin Core developers did this in the past by imposing a limit on the size of OP_RETURN outputs that nodes relayed, it indeed appeared to make some people decide to take these kinds of use cases to other cryptocurrencies instead of Bitcoin. (Most notably, this is commonly explained as the “origin story” of Ethereum.)

The updated relay policy in Bitcoin Core 30.0 in their view symbolizes the end of such resistance. It signals to “spammers” that they are welcome on Bitcoin.

One concern is that this will increasingly draw in this class of users and projects. And because Bitcoin block space is limited, using it for data storage will fill blocks up quickly, in turn driving up transaction fees, perhaps to the point where many regular (“monetary”) transactions are priced out because of it.

Another concern is that, even though arbitrary data can already be embedded in different ways, OP_RETURN makes it a bit easier to parse this data compared to other methods; it takes a little less effort to turn it into (say) an image. This, Bitcoin Knots proponents worry, also increases the risk that inclusion of illicit materials like CSAM (child sexual abuse material) could result in regulatory pressure on node operators.

If the problem is that Bitcoin Core developers are not resisting the spammers, Bitcoin Knots represents this resistance. Even if they can’t prevent arbitrary data from being included in the Bitcoin blockchain, or not prevent it completely, they at least won’t help open up an additional avenue for it. In effect, they’d be signaling that spam is not welcome, which they hope will have a discouraging effect.

Assuming this discouraging effect succeeds in keeping the spammers at bay, Bitcoin Knots proponents say, Bitcoin can continue to be used for what it was originally intended: monetary transactions.

The “Bitcoin Core perspective”

People can store arbitrary data on Bitcoin’s blockchain in various ways. Indeed, in recent years many people stored images in Inscriptions, and it could even be embedded in public or private keys.

Most Bitcoin Core developers do agree with Bitcoin Knots proponents that none of this is great, and it’s not what Bitcoin is intended for. But out of all these options, using OP_RETURN is the least harmful method, because it minimizes a computer’s resource consumption, thus keeping nodes as affordable and accessible as possible.

As such, Bitcoin Core developers figure that rather than trying to resist the use of OP_RETURN, it’s better to just allow it; limiting probably only makes matters worse, and possibly much worse.

For one, just refusing to relay these transactions technically doesn’t achieve much. These same transactions could still be relayed by some other nodes, like Libre Relay nodes, or they can be submitted to miners directly to be included in blocks. This in turn could have a centralizing effect, as direct submission would presumably be done to larger miners disproportionately, who then benefit from the extra fee revenue at the expense of smaller miners. (There are also some nuanced detriments for nodes themselves if such transactions do make it into a block anyways.)

The more robust solution — and arguably the logical next step — is to render (big) OP_RETURN transactions invalid through a consensus protocol upgrade (soft fork), so they can’t get mined at all. But the problem with that, as already noted, is that people might use other, more harmful methods to store data on the blockchain. (In fact, many already prefer to use Inscriptions because this is significantly cheaper for bigger chunks of data like images.)

In theory, some of these methods could be blocked as well. But most Bitcoin Core developers foresee that this will only lead to a game of whack-a-mole, with “spammers” resorting to different methods each time. It would incentivize them to “disguise” their data like regular transactions, which could lead to a situation where monetary transactions and arbitrary data become increasingly indistinguishable from each other.

The only solution left in this stage might be to designate some person or group to make judgement calls about which transactions are acceptable and which are not, in effect introducing some kind of entity that has the power to impose censorship. Bitcoin Core developers (themselves a rather amorphous group of contributors) have no interest in taking on such a role — not least because they don’t wish to become a target for regulators that could force them to abuse this power — and prefer Bitcoin not to go down this path at all.

Instead, they generally expect that the problem will resolve itself over time, without their interference.

This is because a monetary transaction is relatively speaking a tiny bit of data. A single Bitcoin block can fit thousands of them. Other types of data tend to be much larger; just one image can fill up an entire block. This means that a single “spammer” typically has to outbid many regular users. Given enough demand for monetary transactions, using Bitcoin for data storage quickly becomes expensive. Arbitrary data should in this scenario be priced out and disappear organically.

Most Bitcoin Core developers agree that Bitcoin should be a network primarily for monetary transactions— but not because they’ll actively resist other use cases, rather because this is how the incentives of the system already align.

So now what?

Everyone is free to use whatever software they want, whether this is Bitcoin Core 30.0 (with or without touching this default setting), an older version of Bitcoin Core, Bitcoin Knots, Libre Relay, or anything else. In this sense Bitcoin users are, in a very real way, sovereign.

Judging by sentiments on social media platforms like X, it does seem that some non-trivial segment of users won’t upgrade to Bitcoin Core 30.0, or indeed switch to Bitcoin Knots. But it’s impossible to tell how big of a share of Bitcoin’s user base this really represents. It could be a large majority… or it could be a small (and loud) minority.

Either way, Bitcoin does not operate like a democracy. Because every node typically relays transactions to multiple others, if even a relatively small minority of users choose to run Bitcoin Core 30.0 (or Libre Relay or something similar), larger OP_RETURNs should in fact propagate rather freely. This probably can’t be stopped completely, but assuming Bitcoin Knots proponents want to at least meaningfully stifle this, they’ll need to convince some supermajority of node operators (perhaps 95% or more) to join them in their filtering efforts.

If they fail to do that, running Bitcoin Knots can be seen as a voice of dissent— but one with little practical effect.

https://bitcoinmagazine.com/technical/bitcoin-core-or-bitcoin-knots-what-the-op_return-debate-is-actually-about

[PostQuantumBTC]

Before anyone think of running Bitcoin Knot, they should first think of how centralized Bitcoin Knot is because it is controlled by a single developer, this is different from Bitcoin Core that has many developers.

[pooya87]

That's a good summary of the situation reporting both sides of the argument instead of a one-sided one.

However, it is still missing one important part. The fact that this all started with the exploit someone found in the Taproot SegWit and used it to create the Ordinals Attack and then because of the market that was created where these spam transactions were traded, it attracted more spammers. Then and only then the core developers decided to remove the OP_RETURN limit (instead of fixing that exploit) to encourage these spammers to use that.

This little fact gives this whole situation a different perspective. Because those who are attacking bitcoin (using it as cloud storage) don't care about using the preferred way of inserting arbitrary data into the chain which is OP_RETURN which is also less harmful. If they did, they wouldn't have used bitcoin as cloud storage in first place!
They also would prefer the discount using the exploit gives them (the SegWit discount thing) which means regardless of what the OP_RETURN limit it, they are not going to be encouraged to use it over the exploit Ordinals Attack introduced them to.

In my opinion loosening the OP_RETURN restrictions only introduced a new spam vector on top of what already existed. Even then the problem I have with core is always the same. They don't offer the users an easy way of changing these policy rules. The user either has to modify the code or do a lot of search to find the environment variable and change that in a very user unfriendly way. Heck why not add something as simple as the following to the UI in the Settings window or something like that? It is trivial to add...

Doing something as simple as that would not only give the user back the control over what they want to relay (which is how bitcoin should work) but also it would eliminate all this core versus knots nonsense.

[headingnorth]

Before anyone think of running Bitcoin Knot, they should first think of how centralized Bitcoin Knot is because it is controlled by a single developer, this is different from Bitcoin Core that has many developers.

That doesn't mean anything. What matters is the code is open source and can be seen by anyone.
Which is true of both Knots and Core.  

What matters are the intentions and motives of the people running it, not the quantity of people.
With many Core developers being advocates of ethereum and other shitcoins, does not give me a whole lot
of confidence nor trust in their motives.

Core devs should be working on closing the loopholes that allows for garbage like ordinals and inscriptions, which they constantly
refuse to do. Instead of constantly working to make it even easier to relay spam and other garbage. Knots does more than just
limit spam through the OP_RETURN filter it also rejects ordinal and inscription transactions. The same cannot be said for Core.

[BitGoba]

Core side claims that spammers are bloating the UTXO set, and that when the OP_RETURN limit is removed, they will cause less harm. What I don’t understand is why they don’t focus instead on fixing the flaws that allow spamming in the first place.

[Ucy]

Whatever goes against the sacred Bitcoin principles must be rejected with all gravity. This is not about being religious, it's about sticking to what's right for Bitcoin. And the right things have to be enforced through public consensus that's is based on permissionless verification of works, proposals, ideas, claims, etc (by anyone) for correctness before approval. This method is based on the trustless principle of Bitcoin, which requires not trusting without verification, or generally not trusting a person,  something, group, without a way of ensuring he/it doesn't fail, make mistakes or be evil.

The Bitcoin consensus should ensure:
- That nodes won't be hard to run, and end up being run by a few people. This will help keep the nodes very decentralized
- That only light data are stored on the Blockchain, and the data should be mostly money or finance related. This will also aid in decentralization and prevent spamming the system with irrelevant and unlawful data.. Ofcourse, we are aware that people could be able to store this data in pieces, but what is important is that they are difficult to access by anyone, or obscure and hard to find/access. And it should be made really difficult to store such things on the Blockchain.



It's important to note that colored coins (or tokens) should be allowed onchain since they are related to money.. Things like hashes of irrelevant data stored on another place should also be allowed unless they are frequent or spammy. We don't want anything to prevent the smooth use of Bitcoin chain for its core objectives

[Cookdata]

Core devs should be working on closing the loopholes that allows for garbage like ordinals and inscriptions, which they constantly
refuse to do. Instead of constantly working to make it even easier to relay spam and other garbage. Knots does more than just
limit spam through the OP_RETURN filter it also rejects ordinal and inscription transactions. The same cannot be said for Core.

Many people are taking side with this OP_RETURN thing personal but I want to believe the advocate of Bitcoin core knows what they are doing and why they decided to keep OP_RETURN scripts till now.

The Bitcoin knot runners are making it looks like all of sudden utxo bloating started since ordinals and the recent discussion of arbitrary data but fake pubkeys bloating on utxo set didn't start today, it existed before now that's when OP_RETURN script was introduced which many people do play around before now. Many debates has made the script size to be increased and decrease but now since arbitrary data abuse of fake pubkeys has become another trend, maybe increasing the limit will reduce this bloating problems but Knot feels everything need to be scrap, common! It doesn't have to be that complex, what message are you passing to investors? Other than that, you are taking incentives away from miners, without them nothing is going to work even as I understand the fear of node runners, they fear the cost of storage with OP_RETURN.

Core side claims that spammers are bloating the UTXO set, and that when the OP_RETURN limit is removed, they will cause less harm. What I don’t understand is why they don’t focus instead on fixing the flaws that allow spamming in the first place.

There isn't nothing to fix, this isn't a bug. You don't just change things that is been build. Many of us are not looking at the consequences of trying to remove what already existed. What happen to decentralization all of a sudden and why must everyone listen to Luke.

There was a time everyone including me was annoyed about block war during ordinals, paying $10 to get transaction confirmed but the trend has slowed down and transaction median fee are back to as low as 1sats/vbyte. Some wallet are trying to reduce their minrelayfee since some miners are already taking as low as 0.1sats/vbytes.
If you run core and you are not confident in the new upcoming version and you don't like what's been updated, you can keep up with v29 until this debate comes to an end. I guess very soon, we will see the consequences of our actions whether Knot are right or core made the right decision.

[headingnorth]

Core side claims that spammers are bloating the UTXO set, and that when the OP_RETURN limit is removed, they will cause less harm. What I don’t understand is why they don’t focus instead on fixing the flaws that allow spamming in the first place.

The devs won't do anything to address the root causes of spam because they have a financial incentive not to.
They are the ones who created the problems in the first place so don't expect them to do anything to fix it.
Core developers have been fully bought off and paid for by crypto vulture capitalists, the same ones that funded
pepecoin and fartcoin. They have been fully compromised.

Core will only get worse over time. Don't be surprised the day comes when the devs propose
the removal of the 21 million limit cap and convert bitcoin into a proof of stake consensus.
They have already started talking about such things believe it or not.
 
Since implementation of Taproot their plan is to slowly destroy bitcoin by death of a thousand cuts
and reduce it to a pump and dump memecoin.

Fortunately the solution to all their BS already exists in the form of Bitcoin Knots.

[Satofan44]

Fair article, except that he wrote it using ChatGPT.

Instead, they generally expect that the problem will resolve itself over time, without their interference.

This is not a good thing. You can't arbitrarily decide which problems you will leave and hope that those that you pick will resolve itself. That is as subjective as it gets and can not be used as a valid position. Most likely they would not accept this position for issues that they think won't resolve themselves on their own. It is purely arbitrary.

The devs won't do anything to address the root causes of spam because they have a financial incentive not to.
They are the ones who created the problems in the first place so don't expect them to do anything to fix it.
Core developers have been fully bought off and paid for by crypto vulture capitalists, the same ones that funded
pepecoin and fartcoin. They have been fully compromised.

Don't start with this Bcash and BSV rhetoric again. It has failed. Roger Ver, Craig Wright and everyone around them are cancerous retards.

Fortunately the solution to all their BS already exists in the form of Bitcoin Knots.

It does not really solve anything. You need a lesson on Bitcoin basics.

[headingnorth]

The devs won't do anything to address the root causes of spam because they have a financial incentive not to.
They are the ones who created the problems in the first place so don't expect them to do anything to fix it.
Core developers have been fully bought off and paid for by crypto vulture capitalists, the same ones that funded
pepecoin and fartcoin. They have been fully compromised.

Don't start with this Bcash and BSV rhetoric again. It has failed. Roger Ver, Craig Wright and everyone around them are cancerous retards.

Are you on crack? I have no idea what the hell you are talking about.

Fortunately the solution to all their BS already exists in the form of Bitcoin Knots.

It does not really solve anything.

That is true. For spamcoin/shitcoin casino pushers like yourself Knots doesn't solve anything.

[Ambatman]

Core side claims that spammers are bloating the UTXO set, and that when the OP_RETURN limit is removed, they will cause less harm. What I don’t understand is why they don’t focus instead on fixing the flaws that allow spamming in the first place.

It would be harder to fix UTXO bloat from fake pubkeys especially in setting a filter on what is legitimate
And restrictions could affect multisigs abs Timelock, these rely on Pubkeys.

And even if it successfully filtered, Spammers would still find a way to bypass restrictions or what is tagged 'spam'

My issue is why was the OP Return even changed. It would have been left until a better solution is found
Or the limit is increased little by little.
Because now they are just hoping.

Core will only get worse over time. Don't be surprised the day comes when the devs propose
the removal of the 21 million limit cap and convert bitcoin into a proof of stake consensus.
They have already started talking about such things believe it or not.

They can't Be that stupid. They are very much aware that such an Hardfork would require major consensus
And the most wouldn't accept such
Because at the end that's just a Shitcoin not Bitcoin.

Snip

The truth is at the end of the day, it would be hard for this side to convince that side and vice versa
Because they understand where the other are coming from but believes ones cost outweighs the others benefit
Maybe a compromise would be made.

[headingnorth]

Core will only get worse over time. Don't be surprised the day comes when the devs propose
the removal of the 21 million limit cap and convert bitcoin into a proof of stake consensus.
They have already started talking about such things believe it or not.

They can't Be that stupid. They are very much aware that such an Hardfork would require major consensus
And the most wouldn't accept such
Because at the end that's just a Shitcoin not Bitcoin.

The devs didn't need consensus from anyone to proceed with ripping out the spam filters with Core 30 did they?
They could care less about community consensus. They have shown that they will undertake unilateral actions to
do whatever they want and shove it down our throats. The precedent has been set. Under Core 30 Bitcoin is no
longer governed by community consensus but by ultimate centralized power and decree.

Call it what you will, but never underestimate the depths of human stupidity, greed, corruption, evil, etc.
Never underestimate how quickly a person can surrender their integrity to the highest bidder. The Bitcoin protocol
itself cannot be corrupted, but humans can be. The human factor has always been the weakest link in the Bitcoin ecosystem.
Not just Bitcoin, but for any system that humans are involved with.

As history has proven to us time and again pushing back against such forces is a battle and a struggle that never ends.
It is something we should never become complacent about. In the words of Jefferson, the price of freedom is eternal vigilance.

[gmaxwell]

Whatever goes against the sacred Bitcoin principles must be rejected with all gravity.

::blinks::  So let me get this straight:  People you don't like transacting over matters you don't like in ways that you'd never know about if you didn't have someone drawing it to your attention...  that's against Bitcoin's principles.   And with bitcoin's principles is appointing a indisputably delusional religious fundamentalist monarch to pass moral judgement over other peoples' transactions ... that's with Bitcoin's principles?

That's a total loss of any perspective--  spam derangement syndrome.

Sure NFT crap is stupid, but paper straw mandates don't do anything about it.  It's also yesterday's problem... fees do regulate the shitcoin spam successfully as we've seen over and over again.  The alternative of introducing human subjective judgements over how other people use Bitcoin is simply not worth whatever improvement it might make on top of the system's free market self regulation.

Bitcoin was created specifically to *eliminate* the role of human judgement in what transactions people get to make or not make.  Not to change which humans get to make it, but to remove that judgement entirely to the greatest extent possible.  Sometimes this means that there will be some bullshit traffic that if this were just paypal their CEO would magic it away with a button press,  but the same button can be used to stop you or anyone else from transacting so Bitcoin was designed to remove that button as much as possible.  It's a minor cost for a huge benefit and if you don't like the tradeoff then you absolutely should find another system to use.

My issue is why was the OP Return even changed. It would have been left until a better solution is found
Or the limit is increased little by little.
Because now they are just hoping.

For the 47th billion time: Major miners *already* disabled it.  This means the limit is already functionally gone for the purpose of blocking anything you might want blocked.  The remaining effect was to fuck up block propagation, incentivize the growth of direct to miner submission, and incentivize fake pubkey outputs crapping up the UTXO set (because using fake pubkeys saves you from having to setup directly submitting to miners).  Turning off the outdated thing that is causing harm is the best solution.   There is no marginal harm from disabling a limit which no longer limits and doesn't do anything but cause a little harm.

What hoping?  

This drama will end once ocean mining finally goes bankrupt and stops making manufacturing a disaster in a desperate attempt to stay relevant.

[nutildah]

That's a good summary of the situation reporting both sides of the argument instead of a one-sided one.

However, it is still missing one important part. The fact that this all started with the exploit someone found in the Taproot SegWit and used it to create the Ordinals Attack and then because of the market that was created where these spam transactions were traded, it attracted more spammers.

Its not an attack, and those aren't spammers. They are people using Bitcoin in a new way, and they can do it independently of your approval. It could be the only way they know how to use Bitcoin. But they are using it for an end goal other than "attacking" the network. Therefore it can't be an "attack" because that suggests malintent. While their practice might be short-sighted, they do not set out with the intention of causing harm or disruption.

This is what you sound like every time you say "Ordinals Attack":



Its just hyperbole for the sake of adding emotional weight to an argument.

By insisting on mischaracterizing the situation with hyperbole, you render it impossible to attain an accurate understanding of it.

[gmaxwell]

meh. some of the nft shitcoiners are attackers for sure-- I mean, that ecosystem appears to be substantially funded by Calvin Ayre for christsake.   Of course, many of the participants are not.

Ultimately though, their intention doesn't need to matter to us.  Bitcoin ought to be and is robust to both well intentioned and attack traffic.

One of the downsides of thinking in terms of a fight against an attacker is it causes you to think that your goal is defeating them.  But that should never be our goal as Bitcoiners, our goal should be Bitcoin's success and the fate of some loser attacker ought to be irrelevant to us.  Trying to "defeat the attacker" takes attention away from making Bitcoin successful and it's a behavior that attackers can even exploit e.g. by placing Bitcoin's central properties on the shortest path to defeating them and trust that people's fixation on destroying an enemy overrides their desire to protect what really matters.

If an evil overlord were bent on disrupting Bitcoin's central properties like censorship resistance I can't think of a better way to do it than becoming a nuance "user" and baiting everyone else into blocking them.  If they attack outright, it would just unify the community against them-- so instead they need to make the community attack itself in the name of "defense".

That's probably not the intent with the NFT crap, sure, but the way to be immune to that attack is to stay committed to Bitcoin's core values and not worry too much about "defeating" losers or scammers that are trying to divert your attention.  Well never know to what extent this stuff has been an intentional attack on Bitcoin (or who is behind the parts that are e.g. no one ever managed to figure out who was behind coinwallet.eu), but so long as we stay true to the ideals that motivated Bitcoin's creation we don't have to know.



 

[PepeLapiu]

In theory, some of these methods could be blocked as well. But most Bitcoin Core developers foresee that this will only lead to a game of whack-a-mole, with “spammers” resorting to different methods each time. It would incentivize them to “disguise” their data like regular transactions, which could lead to a situation where monetary transactions and arbitrary data become increasingly indistinguishable from each other.

I think what you are saying is absurd. It's like saying that locking my front door is useless because some thieves will use my second floor windows and in fact break the window. So I should be kind to them and leave my front door wide opened.

For sure stamping out spam is going to be a constant game of whack-a-mole.

If I lock my front door, they might use my back door. That's when I should put a lock on my back door. If they break through the windows, I should install bars, or an alarm system, or a neighborhood watch.

Saying spammers will spam is like saying thieves will steal.
I think we should create as much incentives as we can to get them to go post their shit on Etherum.

Saying that spammers are too resourceful and too crafty to ever try to fight them and open the door to them instead, that is a weirdly defeatist stance.

It is not an attack, and those aren't spammers. They are people using Bitcoin in a new way, and they can do it independently of your approval.

Bitcoin is a monetary network. Bitcoin should be preserved as a monetary network. And anyone who attempts to use bitcoin as some sort of free jpeg hosting database should be considered an hostile user and booted out on the curb.

We are busy building sound money here. Take your stoopit arbitrary data elsewhere.  

Here is the reality.

Spammers are able to get around the present filters by going directly to nefarious miners like Mara and F2Pool and pay them to include their spam in their next block.

But there is a limit to what spammers can post. Even though Mara and F2Pool are immoral degenerate entities, they would not want to fill their blocks with child p**n and other disgusting filth. That would be a legal and PR nightmare for them.

So the core shitcoiner devs have decided to blow wide open the op_return filters from 80 bytes max all the way to 100,000 bytes max. They say that it's a less harmful way for spammers to post their filth but even the core devs and supporters have admitted the spammers will never use op_return because it's 4x more expensive.

But in reality, once the op_return is blown wise open, that allows a state attacker to pay a few people to post tons and tons of child p**n, malware, and other disgusting illicit data in op_return. And nobody can stop any of this stuff.

You think bitcoin had a bad reputation when the MSM was saying we waste too much power? You just wait until the chain is filled with filth. See how you handle the PR than.

[Wind_FURY]

meh. some of the nft shitcoiners are attackers for sure-- I mean, that ecosystem appears to be substantially funded by Calvin Ayre for christsake.   Of course, many of the participants are not.

Ultimately though, their intention doesn't need to matter to us.  Bitcoin ought to be and is robust to both well intentioned and attack traffic.

 👍

Thanks Calvin Ayre, for giving us a demonstration of how the fee market actually helps mitigate the spam. Plus the miners got paid a little more than usual in fees.

It was an inconvenience for many users, but it didn't last that long and I doubt it will last very long the next time it comes back. The actual users of dick pics and fart sounds on-chain will realize that they will have a better UX in those other blockchains.

One of the downsides of thinking in terms of a fight against an attacker is it causes you to think that your goal is defeating them.  But that should never be our goal as Bitcoiners, our goal should be Bitcoin's success and the fate of some loser attacker ought to be irrelevant to us.  Trying to "defeat the attacker" takes attention away from making Bitcoin successful and it's a behavior that attackers can even exploit e.g. by placing Bitcoin's central properties on the shortest path to defeating them and trust that people's fixation on destroying an enemy overrides their desire to protect what really matters.

If an evil overlord were bent on disrupting Bitcoin's central properties like censorship resistance I can't think of a better way to do it than becoming a nuance "user" and baiting everyone else into blocking them.  If they attack outright, it would just unify the community against them-- so instead they need to make the community attack itself in the name of "defense".

That's probably not the intent with the NFT crap, sure, but the way to be immune to that attack is to stay committed to Bitcoin's core values and not worry too much about "defeating" losers or scammers that are trying to divert your attention.  Well never know to what extent this stuff has been an intentional attack on Bitcoin (or who is behind the parts that are e.g. no one ever managed to figure out who was behind coinwallet.eu), but so long as we stay true to the ideals that motivated Bitcoin's creation we don't have to know.

Attack or not, it will always come back to the network's viewpoint. If they didn't break the consensus rules, then who are we to say that it was an "attack".

I have full confidence that Bitcoin will continue to exist longer than those "attackers" stay solvent.

[stwenhao]

Heck why not add something as simple as the following to the UI in the Settings window or something like that?

1. Because then, different nodes would relay different transactions, and it would be hard to know, what value can be used. Which means, that if many people would set "zero" here, then people would switch to this method instead: https://blog.bitmex.com/the-unstoppable-jpg-in-private-keys/
2. Because if all old scripts would be limited to 520 bytes on consensus-level, then it would stop being a problem.
3. Because when OP_RETURN is used instead of Segwit data pushes, then the maximum block size is limited to 1 MB, instead of 4 MB. So, the more people will use OP_RETURN, the smaller blocks we would have as a result. And then, maybe Segwit discount could be finally lifted, so all blocks would then have 1 MvB as a maximum, like it is in signet.

It is trivial to add...

Pull requests welcome.

You can't arbitrarily decide which problems you will leave and hope that those that you pick will resolve itself.

You can, because it is an Open Source world. There is no warranty, and people can decide, that they don't want to write any new code, at any point in time. And users have no way to force developers to write the code they don't want to write.

That's also why users are still using OP_RETURN to push data, instead of using commitments, which are known for years, are uncensorable, and are much cheaper, but then, they are worse, when it comes to being a cloud storage, if your goal is to force other people to store your data for you.

If they didn't break the consensus rules, then who are we to say that it was an "attack".

If you assume, that every non-standard transaction should be allowed, then what do you think about transactions, that can take a few minutes to verify? Would you call "an attack" making blocks, which would take 10 minutes or more to verify?

[Satofan44]

So the core shitcoiner devs have decided to blow wide open the op_return filters from 80 bytes max all the way to 100,000 bytes max. They say that it's a less harmful way for spammers to post their filth but even the core devs and supporters have admitted the spammers will never use op_return because it's 4x more expensive. But in reality, once the op_return is blown wise open, that allows a state attacker to pay a few people to post tons and tons of child p**n, malware, and other disgusting illicit data in op_return. And nobody can stop any of this stuff.

You think bitcoin had a bad reputation when the MSM was saying we waste too much power? You just wait until the chain is filled with filth. See how you handle the PR than.

This "limit" is already regularly bypassed, so the change in Core does not do what you described.

Thanks Calvin Ayre, for giving us a demonstration of how the fee market actually helps mitigate the spam. Plus the miners got paid a little more than usual in fees.

It was an inconvenience for many users, but it didn't last that long and I doubt it will last very long the next time it comes back. The actual users of dick pics and fart sounds on-chain will realize that they will have a better UX in those other blockchains.

While it does work at times, the fee market is not a holy grail that many make it out to be. We must continuously remind a lot of people that Bitcoin does not exist in a bubble. Every time fees go off the rails we are pushing some people into other, less-safe and more centralized alternatives. Further, we should not be elitist and dismissive of such people.. "they deserve it" kind of style. The spam and Bitcoin's low TPS are at times completely killing the usability for a fairly sized group of people.

You can't arbitrarily decide which problems you will leave and hope that those that you pick will resolve itself.

You can, because it is an Open Source world. There is no warranty, and people can decide, that they don't want to write any new code, at any point in time. And users have no way to force developers to write the code they don't want to write.

You can't do that fairly unless you would accept the same position from others, which practically nobody from Core would. Who's to say that they won't be entirely wrong about one future case? Who suffers the most from such an error? That's right, the users and the best HODLers.

If users demand solutions and people are paid to work on Bitcoin, they should listen to the users. Otherwise the power dynamics will get messed up. People will be paid to work for things that only they or their money giver wants. This is contrary to how things should be. Anyway to preserve their character every developer should come down to the Earth every once in a while. A balance is always necessary between users, developers and the miners.

[mindrust]

If the miners decide to remove the 21 million coin supply cap, how is that any different than any other upgrade? The community approved the segwit fork which was controversial at that time too. Some people didn’t like the changes and left bitcoin. They even call their own network bitcoin nowadays.

I wonder how many of us still call it bitcoin if the supply cap gets removed. Technically it will still be bitcoin because it is the miner that can decide for that change.