I see way too many people on Nostr that are still confused about the Core vs Knots debate. This is a tl;dr for them. If a longer explanation is needed, they should go over the website below. tl;dr: SegWit introduced the witness discount, that ended up making junk data up to 75% cheaper, which opened the door for arbitrary data-carrying transactions to directly compete with monetary transactions for blockspace. In practice, that ended up being an unintended de facto subsidy for spam. Taproot then provided a way for inscriptions to sidestep the old datacarriersize filter, which is why the UTXO set exploded from around 4 GB in 2023 to nearly 12 GB by 2025, putting real strain on low-end node hardware. Meanwhile, the Core devs’ reaction has been pathetic — hand-waving it away for two whole years as “free market dynamics” or saying that fixing the exploit is considered “controversial”. At the same time they did a stealth documentation change to pretend the broken filter is “working as intended”. @npub100ma...fyy5 caught them red handed, but instead of apologising for hiding it, they claimed that changing the documentation is a valid way for fixing bugs. Now they’re doubling down their efforts “to fight spam” they willingly allowed by gutting another spam filter (OP_RETURN) that has worked for 11 years, and helped keep 99.9% of all OP_RETURNs at or under 80 bytes. Larger payloads were possible, but never at the absurd size of 100 KB in a single output. Core v30, due in early October, will raise the default limit to 100 KB (an 1200x increase), which makes it trivial to upload entire malware files or worse straight into the chain. This isn’t hypothetical — when BSV made the same change in 2019, it was immediately hit with child p[]rn. The legal and practical fallout for Bitcoin node operators, especially those on cloud infrastructure, hasn’t even begun to be fully grasped. All these absurd and rushed decisions raise the obvious questions: why push this change through despite massive pushback; who stands to profit from it; and why are the real risks of this happening being ignored or swept under the rug?

Replies (37)

