Even Knotzi leadership concedes that spam can't be stopped, they just "want to send a message" by engaging in an endless cat and mouse game that the overwhelming majority of Bitcoiners don't care to play.

Community warning: a shitfork scammer who pushes others onto the fork but refuses to swap sats to get more on its side, hence himself deeming it less valuable View quoted note →

Meanwhile Slopp leadership tries to convince you that since spam can’t be stopped, it shouldn’t be fought against or limited.

Great video from @Matthew Kratter View quoted note →

It can be defeated by economical means, that's the point of proof of work. Also @Jameson Lopp argues you have to be flexible about your idea of what bitcoin is. Put another way, bitcoin is many different things to many different people. Meanwhile, I'm running a full node and I can keep doing so for a few hundred $ only.

What if I told you we have forensic evidence that suggests fees cannot fight the current gamified spam on Bitcoin? Lameson Jobb is a known spam apologist and deeply invested in the spam grift, so if I were you I would not listen to anything he has to say.

Aren't fees bound to increase as time goes by ? How is the network going to be secured after another few halvings ? For now, I'm struggling to see how spam is a threat at all. Nodes are running, implementing their consensus rules and anyone can participate given the economics of the hardware.

damus:@Jameson Lopp lol

Have you heard about death by thousand cuts? You’re also conflating two different things: rising fees as a security feature and fees as anti spam mechanism.

Issue #3 - Three Years of Spam

From zero to 36%: a timeline

The solution to spam is already here : fees/block size. If we use the blockchain more than we do today, we should price out spammers. This is how you raise the cost of spam. You admit yourself here that BIP110 won't stop it, spammers will have to find new ways. Meanwhile, have you considered in depth all the risks associated with adopting the BIP ?

Core’s dumbass argument is: “It can’t be stopped… so let’s open the floodgates”

You are degenerate gambler retard and spammers cuck. Continue licking SLopp's boots.

The obvious risk is forking the chain. Then you taint bitcoin's reputation as uncensorable. It also constrains Covenants. You may disapprove of them, I don't know but creating conditions to move your btc as part of your vault seem relevant to me. Where the real dechotomy lies imho is that both sides of the argument want what's best for the ecosystem. BIP 110 advocates are convinced they are protecting the network against an evolution of ever increasing spam and the Core side consider that introducing a BIP to fight this fight is setting a precedent and sets Bitcoin on a path away from neutrality. What other fork will be suggested after the implementation of BIP 110 to constrain transactions even more once spammers have found thei network's next weakness ?

Well @Jameson Lopp claims citrea's bridge doesn't need larger Op_Returns, that it doesn't even use it, it uses witness data. Citrea uses Op_Return for fraud challenges which are very rare.

It's not a "claim," it's a fact that anyone can verify by reading the whitepaper or by inspecting the code. Though I suspect Knotzis are too lazy to do so as it would shatter their bullshit propaganda.

Jameson SLopp's and other Coretards lies were exposed here

Also evidence that Citrea directly triggered OP_RETURN increase via the compromised Core is in the two videos below

Thanks for sharing. I never got that "temporary" feature. How can it be temporary ? In fact, why should it be temporary ? To try it out ? Isn't it what testnet is for ?

Its a humble approach. BIP 110 masterminds do not pretend to be God and to know everything perfectly. The temporary approach gives us all time to assess the effectiveness and if it needs improvement to improve and then make it permanent when we are confident that its working as designed. Its also outlined in the BIP 110 itself here

GitHub

bips/bip-0110.mediawiki at master · bitcoin/bips

Bitcoin Improvement Proposals. Contribute to bitcoin/bips development by creating an account on GitHub.

"Abstract Temporarily limit the size of data fields at the consensus level, in order to correct distorted incentives caused by standardizing support for arbitrary data, and to refocus priorities on improving Bitcoin as money. " and "Why is this softfork temporary? The impact of these restrictions would severely constrain future upgrades, potentially forcing them to be designed as a hardfork instead of a softfork. Some restrictions are also not ideal, but an improved limit would be more complicated to develop and test - by deploying these simpler restrictions now, we avoid making the perfect the enemy of the good enough, while still allowing for upgrading the limits to better variants in the future. Over the next year, interested developers can implement and propose a longer-term solution to address the needs of the protocol without the tradeoffs or blunt/simplified changes."