Thoughts on Bitcoin Knotz? Luke Dashjr's Bitcoin node and wallet

So, I just found out that luke-jr is working on this Bitcoin node and wallet software called Bitcoin Knotz. He's pretty much against using OP_RETURN for ordinals or whatever else people want to use it for. Looks like Luke is still pretty active with both Bitcoin Core and the Bitcoin Knotz GitHub. I’m curious, do a lot of folks actually use Knotz? I don’t know much about it honestly. I caught wind of Cobra saying that Knotz could be the new go-to, which definitely got me interested in checking this out. Anyone got more info on what's happening with it? I haven't seen much chatter about it around here.

Bitcoin Knots is a codebase fork of Bitcoin Core (since December 2011) that recently gained adoption (17% of nodes) because of its mempool policies. A development fund for its contributors was also created recently.

I would phrase it like this: It is a good enough alternative to the reference implementation and Luke has sufficient reputational history to run a project like this. There are good social reasons for its existence. At least one good alternative should always exist. Otherwise we risk getting into a "king in the high castle" situation where the developers do primarily what they want, and they very rarely try to communicate with normal users. That said, Luke also has weird views on many things which do not help at all. If I recall correctly once he even advocated for lowering the block size.

It is double-edged sword: if there are many different clients, then some bug may be present in one client, but not the other. And then, there is a risk of forking, if some mining pools will run one version, and different mining pools will run something else. It is important to stick to a single version during early stages, but now, I guess the environment is mature enough, that we can work with multiple clients. But in general, Bitcoin Knots is very similar to Bitcoin Core. There are some minor changes here and there, but it is not something rewritten from scratch, and implemented in a completely different way, than Bitcoin Core. Which means, that many fixes, and code changes, are used by both clients, and they share most of the source code. If transaction batching would be widely deployed, then it could be done. And also, signet blocks were already reduced from 4 MB witness into 1 MB witness, just to test smaller blocks, and build fee pressure, without the need to artificially make more transactions. Also, fortunately, block size decrease can be done without any fork, all that is needed, is just convincing enough mining pools to do that.

Yes, both situations have their own respective risks. Perhaps, but some of the demand for it would decrease if Core developers start behaving better. It is a bit ironic at times. They want as many people to run nodes as possible, but when these same node runners have concerns about stuff like OP RETURN then the developers become quite dismissive of them. It is a good setup, as the risk of forking between the two clients is very low. I don't think trying to artificially force fees up by lowering capacity will ever work. If anything, we need more capacity and minimum fees. It would be a better solution, but we should continue this in another thread if we want to talk about this.

Some useful links: - Should the forum support Bitcoin Knots as they do with Bitcoin Core? - Removing OP_return limits seems like a huge mistake - RoninDojo bans connections to Knots nodes I don't follow the debate / dilemma, so I preferred to show you the links and you can check and read for your own.

I don't think there's anything new to say about Luke, he's made a lot of technical contributions, there's no doubt about that, but some of his opinions are not universally accepted. The extreme stance he took on block size was a good example.

I think we will see more such implementations based on the consensus code used in core, through the libbitcoinkernel library.

Is that about Bitcoin Knots and its filtering of non-financial transactions? Do the Bitcoin Core developers, collectively, actually need to be dictators in this situation and tell everyone what tramsactions are good and what are bad? Because from the network's viewpoint, transactions are transactions and should be allowed if they didn't break any rules. Plus why would Bitcoin Knots become the "reference implementation"? Because the Core Developers won't activate any filters for "dirty transactions" in Bitcoin Core? Because they haven't made their position "official" in the matter?