core runs on an rpi. knots does not. therefore, running knots is not the solution, it is the problem it's been a long time since i did an ibd, but i'll think about testing low memory configs. are you running something like start9 or umbrel? and how did you install bitcoin? image
That's one of the most clueless takes I've heard yet. Yes the UTXO has ballooned out, for all clients Core and Knots both. How is it irrelevant??
core demonstrates that a simple counting of the UTXO set size isn't relevant to whether you can run on an rpi. if you are running knots on limited hardware and it's unable to sync, running core is a solution
Ah, I thought pruned nodes cut off transactions that are older then some date to reduce data 🤔 I was thinking about keeping all the transactions since the Genesis but just not saving the unnecessary stuff 😅
I run Knots on an old laptop. I also run core on another (relatively new, low end laptop) for my BTCPay server. Both machines are with 8 gigs of RAM, and both took around 4-5 days to fully sync. Haven’t tried on a rpi, but a couple of people I’ve talked about trying to do a fresh IBD at 4 gigs told me it took them more than 10 days to finish over a decent internet connection.
The Core one is. The Knots one I run on Windows, since I feel more comfortable with it. But this wasn’t an option for the BTCpay server, so I went with Core, since it’s easier to setup (more manuals available).
Gotta get sleep. Bookmarked and commented to remind me to read this mañana. Gn cruel world.
Lazarus Long's avatar
Lazarus Long 3 months ago
Is your 2gb ram rpi node pruned? Can you do much with 2gb ram? I imagine that would struggle to run electrum server in parallel? But the UTXO set never needs to be fully stored in ram so I think your initial point is mute. No one but ordinals scammers benefited from a tripling of the utxo set in 2 yrs.
Lazarus Long's avatar
Lazarus Long 3 months ago
Core: We're going to enforce fundamental changes that noone asked for and with minimal user benefit while ignoring the likelihood of unknowable consequences. ynniv: Knots is clearly the problem here.
just to add some details: tapscript size being unlimited caused the inscriptions, which is in the witness data. before taproot, with segwit v0 there was a P2WSH script size limit, which limits the size of witness while spending a P2WSH output. this whole file is about policy settings, aka filters. these settings are policy so we don't have to fork the chain each time we wanna change these. if you are asking what does this have to do with P2WSH, witness data is in the input side of the tx. so meaning of witness data is decided by scriptPubKey of the output we are spending. of course inscriptions were possible before taproot, but only really small images. or you had to split it into multiple inputs. which increases the total size and fee you have to pay. tapscript(which is basically witness space in taproot) being unlimited made it attractive as blob data storage. we can limit the tapscript size, or we can detect inscriptions specifically and other similar methods and filter them specifically, because they are using the script space as data storage, which is unintended use. parasite. knots does similar stuff.
The blocksize war in 2014-2017 was about two things. Everybody knows about the first. 1] Increasing blocksizes to allow more (not infinite) transactions on chain. Many people saw this as an attack against the viability to run nodes on RaspberryPis ultimately leading to centralisation 2] Rejection of ugly Segwit code The second ultimately lead to the fork as blocksize increases could have been introduced at a later stage (BCH increased to 32M + a growth algo that keeps spammers in check)
Plot twist: The real secessionists already happened in 2017. Core vs Knots is just a reignition of old front lines.
Tauri's avatar Tauri
I see way too many people on Nostr that are still confused about the Core vs Knots debate. This is a tl;dr for them. If a longer explanation is needed, they should go over the website below. tl;dr: SegWit introduced the witness discount, that ended up making junk data up to 75% cheaper, which opened the door for arbitrary data-carrying transactions to directly compete with monetary transactions for blockspace. In practice, that ended up being an unintended de facto subsidy for spam. Taproot then provided a way for inscriptions to sidestep the old datacarriersize filter, which is why the UTXO set exploded from around 4 GB in 2023 to nearly 12 GB by 2025, putting real strain on low-end node hardware. Meanwhile, the Core devs’ reaction has been pathetic — hand-waving it away for two whole years as “free market dynamics” or saying that fixing the exploit is considered “controversial”. At the same time they did a stealth documentation change to pretend the broken filter is “working as intended”. @npub100ma...fyy5 caught them red handed, but instead of apologising for hiding it, they claimed that changing the documentation is a valid way for fixing bugs. Now they’re doubling down their efforts “to fight spam” they willingly allowed by gutting another spam filter (OP_RETURN) that has worked for 11 years, and helped keep 99.9% of all OP_RETURNs at or under 80 bytes. Larger payloads were possible, but never at the absurd size of 100 KB in a single output. Core v30, due in early October, will raise the default limit to 100 KB (an 1200x increase), which makes it trivial to upload entire malware files or worse straight into the chain. This isn’t hypothetical — when BSV made the same change in 2019, it was immediately hit with child p[]rn. The legal and practical fallout for Bitcoin node operators, especially those on cloud infrastructure, hasn’t even begun to be fully grasped. All these absurd and rushed decisions raise the obvious questions: why push this change through despite massive pushback; who stands to profit from it; and why are the real risks of this happening being ignored or swept under the rug?
View quoted note →
WTFhappenedinfeb2023 dot com is a real treasure when it comes to context about the current Spam War. If one day there is a book similar to the Blocksize War, this would probably be the main citation source for it. View quoted note →
the changes aren't fundamental, and the user benefit is a healthier bitcoin. we can infer the consequences by using the grey matter between our ears, or at least between my ears. no one ever asks for less complexity, and you're welcome to run whatever floats your boat
CTV is probably not gonna happen anytime soon and part of the reason is that pro filters and sandwichheads don’t like each other.
it's an 8gb rpi that has 6gb available. i recently enabled pruning because it has 1TB of drive space, but memory usage is the same > But the UTXO set never needs to be fully stored in ram so I think your initial point is mute first off, you mean "moot". second, you guys suck at arguing. it's like a fallacy tasting menu. the central argument is that core is making decisions which prevent people from using raspberry pi class computers as bitcoin nodes. this is demonstrably false, as a well run node currently uses 2gb of memory. some rpi installations are running out of memory, and on inspection it appears that knots/datum is a pig. if you are adamant about running knots/datum, perhaps they can be more efficient with memory usage. if not, it's easy enough to run core instead