From: <eric@voskuil.org>
To: "'Bitcoin Development Mailing List'" <bitcoindev@googlegroups.com>
Cc: "'Fabian'" <fjahr@protonmail.com>, "'Anthony Towns'" <aj@erisian.com.au>
Subject: RE: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing
Date: Fri, 15 May 2026 20:58:48 -0400 [thread overview]
Message-ID: <002301dce4cf$27bc3040$773490c0$@voskuil.org> (raw)
In-Reply-To: <agenaZ5mfhghneYo@erisian.com.au>
> 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.
next prev parent reply other threads:[~2026-05-16 1:01 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 [this message]
2026-05-16 17:58 ` Saint Wenhao
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='002301dce4cf$27bc3040$773490c0$@voskuil.org' \
--to=eric@voskuil.org \
--cc=aj@erisian.com.au \
--cc=bitcoindev@googlegroups.com \
--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