pull down to refresh

Why Bitcoin Knots instead of Bitcoin Core ? 🧵
294 sats \ 7 comments \ @BITC0IN 14 Jan bitcoin
  1. Knots helps you exercise your self sovereignty verification muscle, instead of conforming to the TrustMeBro defaults of core. Thus you are more prepared to actively defend Bitcoin in case of hardfork-softfork or other shenanigan's.
  2. Knots is more feature rich and useful than core, allowing end users to finely tune their nodes mempool policy to reject spam transactions from their own mempools, through such bitcoin.conf settings as: rejectparasites=1 , datacarrier=0, permitbaremultisig=0
  3. Running a Underdog Bitcoin Client makes the Bitcoin network more robust as a whole. Supporting an ecosystem of multiple compatible clients running in tandem. Running knots makes Bitcoin, the network more robust, and makes the bitcoin development ecosystem richer. Knots is a backup-option in case core becomes obviously compromised. For decentralization, do we really want only a single implementation, with all our eggs in one basket with just bitcoin core? No.
  4. "Knots makes it so that you're not using your node's computing resources to hold and process spam shitcoin transactions and you have better control over what transactions you prioritize processing." - Thus you can save your mempool resources from being abused by bad actors with Knots, but not with core, unfortunately. Core doesn't believe in giving their end users too much choice. This has long been their attitude: to dictate down and deny non-consensus violating choice to end users.
  5. Thus running Knots is a counter movement to the unfortunate attitude in core that has willfully neglected a core subset of it's users who care about spam filters. Running Knots is not just a technical improvement in running Bitcoin. It's a political statement in the Bitcoin development ecosystem. ie
No. Not Good Enough. I get to run the code I want within consensus and you can't stop me. That's Bitcoin.
You can download Bitcoin Knots at http://BitcoinKnots.org
Be sure to verify your download. Exercise your verification muscles.
For a full list of Bitcoin Knots features versus Core, see: https://bitcoinknots.org/files/27.x/27.1.knots20240801/bitcoin-27.1.knots20240801.desc.html
A related video on the subject by Matthew Kratter: https://www.youtube.com/watch?v=Pgab8FuBwgg&ab_channel=BitcoinUniversity
write
preview
related posts
9 sats \ 0 replies \ @ZezzebbulTheMysterious 15 Jan
“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. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.” SN, 2010
If you run knots, you are a fool for ignoring this wisdom.
reply
0 sats \ 5 replies \ @ZezzebbulTheMysterious 15 Jan
A just saw the Kratter video where he said to runs knots. Kratter is wrong about this and wrong about client diversity increasing the resilience of the network. He also said if the devs act in bad faith their rep would be known. Oh we know indeed.
Satoshi addressed this in 2010, the quote is in the other comment.
reply
0 sats \ 4 replies \ @BITC0IN OP 15 Jan
So satoshi was wrong about a lot of things. He may have been right at the time though with this comment, given Bitcoin's infancy.
But things change, contexts evolve.
In the current environment, people are trusting core implicitly, and not verifying it. As a result core's become a bit of a monolith monopoly which can and has dictated down it's preferences to end users for non consensus parameters, such as filters.
Bitcoin the network is now robust enough to welcome in competing but compatible Bitcoin clients that won't be menaces to the network, but strengths.
You don't have to participate, run core, or not at all. But you can't prevent anyone else from running their version of Bitcoin. It's free open source software.
That's part of the reason for, why run knots. It's taking your liberty instead of asking for it. An expression of the Bitcoin ethos, to run the code you want in this world.
reply
0 sats \ 3 replies \ @ZezzebbulTheMysterious 16 Jan
I fundamentally disagree and think that Satoshis words are timeless here. Knots does not add anything here. If “core” aka Bitcoin does something else, knots is not in a position to enforce consensus. It’s a minority fork, and we have dealt with these before.
Knots is nothing but a hard fork risk created by a sick man.
This is all the part of the evolution of any memetic structure where false prophets lead the unwise into poverty.
reply
0 sats \ 2 replies \ @BITC0IN OP 16 Jan
I think you're missing the point though. Knots does add something here. At minimum a faster IBD then core, and filters to exclude spam transactions from abusing my nodes mempool resources.
It's not a fork in the way you describe. It's a within consensus fork, still part of the consensus majority.
I don't believe luke is a sick man. Even if he was, that should be beside the point. Knots is open source bitcoin software. you can verify it for yourself.
As for being a hardfork risk. That risk is vastly overstated and could actually be a good thing. If we find a hardfork bug through some oddity, when the design spec is to be within consensus, then we've discovered a bug worth discovering, and can patch it.
reply
0 sats \ 1 reply \ @ZezzebbulTheMysterious 16 Jan
You are right in that I cannot stop you running it, nor do I really care to stop you. I can just warn of the risks. If you have been around a while, you know the history for that developer. I lost trust when he messed with the gentoo package.
Bitcoin does not have a formal spec. It has an implementation, and someone elses interpretation of that implementation called Knots. There is no 'within design spec but wrong implementation in Core'. There is just the core implementation.
If there is a bug in Knots, the rest of the network will reject its blocks and it will hard fork. Its not an 'opportunity to fix core'.
reply
0 sats \ 0 replies \ @BITC0IN OP 16 Jan
well it could be, since such a bug would reveal a consensus rule previously unknown, that would then likely need to be accounted for by core with guard rails. theres been examples of this in the past.
its interesting you bring up the gentoo issue too. someone else said the same thing to me recently. https://www.reddit.com/r/Bitcoin/comments/2iuf4s/lukejrs_public_apology_for_poor_gentoo_packaging/
from my reading, this was an unintentional fuck up, that had no effect on anyone? that he maturely owned up to.
nullc even states in that thread "OTOH, while I strongly disagreed with the 'anti-spam' approach (and had long been nagging luke to do more pure behavioral matching on the abusive transaction behavior (censor-magnet, and UTXO bloating)), I am a little sad to see many people criticising a different distribution of Bitcoin Core not just for its own policy decisions but for being different at all.
There is no mandatory official Bitcoin, and when it comes to node policy-- (not consensus rules, of course)-- diversity is valuable, and people should have the ability to control what their computers are doing, how their resources are being spent, etc."
reply