Yes. Many people hate Ordinals, NFTs, and similar things. They don't have to. But the development was never decentralized. If it would be, then all altcoins in the world would be built on top of Bitcoin Core. Now, many limits were lifted, and I expect more of them will be in the future. And then, if the network would be spammy or unsafe, developers could safely say "it is not our fault, your node, your rules". Do you want to accept all non-standard transactions on mainnet? Because that's where it could lead: all non-standard transactions are valid. And they don't break any consensus rules. Do you want to see 4 MB transactions, using future Segwit versions? Do you want to see future soft-forks activated, without any coordination, just because someone feels like it? It is not yet there, but it is gaining popularity. And who knows, how many people will use a different client in the future? They are now in the minority, but it can change. People in the past also thought, that Bitcoin domination will never fall below 50%, but it did. Every time, when there is some disagreement, there is a risk of splitting users between option A, and option B. Users can run any software they want. The future will tell us, if it is better to lift next limits, and accept any amount of spam, or is it better to drop transactions, and be accused of censorship. And the same is true for any other question: we don't know, which quantum proposal will be activated. Again, there are some options, and different users will make different choices. And only time will tell us, who was right, and who was wrong. Time, and maybe also Proof of Work. Oh, there are "letters", if you need any "official" statement: https://bitcoincore.org/en/2025/06/06/relay-statement/

Bitcoin is open-source, and anyone can download and modify it.But the important thing is that it stays within the rules of consensus, so it doesn’t split off In the end, users choose which software to run. Bitcoin was designed to be money and a monetary network, not a crypto blockchain It’s obvious that Core developers have been under strong influence from the crypto blockchain narrative, as well as from various scammers who exploit that narrative to enrich themselves by creating all sorts of shitcoins, tokens, NFTs, and other nonsense that they dump on naive people.They enabled scams on Bitcoin and don’t want to fix the mistake or fight against the scams and spam As a result, many Bitcoin users don’t want to use the Core software and are switching to Bitcoin Knots Essentially, one side wants Bitcoin only as money and a monetary network, while the other side is more crypto and blockchain oriented. The number of Bitcoin nodes depends on the source and the method of tracking. If you look at public nodes, currently Knots  they make up about 17% of the network. However, there are also private nodes that do not report publicly. Luke Dashjr maintains a page where he tracks all nodes both public and private  and according to his data, the total number of nodes is around 100,000, with Knots nodes accounting for about 13%. https://luke.dashjr.org/programs/bitcoin/files/charts/software.html

Since it's obvious, you won't mind citing concrete evidence in the form of links to posts or interview clips with any developers of Bitcoin core that provide any support for that statement? Because as far as I can tell all the commiters and frequent contributors (*) _hate_ shitcoins and nfts and such-- and what you're saying is a flagrant lie. (*) I specify commiters and frequent contributors because it's an open project that accepts contributions from pretty much everyone, even at times people that most of the contributors hate. If the standard is just any rando that submitted a patch here or there then you say that literally all of them are also speak for knots.

I hate to repeat this again and again, but Knots does exactly nothing against spam. Please educate yourself, e.g. reading the Bitcoin mailing list discussion. If Knots was the reference implementation, and nearly all miners would follow their stricter standardness rules, then this would be a massive incentive to store NFTs in fake public keys or addresses. This would pollute the UTXO set and increase the costs for full nodes to validate the blockchain. See again the prime example Bitcoin Stamps (no link to this service from me, search it yourself). OP_RETURN and the Taproot "exploit" do not have this problem. And as we're seeing in mid-2025 the big fad is already gone. One could also say: Everybody advocating for Knots because of the OP_RETURN "problem" is thus a Bitcoin Stamps shill and wants Bitcoin to be less decentralized.

I am contemplating converting my Core node to Knots, because I do not want the idea to be pushed that nodes can be used to store CSAM or malware payloads. It would be disastrous for the entire community if somebody executes this use case. We will be pushed into an enclave like the Monero community. The last thing we want is for nodes to get regulated, and for people in the government to decide that only financial corporations can run nodes. It means I would have to shut down my node challenge thread. Knots does not stop the spam from entering the blockchain, but it prevents it from being stored on your node which can remove you from liability in cases like what I mentioned.

I forgot who it was, but it was probably a former Bitcoin Core developer who said that Knots' approach to "solve" this issue is like those old network admins in universities that "filer non-academic traffic".   Will those be actual exploits caused by the censoring/"filtering" of the "exploits"?   🤔 Mike In Space is reading through the debate in Reddit, X, Github with a large tub of popcorn.

