From: Saint Wenhao <saintwenhao@gmail.com>
To: eric@voskuil.org
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>,
Fabian <fjahr@protonmail.com>, Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing
Date: Sat, 16 May 2026 19:58:24 +0200 [thread overview]
Message-ID: <CACgYNOJVvO9BgMHspYKyKtcOZZpXqERbwgxnLi=ecTXO8HuM4Q@mail.gmail.com> (raw)
In-Reply-To: <002301dce4cf$27bc3040$773490c0$@voskuil.org>
[-- Attachment #1: Type: text/plain, Size: 7410 bytes --]
> I commonly see people expecting IBD to take a week or more
Because it is true, at least for me, and maybe also for some others. You
can read some examples on forums, where people run full nodes, and post
their progress on a regular basis:
https://bitcointalk.org/index.php?topic=5480200
Currently, I started Initial Blockchain Download on some node. It is now
around block 250,000, after few hours. It shows around 1 MB/s in the
"Network Traffic" tab from the GUI client. Even if my Internet speed may be
better than that, then still: it is limited by what my peers can provide.
And if I check 10 connected nodes, and all use NETWORK_LIMITED flag, so all
are in pruned mode, and all just act as proxies, fetching blocks from other
full, archival nodes, then guess what: it is limited to the weakest link,
the slowest node in the chain of connections.
When I did the same experiment some months ago, but this time from some
VPS, running 24/7, my results were quite similar. Waiting around a week to
be fully synced is normal for me, and I got used to that.
Also, I understand, why full, archival nodes, use rate limits: because
otherwise, they would pay more bandwidth fees, if everyone would be able to
get everything instantly, at full speed. Which is why when many people
limit their connections, to not share too much data too fast, it is what it
is. And it is normal, because nodes are not rewarded for their services, so
they have no incentive to provide more, than the bare minimum they can
handle.
sob., 16 maj 2026 o 03:01 <eric@voskuil.org> napisał(a):
> > From: Anthony Towns
>
> > On Tue, May 12, 2026 at 11:56:33AM -0400, eric@voskuil.org wrote:
> > > > AssumeUTXO is a UX improvement for those interested in running a
> > > > fully validating node. The option to get started in a very limited
> > > > amount of time [...]
>
> > > It's not at all clear to me how this is a UX improvement. Get started
> doing
>
> > what?
> >
> > Getting started validating blocks and transactions at the current tip; ie
> > receiving payments.
>
> Receiving payments without having validated is an exceedingly unwise
> scenario, and not worthy of protocol support.
>
> If you have not fully validated every block in history, you have not
> validated at all. The validity of a block requires the validity of all
> prior blocks.
>
> There seems to be a common misapprehension that using a trusted utxo store
> is something akin to SPV. This is not the case. A node/wallet could
> certainly also implement SPV and use it while downloading/validating,
> though that eliminates the use case for trusted utxo state.
>
> Using a trusted utxo store for transacting is equivalent to a fully
> trusting wallet. The person is 100% trusting that the state of their node
> is valid - having not validated any of it until having validated all of it.
> Accepting this as a matter of protocol is irresponsible.
>
> If you want a reduced (vs. zero) level of security while downloading and
> validating the chain, I suggest implementing an SPV wallet that transitions
> to a full node wallet after downloading and validating the full chain.
>
> > Obtaining the full Bitcoin blockchain currently requires downloading
> about
> > 600GB of data. At 250Mbps with perfectly well-behaved peers, that's a bit
> > under 7 hours. At the consumer level, bandwidth seems to be the
> bottleneck,
> > with modern PCs being able to validate the blockchain in about that time.
>
> Let's look at the trend:
>
> May 2016
> ---------------------------------------------------------------------------
> Blockchain size: ~80 GB
> Median U.S. broadband speed: 39 Mbps
> Download time: 4 hours 33 minutes
>
> 80 × 8,000 = 640,000 Mb
> 640,000 ÷ 39 ≈ 16,410 seconds
> 16,410 ÷ 3,600 ≈ 4.558 hours (4 hours 33 minutes)
>
> May 2021
> ---------------------------------------------------------------------------
> Blockchain size: 343.5 GB
> Median U.S. broadband speed: 100 Mbps
> Download time: 7 hours and 38 minutes
>
> 343.5 × 8,000 = 2,748,000 Mb
> 2,748,000 ÷ 100 = 27,480 seconds
> 27,480 ÷ 3,600 ≈ 7.633 hours (7 hours and 38 minutes)
>
> May 2026
> ---------------------------------------------------------------------------
> Blockchain size: 739.2 GB
> Median U.S. broadband speed: 308 Mbps
> Download time: 5 hours and 20 minutes
>
> 739.2 × 8,000 = 5,913,600 Mb
> 5,913,600 ÷ 308 = 19,200 seconds
> 19,200 ÷ 3,600 = 5.333… hours (5 hours and 20 minutes)
>
> ---------------------------------------------------------------------------
>
> Despite a 4x max block size increase in 2016, download time is
> *decreasing*.
>
> It only increased in early years because blocks went from empty to ~full
> (median block ~1MB in 2016), coupled with segwit 4MB limit impact.
>
> > AssumeUTXO significantly reduces the download requirement, with the utxo
> > snapshot at block 935000 being under 9GB. At 100Mbps with perfectly well-
> > behaved peers, that's about 15m to download. Adding in another 8GB-34GB
> > of actual block data to download (assuming that the utxo snapshot people
> use
> > will be between 4 and 17 weeks out of date) brings that up to 30 minutes
> to
> > an hour.
>
> Downloading an additional 9GB only increases the total download
> requirement/time.
>
> What has been increasing is the perception of increased block data
> exceeding Moore's Law. This perception has fed the spam debacle. This
> perception is rooted in the reality that sequential indexation (even
> without validation) does not (cannot) fully take advantage of advancing
> hardware. This is an implementation issue.
>
> Chain growth is linearly bounded. Hardware growth at a given cost is
> exponential. Even Satoshi reasoned this out. What he didn't do in his
> prototype was provide a scalable implementation - he left that to us.
> Necessary download and validation time/cost is shrinking. Eventually
> downloading and validating the chain will be as cheap as texting a video
> clip has become. It wasn't long ago that too was unthinkable.
>
> On a fast home Internet today, on the same machine I've been developing on
> since 2017, the full chain can be downloaded and fully validated in under 5
> hours. That's less time than it took almost 10 years ago on the same
> machine - and my real Internet cost today is about half what it was at that
> time.
>
> So I reiterate my NACK. This is a very unwise idea, without justification
> for network protocol integration.
>
> Best,
> Eric
>
>
> --
> 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/002301dce4cf%2427bc3040%24773490c0%24%40voskuil.org
> .
>
--
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/CACgYNOJVvO9BgMHspYKyKtcOZZpXqERbwgxnLi%3DecTXO8HuM4Q%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8552 bytes --]
next prev parent reply other threads:[~2026-05-16 21:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 15:36 [bitcoindev] [BIP Draft] P2P UTXO Set Sharing 'Fabian' via Bitcoin Development Mailing List
2026-05-05 16:01 ` [bitcoindev] " Eric Voskuil
2026-05-06 1:06 ` Antoine Riard
2026-05-07 21:50 ` 'Fabian' via Bitcoin Development Mailing List
2026-05-07 21:34 ` 'Fabian' via Bitcoin Development Mailing List
2026-05-12 15:56 ` eric
2026-05-15 23:08 ` Anthony Towns
2026-05-16 0:58 ` eric
2026-05-16 17:58 ` Saint Wenhao [this message]
2026-05-16 21:48 ` 'Fabian' via Bitcoin Development Mailing List
2026-05-17 2:09 ` Eric Voskuil
2026-05-17 8:50 ` sadiq Ismail
2026-05-17 21:29 ` Eric Voskuil
2026-05-18 1:36 ` Eric Voskuil
2026-05-19 8:36 ` 'Fabian' via Bitcoin Development Mailing List
2026-05-19 23:20 ` Eric Voskuil
2026-05-16 22:39 ` Eric Voskuil
2026-05-19 9:32 ` josie
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='CACgYNOJVvO9BgMHspYKyKtcOZZpXqERbwgxnLi=ecTXO8HuM4Q@mail.gmail.com' \
--to=saintwenhao@gmail.com \
--cc=aj@erisian.com.au \
--cc=bitcoindev@googlegroups.com \
--cc=eric@voskuil.org \
--cc=fjahr@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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