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: Sat, 16 May 2026 15:39:45 -0700 (PDT) [thread overview]
Message-ID: <1c46393e-ab63-47f3-b0c5-4e79cfb6696dn@googlegroups.com> (raw)
In-Reply-To: <CACgYNOJVvO9BgMHspYKyKtcOZZpXqERbwgxnLi=ecTXO8HuM4Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3373 bytes --]
> From: Saint Wenhao
> Even if my Internet speed may be
> better than that, then still: it is limited by what my peers can provide.
This is a reasonable assumption, but it is not correct. P2P download speed
is limited only by your bandwidth, not that of your peers. If you have
extra capacity you add more peers. You drop the slower peers and connect to
the faster peers - the ones offering capacity. You use standard deviation
to detect which peers are slow. This will rapidly saturate your bandwidth,
and is optimal for the P2P network. Your node may be pounding away at
someone's laptop until timeout because the node software doesn't work this
way. That's an implementation issue.
> 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.
This isn't how the protocol works. Addresses are advertised with their
service bits. A node attempting to download blocks should not be connecting
to a pruned peer. This is why this service bit exists. This is also why
pruning is not good for the network. In 12 years of writing node software I
have never seen peers produce a download limit. The chain can be
consistently downloaded at the theoretical limit based on own bandwidth. We
commonly operate from 1-2.5 Gbps and peers are never limiting.
> 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.
Throttling is not a problem for the same reasons discussed above. Download
time is local bandwidth limited, not peer limited. If you are downloading
at a rate below your available bandwidth it is either because your hardware
cannot keep up with your available bandwidth, or the software is not
designed to.
Finally, I posted example bandwidths and related times over five and ten
year periods to show the strongly declining relative trend despite strongly
increasing data. There is no need anecdoting about bandwidth. It's easily
obtained public information and a straightforward process to determine
download time from these numbers.
https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds
> It shows around 1 MB/s in the "Network Traffic" tab from the GUI client.
This is about 1/5 of an Eritrean mobile phone, the slowest mobile rate on
Earth, or 1/4 of a Cuban land line, the slowest wire rate on Earth. Seems
like there's more going on here than bandwidth, but it is not caused by
peers.
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/1c46393e-ab63-47f3-b0c5-4e79cfb6696dn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3818 bytes --]
next prev parent reply other threads:[~2026-05-16 22:41 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
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 [this message]
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=1c46393e-ab63-47f3-b0c5-4e79cfb6696dn@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