This is a slightly friendlier version of a previous reply I sent to Chris already:

--------

> The tripling of the utxoset within a couple of years has raised the minimum cost of joining the network from ~$150 to ~$250

I will be short: we want blocks to be full, blockchains are meant to grow, and even cheap nodes were more expensive in the past than what we can have now (which are also a lot more performant).

I bought a node in 2021 for ~$330 (which is ~$400 inflation adjusted) and it struggled with 700k blocks for weeks: https://x.com/L0RINC/status/1968189583180579188
If you're into storing the whole chain for some reason, you can have the same for ~$170 now and it will finish IBD in less than 1 day, depending on your internet speed (with average global speed just downloading it takes ~16 hours), see https://x.com/L0RINC/status/1967679285168386135.
But you can also get a very good fully validating pruned node for $111 (e.g. https://gist.github.com/l0rinc/5a44ffa174857bc9c680a8e4bfc40a88), which can likely finish an IBD in ~2-3 days.
You can even buy one for $99, but that would indeed be quite slow, but even that would likely finish IBD in a week. You can go even cheaper with second-hand hardware. But I'm not sure why we would want to go lower than the price of a single night in a hotel...

> core devs have done nothing to prevent it from happening again

Core devs progressively made the latest version 250% faster than v23 https://x.com/L0RINC/status/1970918510248575358.
And we still have other unmerged optimizations, so the situation is expected to be even better in upcoming releases. On my laptop our unmerged changes can fully reindex in ~2 hours. And with a SwiftSync prototype I have even done a reindex-chainstate on a battery-powered cheap rpi5 (+ monitoring over wifi) in ~3:14 hours (pi on a pi - and the batteries were still 70% full): https://x.com/L0RINC/status/1972062557835088347.
The situation has never been better, you can now do IBD from batteries!

> core devs should listen to their users

Twitter is not a representative sample (and neither are you).
In the free market, participants produce stuff and the usage is the feedback, not the online complaining.

> the most popular merchant node hardware (the RPi 4B 4GB) can no longer sync the chain in under a month, and the next cheapest hardware that can do so is much more expensive.

I also retested an old Raspberry Pi 4b with 8gb: IBD with v30 finished in 71h 36m 44s (<3 days) until ~916k blocks with default dbcache.
With a 5GB dbcache it would likely be even faster, I just wanted to see the worst case.

> Reducing data spam (or utxoset workarounds like libbitcoin) are what we should be focusing on to increase participation in the node network.

I don't see how spent + unspent can be smaller than just the unspent set.

> but practically everyone with a low-resource node noticed extreme increases in IBD times due to spam

It's not the "spam", that's very cheap to validate. They just likely forgot to update the node (leaving the assumevalid height early and they're doing too many useless script validations) or are writing on cheap SD cards with 10MB/s rate or are doing IBD over TOR or are leaving the dbcache size at default or increasing it to the total memory size and are constantly swapping, or have enabled all optional indexes, etc.
I agree these should be better documented, it's why https://github.com/bitcoin/bitcoin/pull/33336 and https://github.com/bitcoin/bitcoin/pull/33333 were opened: if only you used all this anger to educate people and help, instead of blaming the firetruck for the fire...

> The purpose is to raise costs on spammers

Why do you focus on hating people who disagree with you, even when that hurts honest participants?

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALL0pNFxsRCF00CN3YwSZOnoATB%3DzAdZQXpKvy_4oAOjRx40%3DA%40mail.gmail.com.