Actually from one side of things, it doesn't even matter if the stuff in Knots works. You can see it more as behavior which signals disagreements with how Core handled this situation. Anyway in this case, incentives are useless. The consideration is for malicious entities, they don't care about your incentives.   The Taproot thing could have been solved, but alas we tend to open more doors than we tend to close for some reason.. I found the arguments against doing so very unconvincing, especially since this is a an "exploit" in a recently introduced feature.

You're far too late to worry about it. More than 1 decade ago someone already push Wikileaks cablegate data on Bitcoin blockchain[1]. It would be great if your (or anyone else) could show reference that Knots does not store arbitrary data. Last time i checked, Knots only refuse to relay TX that contain arbitrary data. [1] https://www.reddit.com/r/Bitcoin/comments/1bw9xg/data_in_the_blockchain_wikileaks/

Incentives, in a system that runs on incentives, is useless? What did you actually mean by that, ser? I genuinely would like to know the context and what actually you mean by that. ? But weren't dick pics and fart sounds/arbitrary data already were embedded in blocks before? What's the difference between Luke Dash Jr.'s embedded bible passage and any arbitrary data?

The coming changes to Bitcoin Core would force node runners to host all kinds of garbage including images of child pornography and other useless or even illegal material. That is no exaggeration. Since it is against the law to host CP on your computer every node runner would become potential targets of the criminal justice system, through no fault of their own. Which is why I switched to Knots long ago. This would provide governments with a legal justification to shut down bitcoin completely or at least outlaw it in their respective country.   Those who argue that bitcoin should be completely free and wide open to anything, and that anything goes on the bitcoin network as long as you pay the network fees, are complete fucking retarded imbeciles. From the start Bitcoin was created by Satoshi as a monetary network first and foremost and should not be turned into another shitcoin like Ethereum, solana, pepecoin, fartcoin, etc. There are millions of existing chains that shitcoiners can use for that garbage. There is no need, and no sense for bitcoin to do the same.

This only works if the spammer is kind enough to use OP_RETURN or the Taproot/Ordinals method. If he uses a collection of fake pubkeys (Stampchain ...), then you cannot prevent any data to be stored on your node. Not only will it be stored in the blockchain data (which you can prune later), but also in the UTXO set which you need to validate transactions. That's why I consider this "incentive problem" so critical, and judging from the Bitcoindev discussion it was one of the main reasons triggering the decision, alongside with the problem that standardness "violations" are currently happily added by miners and thus there is danger that there's no "common mempool policy". There was a proposal to implement a check that pubkeys must be "real" (i.e. be on an elliptic curve), which means additional ressources needed for tx validation, but it could be worth it if it really was a solution to the problem. This would however make the spam only more expensive for the spammer as he can grind through "real pubkeys which contain his spam data", so if he still wanted damage he could. Even Luke-Jr seems to have admitted (he didn't answer anymore to that thread in the discussion) that the additional validation effort wasn't worth it. My hopes in this field lie basically in new methods to store blockchain, where you could store a set of proofs without storing the complete data. Haven't heard if there was progress on this though. This is of course true. Neither of these methods/filters could do anything for a really malicious party, as they would use the most harmful method no matter what, and thus resorting to Stampchain and friends even with the OP_RETURN door wide open. But the not completely malicious but instead profit-driven folks could behave according to these incentives, see below. I dispute the first part of your sentence. Yes, filters could have worked for some time, but it would have led in a cat and mouse game and much higher development/maintenance cost for Core. And to the "open more doors": The fake pubkey door is the widest one open, and the most harmful. Yes, it is a bit more expensive than Taproot, but Taproot has also some disadvantages. The idea is thus, at least, to nudge the "de facto malicious" spam into OP_RETURN (i.e. not with the intention to attack Bitcoin, but to make profit with NFTs and stuff), before they get the idea to use the Stampchain method and we get much higher node operation costs.