From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 16 May 2026 15:41:11 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wONh1-0006Xb-4X for bitcoindev@gnusha.org; Sat, 16 May 2026 15:41:11 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-43a356e0119sf4960289fac.0 for ; Sat, 16 May 2026 15:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1778971265; x=1779576065; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=eVDGEf7Cg73cgzfoFdFtQZo1L+RPJwq5ZP5H3pGOKt8=; b=eBr5D1YAikMtNp+w4WVngx0LoIsJVrqWyLOagqaXJhn9QIsBA6//BW75l1wjqNJ9gh gLwFY7QhpeOHXjbfx0VhDkbUPl122KT8AsHreCikv1MiqlAjAA7u1Qy9xS9n9xL4/yN1 AZf8dnbwgRZGC7moaXy+AlKqTdds/dF999DtDR+a7utijI6Q8tGNgJDJ6NhNpRlt3Xo3 g20RuZJGXH545sCdNGuYk88sFY3fa/+RWZxPPa/R1NUFA38PH2gF6Zl9WZNCKgzymSb7 gvB/ZBnU9s+kVIj6lQNz1yReaoQnJugEVwRxLiDvUMLsivRulvPHQ33cEdZrm44mdSD5 2fow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil.org; s=google; t=1778971265; x=1779576065; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=eVDGEf7Cg73cgzfoFdFtQZo1L+RPJwq5ZP5H3pGOKt8=; b=YReWNcmpePS7AHZAQtRW/A2N4exev5fJRDTKhLOGz2nSjaR7EgFZJBulCN54FguOmD D05FQIdufKT8U7Ng9EyYElETnlyhxgnPGlX63RAKdPOxYa2h5hJ3A8E4x+tYIUa4U2nB dRUvpz0e+oHCkLv0lsMgfLygpk++KEKaCVafLRhFNKFWHeU6Xd4QLyrGOpU+c6+obc3o RstVlZ2WwwPYMp4qu1khOdECdQef8zsUktyWMa/A6FQl1c8uKWMDecT36BCQtKUyYJ8b NBXIcNpaZm3uHgZT/PLj1DbMQTl7XbpT7I1Ao9tM4xcuAcZScMReea9NpEhTaKSlKDNm NBYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778971265; x=1779576065; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=eVDGEf7Cg73cgzfoFdFtQZo1L+RPJwq5ZP5H3pGOKt8=; b=FAVylBLvOsU0dDe9ggYPN4CETK6fRGX9DAUZNqQx1aW3AzwtmVfkd9Xt3I6GlAdSdH YUFSka6FtwAE4K3oBQKnyBG/E40m4QBlZBbIo2pUXwGBiCohfw5tcOcZmi7OhFahnmZe xi6YFc5UuAShIVQobKu8QCb4MCRvlzSRrpvsQ/L22ACBHMXG1wjfRfnE/nUTb5zrCOqC DRdLH/u0iMBz8wDKk8kPQLx7mfOQTFPE/AKNhdKSSEjVeWbu5HBhx9ea2p8DYXhhX0QW oFanUcQLmN7BpVaJhVYn7AnFw8yS9yNTKDYYJ6egLAcrNSWMXs5yxoQ6WNgsUJoP+akx CL7g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/teiNmtS9o9voRz2sBsVtTYyBJBbJ4z7S2dvxanrvuxBiNIkkOLm3RewgHs6iTp6JfxmON+pObrw7K@gnusha.org X-Gm-Message-State: AOJu0YzepKiYbrF50Mr9Cg13csLFH8Fx9ThjWdd4k12MWXncqV/i5n2q GpXfFfYs11buW+Ys44cnTEF65LcCAN6CqmGEXBvufvOWfP1lCFgj6yxX X-Received: by 2002:a05:6870:3044:b0:439:bf59:554a with SMTP id 586e51a60fabf-439f94c5e1amr6964748fac.13.1778971264568; Sat, 16 May 2026 15:41:04 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMMjDUFoMAPy1eHkgkQlo4ljyRX7WfXAM3gsWepeec+KIw==" Received: by 2002:a05:6871:e40f:b0:42f:bd47:9133 with SMTP id 586e51a60fabf-43a01176df0ls1907951fac.0.-pod-prod-09-us; Sat, 16 May 2026 15:40:59 -0700 (PDT) X-Received: by 2002:a05:6808:4f21:b0:479:faac:1fbf with SMTP id 5614622812f47-482e562d53cmr6074435b6e.2.1778971259531; Sat, 16 May 2026 15:40:59 -0700 (PDT) Received: by 2002:a05:690c:e299:10b0:7ba:f5aa:4ab8 with SMTP id 00721157ae682-7c693ee851dms7b3; Sat, 16 May 2026 15:39:46 -0700 (PDT) X-Received: by 2002:a05:690c:e566:b0:79a:dae4:5832 with SMTP id 00721157ae682-7c95a66b912mr94923317b3.22.1778971185615; Sat, 16 May 2026 15:39:45 -0700 (PDT) Date: Sat, 16 May 2026 15:39:45 -0700 (PDT) From: Eric Voskuil To: Bitcoin Development Mailing List Message-Id: <1c46393e-ab63-47f3-b0c5-4e79cfb6696dn@googlegroups.com> In-Reply-To: References: <19616822-8a03-4de1-99be-72d50479208fn@googlegroups.com> <02c201dce227$e808e050$b81aa0f0$@voskuil.org> <002301dce4cf$27bc3040$773490c0$@voskuil.org> Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_682098_139686698.1778971185053" X-Original-Sender: eric@voskuil.org Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) ------=_Part_682098_139686698.1778971185053 Content-Type: multipart/alternative; boundary="----=_Part_682099_1893051975.1778971185053" ------=_Part_682099_1893051975.1778971185053 Content-Type: text/plain; charset="UTF-8" > 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. ------=_Part_682099_1893051975.1778971185053 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > From: Saint Wenhao

