From: sadiq Ismail <ask4ismailsadiq@gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing
Date: Sun, 17 May 2026 10:50:00 +0200 [thread overview]
Message-ID: <CAHR1cdXgkh=6J1KgpYcHH2-wpPDzJhQMkuJXi0oci7-HcORr-w@mail.gmail.com> (raw)
In-Reply-To: <26c7fd2e-d35d-4ed4-9638-18c95efc75dfn@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 5833 bytes --]
Hi Eric, Fabian, and list,
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.
I will share mine. The average Nigerian individual and business uses 4G
broadband from one of the telco providers, using MTN here as an example,
though all have relatively the same speed:
Download Speed: Up to 150Mbps
Upload Speed: Up to 50Mbps
These are advertised maximums; real world speeds are considerably lower.
I can use wallets to receive Bitcoin as an SPV, but once you want to sync
the blockchain and have a node synced to the tip, I face a significant
bottleneck.
The download was taking days due to frequent internet blackouts and other
constraints. I think if a less-trusted setup were provided, like assumeUTXO
with p2p sharing,
Since my use case is data analysis, not receiving payments, I would not
face this bottleneck and would definitely use it.
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.
The risk of the chain growing so large that syncing takes a long time is
real, and I believe people from my background will simply assumeDatadir
because of the cost/time of getting to the tip. It is worth noting that
some also that some western cloud providers do not serve Nigeria at
all. Hetzner, for example, does not, which makes robust cloud-based
workarounds unavailable to us (This is changing very quickly with the
recent trend of native African data centres).
AssumeUTXO helps eliminate that, because at least you are not trusting one
person but a group of contributors committing to a hash, with headers-first
sync and other safeguards assumeUTXO provides. The use case for assumeUTXO
is very real and solves a real problem.
However, I am also concerned about the trust tradeoffs for users who want
to validate. Having assumeUTXO may not incentivize innovations for speeding
up IBD for Eric's demographic, and alternative approaches could be
dismissed with: why speed up IBD if we have assumeUTXO? I think that should
not be the case. AssumeUTXO is specifically tailored for certain users, but
pursuing fast IBD with abundant resources is not necessarily in conflict
with that. One can throw resources at IBD compute, use libbitcoin-style
sync with faster peers, and get up to speed quickly, while the other simply
CANNOT.
AssumeUTXO is, in my opinion, a lesser evil than, for example,
assumeDatadir. I honestly do not like the tradeoff of having the software
commit the hash or the complexity of multiple chain states in the Bitcoin
Core codebase. It still has good utility and reduces tradeoffs, so I will
not dismiss it completely.
https://shop.mtn.ng/mtn-4g-broadband-router.html
*https://www.reddit.com/r/hetzner/comments/1ajkhp0/reasons_for_rejecting_creation_of_account/
<https://www.reddit.com/r/hetzner/comments/1ajkhp0/reasons_for_rejecting_creation_of_account/>*
On Sun, May 17, 2026 at 4:10 AM Eric Voskuil <eric@voskuil.org> wrote:
> From: Fabian
>
> > The header chain is fully validated before the snapshot is loaded,
>
> Validating the headers is inconsequential if you are not verifying tx
> inclusion. That's what SPV is, and people should not be misled into
> believing that this is SPV.
>
> > and the historical blocks are validated in the background.
>
> The issue is the time before that completing. After validating it's moot.
>
> > The work is the same, only the node becomes usable earlier.
>
> Until the work is complete the node is not usable in the sense of a node -
> it hasn't validated.
>
> > 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.
>
> In this proposal there is no statement that everyone must trust Bitcoin
> Core. The proposal specifically states:
>
> "The Merkle root is the sole trust input required to verify the
> integrity of the received UTXO set."
>
> and
>
> "[The Merkle root is]... either from a trusted source or by selecting
> a root with agreement among multiple peers."
>
> The "agreement among peers" is why Bitcoin exists, so we can dismiss that
> as an infinite regression.
>
> Above you make the explicit claim that Bitcoin Core is the oracle for this
> "sole trust input". If that is the case you should add it to the proposal
> so that people are fully aware.
>
> If so the proposal establishes a central authority for validity. If not
> then we are back to the original problem that Bitcoin supposedly solved -
> where does this agreement come from.
>
> 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/26c7fd2e-d35d-4ed4-9638-18c95efc75dfn%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/26c7fd2e-d35d-4ed4-9638-18c95efc75dfn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAHR1cdXgkh%3D6J1KgpYcHH2-wpPDzJhQMkuJXi0oci7-HcORr-w%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 7481 bytes --]
next prev parent reply other threads:[~2026-05-17 11:56 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 [this message]
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='CAHR1cdXgkh=6J1KgpYcHH2-wpPDzJhQMkuJXi0oci7-HcORr-w@mail.gmail.com' \
--to=ask4ismailsadiq@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=eric@voskuil.org \
/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