From: Eric Voskuil <eric@voskuil.org>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing
Date: Sun, 17 May 2026 14:29:57 -0700 (PDT) [thread overview]
Message-ID: <c92abfec-e3af-42bc-b371-36e209f1727en@googlegroups.com> (raw)
In-Reply-To: <CAHR1cdXgkh=6J1KgpYcHH2-wpPDzJhQMkuJXi0oci7-HcORr-w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4093 bytes --]
> From: sadiq Ismail
Hi sadiq,
> I am from a place with metered and slow bandwidth, so assuming U.S.
> internet bandwidth and speed specifications for IBD is incorrect and
ignores
> that not everyone shares the same reality.
No such assumption has been made. My post specifically addressed the
performance *trend*, which contrary to common assumptions, is improving
(everywhere) and will eventually render this question moot.
> I will share mine.
No number of performance anecdotes can address the outstanding critiques,
but I'm happy to cover the other issues.
> I can use wallets to receive Bitcoin as an SPV
Okay, which is far better than a trusting wallet.
> but once you want to sync the and have a node synced to the tip,
> I face a significant bottleneck.
Why are you syncing the node? Presumably you want a fully validated node -
for better than SPV security. You cannot get that from assuming it. You
should sync and validate a node and then just connect your SPV wallet to
it. This transitions you to actual full node security from SPV security,
once that full node security actually exists.
> I think if a less-trusted setup were provided, like assumeutxo
Assuming is not "less trusted", it's fully trusted. I think you meant "less
trustworthy".
> with p2p sharing, Since my use case is data analysis, not receiving
payments,
> I would not face this bottleneck and would definitely use it.
It's not clear why you would want a less trustworthy (fully trusted) wallet
when you can use a far more trustworthy SPV wallet. And you can transition
that same wallet to zero trust once your node is validated, by just
pointing your SPV wallet to the node. Furthermore you are not providing any
justification for moving this into P2P, the trusted node feature you want
already exists.
> As a real example of the point Fabian made about using worse
alternatives: I
> also travelled hundreds of kilometres to a different city to
assumeDatadir by
> copying the datadir from a trusted friend.
Incorporating Core's trusted utxo system into the P2P network does not
change this at all. You could have just downloaded it from your friend, or
anyone else you trust to provided it. Certainly that's better than
downloading it from randos on the P2P network. And you would have the same
download cost either way.
> The risk of the chain growing so large that syncing takes a long time is
real
The opposite is happening. This is why I pointed out the declining cost
trend. That applies everywhere, not just in the US. And in any case, trust
would not be a solution. That's the problem Bitcoin exists to eliminate.
> AssumeUTXO helps eliminate that, because at least you are not trusting one
> person but a group of contributors committing to a hash
Who is the "group of contributors" that we are assuming has become the
central authority on what is valid? I do not see this listed in the BIP. Is
there to be a public key provided somehow so that we can all be assured
that we are trusting the right authority? If only someone could devise a
solution to this problem.
> with headers-first sync and other safeguards assumeUTXO provides.
There are no such other "safeguards". Headers first is DoS protection. This
is not an SPV implementation.
> AssumeUTXO is, in my opinion, a lesser evil than, for example,
assumeDatadir.
This is a false dichotomy. Using an SPV wallet while syncing your node is a
far more secure and more efficient existing alternative. And it has the
actual security that people seem to be assuming this has (see your headers
comment above). There is no reason to choose any evil, and certainly no
reason to impose it on the P2P network.
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/c92abfec-e3af-42bc-b371-36e209f1727en%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4671 bytes --]
next prev parent reply other threads:[~2026-05-17 21:32 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
2026-05-17 2:09 ` Eric Voskuil
2026-05-17 8:50 ` sadiq Ismail
2026-05-17 21:29 ` Eric Voskuil [this message]
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=c92abfec-e3af-42bc-b371-36e209f1727en@googlegroups.com \
--to=eric@voskuil.org \
--cc=bitcoindev@googlegroups.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