> Even if my Internet speed may be> better than that, then still: it is limited by what my peers can pr= ovide.

This is a reasonable assumption, but it is not correct. P= 2P 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 stand= ard deviation to detect which peers are slow. This will rapidly saturate yo= ur 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 w= ork this way. That's an implementation issue.

> And if I chec= k 10 connected nodes, and all use NETWORK_LIMITED flag, so all
> are in=C2=A0=C2=A0=C2=A0pruned mode, and all just act as proxies, fetching = blocks from other full,
> archival nodes, then guess what: it is li= mited to the weakest link, the slowest
> node in the chain of conne= ctions.

This isn't how the protocol works. Addresses are adverti= sed with their service bits. A node attempting to download blocks should no= t 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 no= de 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: bec= ause
> otherwise, they would pay more bandwidth fees, if everyone w= ould be able to
> get everything instantly, at full speed. Which is= why when many people limit
> their connections, to not share too m= uch data too fast, it is what it is. And it is
> normal, because no= des are not rewarded for their services, so they have no
> incentiv= e to provide more, than the bare minimum they can handle.

Thrott= ling is not a problem for the same reasons discussed above. Download time i= s local bandwidth limited, not peer limited. If you are downloading at a ra= te 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 fiv= e and ten year periods to show the strongly declining relative trend despit= e strongly increasing data. There is no need anecdoting about bandwidth. It= 's easily obtained public information and a straightforward process to dete= rmine download time from these numbers.

https://en.wikipedia.org= /wiki/List_of_countries_by_Internet_connection_speeds

> It sh= ows around 1 MB/s in the "Network Traffic" tab from the GUI client.
<= br />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. See= ms 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/1c46393e-ab63-47f3-b0c5-4e79cfb6696dn%40googlegroups.com.
------=_Part_682099_1893051975.1778971185053-- ------=_Part_682098_139686698.1778971185053--