One of the best “Why Knots not Core” explanations I’ve read
Login to reply
Replies (115)
you are being scammed
why would people who have been staunch defenders of decentralization all of a sudden be the bad guys? is your cognitive dissonance so strong that you can’t recognize you are being fed a false narrative? filter don’t work, they just want influence so they can make unilateral changes to bitcoin. Wake up.
I’ve been talking about this non stop, and will continue to do so until rationality is restored
View quoted note →
because the X ragebait algo is pushing non-technical nonsense. filters don’t work. The knots settings have no effect , even with 99.999% adoption. Knots nodes still relay cp. their narrative is built on lies.
Its not consensus, as long as you have a few nodes connected to miners the tx will go through. Knots can’t stop this
diverging clients lead to systemic risks in bitcoin
filters have no effect, all they do is temporarily delay the relay of the tx data to your node. Please explain what the point of the filter is ?
very subtle divergence bugs can create subtle hardforks even when it’s not intended
Consensus rules let them in regardless. Relay policy is like having a feather as a deadbolt
Why are the majority of op_returns under 80B then?
Rationality might be rolling back the change and improving approach to philosophical consensus. It does seem this is dividing the community at the very worst of times to try to increase adoption. Am curious as to whether this has become such a contentious issue due to communication and confusion. Bitcoin is so much bigger than a few years ago. Maybe there should be a more accessible arena for debate
Is there a real example of this ever happening? Or is it theoretical?
Yes btcd has hard forked before accidentally I believe
let me untangle your muddled logic with actual rigor. You’re parroting the same tired trope: “they were decentralization advocates, how could they be bad guys?” That’s a textbook fallacy — appeal to past virtue. History of intent is irrelevant if present incentives diverge. This isn’t philosophy; it’s game theory. Bitcoin doesn’t care about your sentimentality.
Filters do work — if you actually understand how consensus mechanisms evolve. Soft forks and policy filters are defensive membranes, not censorship layers. They restrict attack surfaces, prevent trivial relay spam, and preserve network health. That’s not “influence to make unilateral changes”; it’s the opposite: minimizing the vector space where unilateral changes could destabilize consensus.
The “false narrative” you’re swallowing is that decentralization is static — as if someone who once defended it can never drift into centralizing power. That’s naive. Incentives mutate. Social reputation is weaponized. Capture doesn’t announce itself. If you think decentralization is about trusting personalities rather than validating rules independently, you’ve already forfeited your position.
Wake up? No, level up. Learn the distinction between protocol-level consensus (rules enforced by full nodes) and relay-level policy (filters applied at mempool entry). Confusing the two is exactly what propagandists rely on.
If you can’t separate those concepts, you’re not defending Bitcoin — you’re defending your own ignorance, loud enough to hope no one notices.
Your confusion stems from conflating consensus-critical validation with mempool relay policy. Consensus rules are immutable unless every full node independently accepts them; relay policy, on the other hand, is a spam-mitigation layer that has zero impact on final settlement validity. Pretending the latter equates to unilateral protocol change betrays a fundamental ignorance of layered architecture.
Bitcoin’s defense against centralization is emergent, not static: adversarial incentives shift, Sybil vectors expand, and bandwidth asymmetries evolve. Filters are not “control levers” but entropy dampeners — they collapse attack surfaces that would otherwise metastasize into systemic throughput degradation. If you seriously believe policy propagation equals governance capture, you’ve confused TCP/IP heuristics with BFT consensus primitives.
#bitcoinknots #bitcoin #nostr #anarchyⒶ #decentralisation #freedomtech #blockchain #freepalestine
Wasn't the filter limit set based on what was being used at the time?
Why do we have to make this change to core ?/why not leave it alone ?
Technicalities aside, as a node runner, it is good or bad for me to have to store arbitrary data on my my node?
It’s like the 2 sides are arguing at crossed purposes:
core = you can’t stop it so why try
Knots = it shouldn’t be there because that’s not what the protocol was intended for.
But as a pleb node runner is it better or worse for me that the data carrier size is gone?🤷 Feels worse but IDK
What is the risk of keeping that dead code? Right now the risk of removeing the dead code is more people running knots.
Because it creates bad incentives, if relaying OP_RETURN transactions is hard, people who want to inscript will bloat your UTXO set. You will be able to do nothing about it, whereas now you ignore everything after OP_RETURN even if it's part of the block.
Core failed to explain enough to gain consensus. Now people are upset and will continue to be upset unless core comes back to the table. They should as table the release of v30 until people are happy about it again otherwise it's full knots speed ahead
I guess people like the feather. We should keep our feather for now. Why remove it?
“Filters do nothing”
“We must remove this filter”
because its virtue signalling
I’d like to see a more fleshed out theory on Knots being a takeover.
Aren’t Core doing the same thing, making unilateral changes to Bitcoin despite significant push back?
I thought it was policy to avoid contentious changes?
If Knots goes rogue, someone will fork and we’ll move to that.
I’d rather Core just revert and then go back to that.
Alan ₿
“Filters work.” — Matt Hill of @Start9
Right because exceptionally low-trust people who are switching clients to protest bcore developer behavior will somehow all of sudden become total lemmings if knots pushes a consensus breaking update.
Holy fuck you devs are social retards
yes he is
If it's not broken don't fix it. Too many times in my experience people have said, this thing on the machine does nothing let's remove it... Then eveything is fine for a little while until the machine does a special cycle and crashes bc that thing was a limit dog for the special cycle.
Why is core so emphatic about removing this ?
Then you will 100% be wasting your time, which is more scarce than Bitcoin, over something that supposedly doesn't do anything. Make that make sense.
i’ve already answered this 6 times, so i am going to stop wasting my time now
Running Knots! 🤙🏼
So what @jb55 ? Why are you so concerned about us poor stupid knots nodes? Are you trying to save us from %gasp% underpaying a fee? 🤯
This is how lots of us feel @jb55 and are trying to get to first principles as to why this arbitrary data, in this format and size, is even on Bitcoin to begin with? 🤔
Shouldn't the main Devs be working to make BTC the best "money"?
If so, then they need to explain why it's *good* to encourage and be OK with people sending jpegs of cats to my node. 🫠
Is that what their best iteration of money is?
I believe data is representative and what it represents matters. Very sharply.
Bloating nodes with rando spam, opposed to financial transX data (sender, receiver, sat amount, fee) seems counterintuitive to the whole project's intent.
Is money just 'jump ball' to whomever wants to pay a miner the fee to push whatever they want to the entire network?
If it takes changing concensus to get rid of such spam, then perhaps we deserve a better "money".
Am I wrong? 🤷♂️
Or is not wanting random jpegs on my money censorship?
What even is Bitcoin to become? 👾
I always seem to find more people to follow during these exchanges.
#bitcoin
#lightning
#runknots
#mynodemychoice
#noderunners
#choosewisely
#thinkdifferent
This is disingenuous. The code wasn't doing nothing. Most OP_RETURNs were less than 80kbs for a reason.
Haha. Hey man. Don't hold me to it. I'm just trying to make my way thru the weeds to figure out what I think Bitcoin ought to be...
They work as a deterrent. To raise the amount of effort and cost it takes to get a non standard transaction into a block. Yessir
It sounds like you have a good grasp on it?
What do you think Bitcoin should be?
A Peer-to-Peer Electronic Cash System?
Bingo! 😃 Haha 🫡
I can get down with that!!!!!
#runknots
Because they're being paid by shitcoiners.
Exactly
Then why aren't you fighting against this change?
Everyone using the same client is a huge risk to the network.
One bad update, a single mistake, and Bitcoin network could become compromised.
Why are you against diversity of clients?
It really does not make sense to be against decentralisation, like, that's the whole fucking point of Bitcoin.
No central bank. Decentralised.
He doesn't sound ill informed to me. Explain it like I'm 5.
Do you support efforts like libbitcoin-kernel?
I think he’s saying that as long as there are SOME nodes that will pass on transactions, they’ll be disseminated throughout the network. There will always be a node that is willing to pass on a tx that your node would ignore.
of course
Here's a little breakdown on this that some of you might find useful:
View article →
Actually Satoshi was also against "diversity of clients".
“I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.” ~ (Satoshi Nakamoto).
Now the question is which client.
Pandoras box is open. Too late to close it now.
I think a counter argument (from Core supporters) is that there are external services (Slipstream, large exchanges) that will offer the service needed to get these transactions mined. That's why he says that you will need to "pay $80" for the service.
So, while it's likely that a sovereign Bitcoiner cannot propagate these transactions easily from his own node, he can just use the service. This makes sense to me since I can't imagine a sovereign Bitcoiner supporting storing arbitrary data larger than a hash at all. I guess I'm just greedy with disk space still after living through the days of only having a 128GB SSD.
Interesting. Ty
Just a reminder that bad actors come into movements all the time to try and subvert or degrade the movement. Happens to all movements. (occupy wallstreet, black lives matter, bitcoin, religion, etc)
Any group could TRY to subvert bitcoin or subvert the other group. So be careful to not to think your team could do no wrong. I think it's dumb to think that current knots users would just go along with anything knots did. They just turned on cores idea, why wouldnt they turn on knots if they starting doing something that didn't align with their values?
I'd be interested to hear what you think knots would do that could somehow subvert bitcoin from being decentralized. At this point knots is just mainly just reimplementing existing things, not exactly crazy since we're still running a lot of the same rules currently on most nodes.
Just because there is a window open that allows spam, but in a bad way (UTXO bloat). Doesn't mean we should open the front door to "solve" one problem and very likely introduce another. (Aka it doesn't solve the actual technical problem, just incentivizes spammers to use the front door) Maybe we screwed up and the initial "bug" that allows the problem needs to be patched.
If there was a bug that let me put my movie files on a server meant for medical information, and my files could never be deleted, it would be patched ASAP.
The biggest issue, as I see it, is the larger data limit or potentially no limit. It makes for poor incentives.
Btcd has entirely different codebase. Knots has 99.9% of the Core codebase. They are not the same.
Yes, so why is Core taking actions that will drive node runners to Knots? 
🫣😥
forwardsteps 🪢
ALL Bitcoiners MUST watch all of this - without distraction, with full focus and all the way to the very end. 😱🚨‼️⏰ 🔔😳🤯...
any divergence has this risk
Yes, and it negligible in the case of knots
I disagree, there are hundreds of unreviewed commits on top of knots
Start reviewing then
code review is very time consuming, would rather spend that time reviewing code from reputable developers on core, like @b10c @Sjors Provoost and many others which i already neglect 🥲
We've had our test case... and it was indeed not a good idea... for the diverging implementation (i.e. Bitcoin Cash).
This is why neither Knots nor subsequent versions of Core have any incentive to diverge from consensus.
👆 this!
There is WAY more 'systemic' risk in having only a single point of influence capable of making unilateral changes. The more clients capable of making changes only with respect to their de minimis sphere of influence, the better.
Satoshi disagreed
View quoted note →
Appeal to authority notwithstanding, the results are in: a second implementation that doesn't provide identical results is indeed a bad idea... for the second implementation (see Bitcoin Cash).
I mean you’re the one that is looking for all sorts of ways to discredit Knots as a project. What better way to dunk on the rest of us by reviewing the code and point all the ways you think it’s crap.
yes i don’t trust luke at all, since i have been around long enough to know how unhinged he is
And I don’t trust any of you fuckers, since I’ve seen your gaslighting, credentialism and lack of adversarial thinking for the past 2.5 years. So we can leave it at that I guess.
Different consensus rules vs 99% core with a few patches that are directed to mempool policy are not the same thing. And I don't agree with this idea of putting Satoshi or Adam Back on a pedistal like they are some kind of God that we have to take their word as gospel. They are people. You are able to still take all information for youself, think critically, and come to your own conclusions.
I think people are reading this as:
- there’s a spam problem
- there’s a weak filter mechanism in place
- proposing to replace the weak filter with nothing means “admitting defeat”/don’t care
I have no blockchain experience under my belt but while the core argument is technically sound I can see why people would react the way they are.
I think this is mostly a communication problem.
Lol
Let nodes decide what filters to set or not set. Knots allows this. Core, like the nanny state, does not.
yeah except the knob doesn't do anything useful, but whatever makes you feel more righteous.
Filters are useful. And even if they weren’t, I’d rather have node runners decide than a small clique of Chaincode Labs devs. The fact that Core is forcing this change despite the controversy around it is very telling.
a knob that adjusts this setting won't stop the tx from getting into your node, but alright. you keep telling yourself that.
It actually does do something useful. It stops the relaying of a tx your node does not wish to relay. Just because a tx can still make it into the block does not make the relay data limit useless. It’s enforcing a policy set by the node runner and the version of code they run.
Bitcoin is a monetary network not a jpeg network. Just because Satoshi didn’t specifically say it’s for money only does not make all data equal. It’s a peer to peer e CASH system. Not a peer to peer insert whatever data you like system. I personally don’t care if people are relaying monkey jpegs but non-continuous CSAM is likely a real risk factor and a possible attack vector.
CSAM still gets to knots nodes, the setting at most delays it for 10 minutes from getting to your node.
How would it get relayed with a tiny limit? It would have to be in chunks.
It doesn’t stop all, but it does stop most, like how all filters (email spam etc) work.
simply not true.
your node will then start relaying this CSAM to other nodes after it comes in a block, I don't see the point of a knob that does nothing except delay for 10 minutes.
this is still true even with 99.999% knots usage. people relaying this stuff won't be doing it through knots nodes.
Why do they need to remove the knob though?
This is all retarded and I don’t trust anyone. One side has a bunch of shitcoiners and the other is a bunch of religious nuts…
your node relays blocks to other nodes, which would include the "filtered" txs.
because it doesn't do anything useful. mempool settings are incredibly niche for non-mining nodes, unless you are optimizing memory, but then you would just use the total mempool size setting.
I've been running a node since 2010 and I never once needed to tweak this, only ever mempool memory usage.
non-useful code is dead code and is a maintenance burden. non-useful code is also confusing to users who think tweaking the knob will actually do something.
There’s a difference between what ends up on the timechain and what I choose to accept in my mempool.
And with Core v30 lifting OP_RETURN limits to nearly 4 MB (a 50,000× increase) the risk of vast CSAM being permanently embedded becomes a much bigger issue.
Sorry but I don’t buy that excuse…
How much additional maintenance does allowing users flexibility to update settings on their node really require?
Just seems very suspect that this is the hill core devs are deciding to die on.
what appears in your personal mempool has no impact on what will be accepted in a block.
My node alone won’t. But enough Knots runners and aligned miners (eg. Ocean) can shape what propagates. You choose defeatism. I do not.
Why isn't it there already then? Please don't say that it isalready there because someone chunked something up to look like utxos and spread it out across lots of transactions. If filters don't do anything why don't we already have big long strings of CSAM in the op return field? Don't say its because no one wants to upload it, someone already went through all the trouble of chunking it up to look like normal monetary transactions.
i choose economic reality, in what world would every miner adopt this
whos to say its not already?
View quoted note →
The reality we already live in, since filters are how Bitcoin already works. Core v30 is what’s attempting to overturn longstanding mempool policy, not us.
As it turns out, I did ask the question "is it already there". What I found was dishonest people conflating methods akin to steganography with simple drag and drop unencrypted file uploads.
“Despite the controversy” - this is IMO the biggest issue here. Influencers making non-technically sound arguments should not be able to change the course of dev work
Historically, Core has only advanced non-controversial changes with broad consensus. Core v30 breaks that pattern. If you don’t think that sets a dangerous precedent, I don’t know what to tell you.
Bitcoin itself is a protest vote. Perhaps you’d be more comfortable in ETH / Fiat world where you don’t need to take any actions and can simply trust the experts.
What’s more dangerous - influencers being able to force dev behavior to change, or the devs themselves?
🤦🏻♂️🤦🏻♂️🤦🏻♂️
yeah i think @Alan ₿ believes bitcoin core is a democracy and that social media campaigns spawned by influencers can change dev direction. If that was the case then bitcoin would be a dumpster fire of bad decisions.
I don't understand your reply to my question, could you clarify?
Lol, dead code is when a function is called and has a deprecated feature. This is a feature that still gets called to define the standardness of a transaction. Dead code...pfft repeat things you hear some more, dude.
virtue signaling left and right; yawn
It’s not an opinion that MOST op_return transactions are under 80 bytes.
So the filters do MOSTLY work.
And I’m reinforcing that point by asking why we have to remove the filter if it doesn’t work anyway
We’ll be discussing the motivation for Core’s new policy at BitDevs Rotterdam today!
To clarify, bcash was a hard fork. Divergent node clients is an entirely different thing. I don't recall we've ever had any diverging clients to any material degree until knots. Closest thing is having some clients updating at different times. We don't definitively know, based on history, if diverging clients will cause problems.
Thank you @Alan ₿ 🧡🙏🫂
You’re economically illiterate, stay in your lane.
yes, but THAT IS WHY :-) any group that develops a client (such as core), should engage with the community to ensure everyone is onboard with specific changes. Obviously not every change will cause a significant amount of the community to start running a fork. Core obviously has more history and more funding and I'm not even a fan of luke, but it is not personal or about who. It is about what and the arguments.
I really dont know or dont care much about who in particular the developers are.
It's not and never was about
- staunch defenders
- or the bad guys
"Filters dont work" has been debunked. They do work. If they didnt, then why remove them? Bitcoin was just fine for the past decade without removing them.
You also havent answers to why you think removing them would help with decentralization - it seems the opposite will happen once BTC will be targeted by CSAM just like BSV was and less noder runners would want to be involved with it and only big players can and will filter those kind of transactions from their mempool, essentially causing centralization.
If you don't agree with that argument, you should be able to argue for why this is not a risk and also why removing filters will presumably help with more decentralization.
Core should not engage with community, thats not really possible. The community is the entire world. How exactly would you derive signal from that?
Community should get involved in dev, its the only way this works
Of course - nobody has to engage with the community.
If you don't you might find many people might stop running your node implementation if you do things they dont agree with.
So, one easy thing would be to try to explain any planned changes (especially if they are bigger and/or contentious) in a blog post and spread it on social media, so others can comment.
The point is mostly to collect all the various arguments that are being made or the criticism that might be observable and potentially mitigate or adapt the planned updates.
That way it is possible to avoid the issue.
There are many ways.
Open source is all about the freedom to fork and the world to choose what open source programs to run.
That is the democratic voting power of node runners and miners to keep the power of a single developer team in check and instead of discrediting that, it should be embraced.
Of course, core can move forward regardless and look down on any criticism if they think that will help them, but they should bear the consequences as well.
...could you maybe finally answers why or how core30 proposal is meant to achieve more decentralization or link to a resource that explains it? 🤷♂️