Imagine if Core and Knots worked together to reduce spam as much as possible, then mitigate the remainder.
View quoted note โ
Login to reply
Replies (17)
I wasnt around during the block size wars, but I couldn't imagine supporting Core back then if they are like now. They have terrible communication skills and the arrogance off the charts.
Yes, that is one of their achilles heel
I had some geeky IT frens back in school and it was the same, they wouldn't listen to anybody and they were always right "technically".
I take a positive from it all though, we need more node software.
Yes, we need more than Knots which is a soft fork of core with as few hundred setting changed.
I always think of Linux with its almost infinite array of distro's, all of which are essentially the same, but each one different in its own unique way.
Also, your geeky friends were always technically right, but got everything they did spectacularly wrong, including getting girlfriends ๐
I think we need a new node implementation altogether (but using the original consensus code) because Core and by extension Knots love corrupting their data directory easily.
Yes ๐ฏ
Yes, agree ๐ฏ
You know when you hate that person because they are exactly like you and it turns out you don't like yourself ๐
View quoted note โ
Oh I didn't say it wasn't important, I just understand the argument and have made my own mind up, more or less along these lines:
View quoted note โ
Both sides are both right and wrong. They have more in common than they think.
This was my conclusion:
View quoted note โ
Not that I've seen, but I wrote my conclusions on both sides within this post:
View quoted note โ
Thanks man. Still gonna have to do my own research ๐ช
If I may place an observed nuance on it. The core guys are right, the problem is they don't understand the knots guys are right also.
View quoted note โ
They could work together. Luke submitted a PR to add the same inscriptions hack fix that Knots uses. Instead of merging the fix, they changed the definition of datacarriersize to turn it from a bug to a feature. Their words and actions made it clear they support spam on the blockchain. This makes sense considering they are financially incentivized by Citrea, Taproot Wizards, etc.
They claim it's impossible to stop, and filters will have to be updated daily from a centralized server. The filter is simple, look for instructions in OP_RETURN that are being abused to embed data in code. It doesn't need to be updated daily. If all nodes were doing this (currently only Knots) and running sane default size limits (all current nodes except LibreRelay) the only way around would be miners using tricks like Slipstream. Core's argument ignores the fact that Slipstream and all sane miners have Terms of Service that prohibit illegal and questionable data submissions. This fixes 99.99% of the problem. It also sends a message to the companies building inscriptions garbage on Bitcoin to go do it on Ethereum, Solana or any other shitcoin.
#Enshitcoinification
Running #Knots
#MBDA
See, that's sensible talk. We need more of this.
Yes, most of the time, in most arguments, both sides agree more than they disagree. In battle, opponents choose to focus on the small differences, not the massive similarities.
It's unfortunate that the current Core regime has decided to ignore Luke's patch, call the bug a feature, ban folks like Mechanic, and launch a campaign of personal attacks against them. I believe Luke and Mechanic are acting in good faith, for the benefit of Bitcoin. I don't see that from Core. I see them acting for the benefit of their employers. Fiat financial incentives strike again.
I would like to see more decentralization. btcd and libbitcoin should be used more. Not the current "one node implementation to rule them all."
#Enshitcoinification
Running #Knots
#MBDA
I've stopped listening to the discussion because it's descended into name calling, but I wrote my reasons for running knots here, and it's nothing to do with either sides arguments:
View article โ