Replying to 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”. nostr:nprofile1qqs8ha7ms0mny284ma46xjzf72hel42t74jmtttf3trssfymxyq8ngqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3gamnwvaz7tmwdaehgu3wdau8gu3wv3jhv72x8mv 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?

https://wtfhappenedinfeb2023.com

"to nearly 12 GB"

and yet, my core rpi node uses less than 2GB of RAM. i can't take this position seriously - knots claims to be the defender of rpi nodes, but from what i have seen, *only knots* uses 12GB of RAM. i'm sure there's some optimizations going on in core, but at the end of the day it's an irrelevant detail.

knots is the problem, not the solution

Reply to this note

Please Login to reply.

Discussion

You know most of that RAM matters during the IBD, right? Have you tried re-downloading the whole chain from scratch? See how much time will take?

I also fail to see how Knots is the problem. Maybe you wish to elaborate.

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?

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.

🤔 these are manual installs on linux?

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).

is it one of these deployment options? what core version / Linux distro? https://docs.btcpayserver.org/Deployment/

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.

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

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

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.

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