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