From: Lőrinc <paplorinc@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts]
Date: Mon, 29 Sep 2025 11:24:16 -0400 [thread overview]
Message-ID: <CALL0pNFxsRCF00CN3YwSZOnoATB=zAdZQXpKvy_4oAOjRx40=A@mail.gmail.com> (raw)
In-Reply-To: <CALL0pNF4b+rNYrgws0QY_LQP6QeVMEhLiOrFL4f-H3Ahf2ePDw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4177 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 5178 bytes --]
prev parent reply other threads:[~2025-09-29 15:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 13:26 Andrew Poelstra
2025-09-26 21:50 ` Chris Guida
2025-09-28 23:46 ` Andrew Poelstra
2025-09-29 13:11 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-09-29 13:41 ` /dev /fd0
[not found] ` <CALL0pNF4b+rNYrgws0QY_LQP6QeVMEhLiOrFL4f-H3Ahf2ePDw@mail.gmail.com>
2025-09-29 15:24 ` Lőrinc [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALL0pNFxsRCF00CN3YwSZOnoATB=zAdZQXpKvy_4oAOjRx40=A@mail.gmail.com' \
--to=paplorinc@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox