From: "'Fabian' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Saint Wenhao <saintwenhao@gmail.com>
Cc: eric@voskuil.org,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>,
Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing
Date: Sat, 16 May 2026 21:48:41 +0000 [thread overview]
Message-ID: <RiAeHX6Gt48YabQbYIIOFyMF63Pziq12Czi1gSAHlXZ3dBWHIs6l5P-egzOYpyShLUQKVcIeb1pW358WsHR5pALr6T5xAHoN6Igg9Hg0NS0=@protonmail.com> (raw)
In-Reply-To: <CACgYNOJVvO9BgMHspYKyKtcOZZpXqERbwgxnLi=ecTXO8HuM4Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 13880 bytes --]
Hi Eric,
Sorry for the late reply. I'm responding to bits of both your last emails since
they made closely related points.
> It's not at all clear to me how this is a UX improvement. Get started doing what?
Aside from the most obvious case that was already named, receiving payments for
goods and services, I would name mining without a centralized template provider
as an equally important use case.
> Receiving payments without having validated is an exceedingly unwise scenario,
> and not worthy of protocol support.
For most merchants this scenario is much preferred to not receiving payments at
all for an extended period of time if they don't have great hardware and bandwidth
at their store or home. I also need to add that an AssumeUTXO node is not
"not validated". The header chain is fully validated before the snapshot is
loaded, and the historical blocks are validated in the background. The work is
the same, only the node becomes usable earlier.
That IBD sync time has been a real deterrent for users choosing a fully
validating node for their PoS setup is demonstrated by the fact that BTCPayServer
shipped their own AssumeUTXO equivalent before AssumeUTXO existed: https://docs.btcpayserver.org/Docker/fastsync/
They also did so with a worse trust model than what is proposed here, a tarball from
a single trusted source.
> 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.
No such software exists, and I think the reason is that most users would not
bother validating anymore once they have turned to SPV. With AssumeUTXO the
situation is different: there is no option to skip background validation of the
chain.
There will always an alternative solution available for those who don't want to
or can't wait for IBD to finish, and it will always be a worse one than what is
being proposed here. Why should users bother with SPV then? We will continue
to lose users to custodial solutions if we are not willing to offer alternatives
with a UX that at least comes somewhat close to what today's consumers
are used to.
Being able to transact with IBD running in the background also takes away the
economic and other pressure off of those who need to get a node started quickly.
> But of course this presents another problem, that of the cost of validating
> them, requiring full validation of the chain. So this inevitably leads to miner
> commitments.
AssumeUTXO is anchored to a hash that is hardcoded in Bitcoin Core and reviewed
in the open. Anyone running a fully validating node can independently reproduce
it from their own UTXO set. That has no relationship to miner behaviour or
PoW-based commitments, and Strateman's concern with about a >50% attacker
creating new bitcoin, does not apply to it. If anything, providing a working P2P
path for snapshot distribution reduces the pressure for any future commitment
scheme rather than enabling one, because the user-facing problem that motivates
commitments is already addressed.
> Even if for some reason you cannot comment, I and others can.
I did comment, I just pointed out that I cannot disprove something that doesn't
exist. I have not been part of any such conversations and I have not heard of
anyone being part of them.
> It is not hypothetical, and it is dangerous. This understanding is at least
> 11 years old:
Old mailing list conversations are useful context but they don't prove anything.
The author of the original Bitcoin Prototype software also wrote, "I don't
believe a second, compatible implementation of Bitcoin will ever be a good idea"
(https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/69/#2), and
that does not seem to have stopped you from working on libbitcoin. The Strateman
quote is a sound warning about a specific scheme, but it is not a scheme this
BIP proposes.
> These aren't limitations inherent in protocol. The implementation details of a given
> node aren't relevant.
The protocol's job here is to enable obtaining UTXO state from peers rather than from
a third-party website. What each implementation does with that capability is, indeed,
implementation. While AssumeUTXO is the primary motivation right now, there may
be other interesting use cases for this down the road.
> Median U.S. broadband speed
> Despite a 4x max block size increase in 2016, download time is decreasing.
Those figures use US-median broadband. Globally the picture is significantly
different, and a meaningful fraction of users rely on mobile or metered
connections where the difference between "over lunch" and "multiple days"
decides whether they run a node at all. The same applies to the 32 GB RAM
minimum noted for libbitcoin (https://nitter.net/evoskuil/status/2054456087252816267),
which already excludes a large share of consumer hardware outside high-income
regions.
I think disregarding hardware and network requirements of users in less developed
countries is causing much higher centralization pressures today than this UTXO
set sharing proposal ever could. Following the trajectory of the last few years
to its conclusion, the minimum is likely to be 64 GB next year, then 128 GB the
year after, and validating with libbitcoin will soon require the latest generation
of Nvidia chips. Validation time will keep going down on that path, but the
user base it serves will keep shrinking.
I am obviously exaggerating somewhat to make a point: it is easy to construct a
plausible-sounding slippery slope argument, including one about libbitcoin's
hardware trajectory. And I don't think you are able to prove today that libbitcoin
will not follow this path in the future. That is exactly why I don't find
your similar argument persuasive.
And in all seriousness, I think at least some Bitcoin implementations should aim to
be accessible with low bandwidth and minimum hardware requirements compatible
with widely available consumer hardware outside high-income regions. That is
what many of the developers I work with are aiming for.
Best,
Fabian
On Saturday, May 16th, 2026 at 7:58 PM, Saint Wenhao <saintwenhao@gmail.com> wrote:
>> 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](mailto:bitcoindev%2Bunsubscribe@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/RiAeHX6Gt48YabQbYIIOFyMF63Pziq12Czi1gSAHlXZ3dBWHIs6l5P-egzOYpyShLUQKVcIeb1pW358WsHR5pALr6T5xAHoN6Igg9Hg0NS0%3D%40protonmail.com.
[-- Attachment #2: Type: text/html, Size: 19405 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
2026-05-16 21:48 ` 'Fabian' via Bitcoin Development Mailing List [this message]
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='RiAeHX6Gt48YabQbYIIOFyMF63Pziq12Czi1gSAHlXZ3dBWHIs6l5P-egzOYpyShLUQKVcIeb1pW358WsHR5pALr6T5xAHoN6Igg9Hg0NS0=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=aj@erisian.com.au \
--cc=eric@voskuil.org \
--cc=fjahr@protonmail.com \
--cc=saintwenhao@gmail.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