From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 16 May 2026 14:50:57 -0700 Received: from mail-oi1-f190.google.com ([209.85.167.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wOMuN-0005IS-VM for bitcoindev@gnusha.org; Sat, 16 May 2026 14:50:56 -0700 Received: by mail-oi1-f190.google.com with SMTP id 5614622812f47-479e99d2aa5sf1612731b6e.2 for ; Sat, 16 May 2026 14:50:55 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1778968249; cv=pass; d=google.com; s=arc-20240605; b=TLn/5Pj+DzCPv6GsNINIcAYzdRkS3MH/oIR9c7ycxZ1zDUtO8rEOMjvEqUKe3/gbqZ yR8xF4Q6EpZlRlKE8iDSnceUzfGzjw5IZjt+hE6E8hv69uIrOMCWPnAvPsOdOMRZjmq4 mHRHlqH/Yb5OcgodX9UrN1WY4C7mSeAcP6+7a5Hb5mtwoCQ4f3EhkGkE3ZjTjUOxjBiN iWegtGPuFnDT55SchZmS0mOaLhlFp8iDFRuRRBtNQWqKp62mbe/vQ5neWtdGYvcnNz3h mYCpW4o9TAqotb+85zbM+uiiHezQmFLYp4Ae3hpY0fSyA2ol+ijRXu7sNqXXbDf8XxBF 31ZQ== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=G0/9c9gSiN4XRxsYGfKRyHDq04dFdoTxsO0IbAMqJlA=; fh=fy6bSWxyrLQqm7n/hrFRCxJpHmn1bEcV2+AcbHb+CRI=; b=NJ/IGUvlzwHAhmqbvf3bQ9ND3ivm4j3Y7DmJ3RWX9hNJ5BWFT9DxNZte22lAXI1fDg 8f7aq652tsnY90KzIcSKCs5quE1PIfvq54/dml01gP/tATIyHwturCm/rYA8HV7Yt5W/ dmGIfFJVhnTWrfvvmjHhAEX9fxQVCImmzHDBVaAmOTyufX/aUX7KMzImvYuQzBDvQ6+8 OdfQXXRNShdoLuenfmH/PCqkig+C330cRYbLxWimVPgWpm/p0dw/7rf7WisRz/iTpLfm 5knfVWsn2H8d1AihZQNDFekSNbI1h064bsdjkfVp1EBNuagvQYT/yzOeOiRNHO+7IaR/ iHrw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=exNxNOHK; arc=pass (i=1); spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1778968249; x=1779573049; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=G0/9c9gSiN4XRxsYGfKRyHDq04dFdoTxsO0IbAMqJlA=; b=QPgsGPwIFAFC0M3e6sM+rYLg60fzVkTKLw8+HuS/f03DK0X8NCG3837QE1gdRLoxo9 1AhFiw9RKh81vJuqFq34mvf39a0DVjOx4ERLhSbpRAB8L7tyihGRpIaqWVYER7fUNpN1 tnEQmHgk48hMpWJgyI+upYOmGULC1p9ZxUnuWp0g8PUept5kzFl0eNU9VXAAXfeNilps BdAXFxpiOjVFyUa84tKse5//ePO7RRGlYiw4MN9zUmyQxUQ/uUjQzrO+9XOaygsiLmyX Zexda7/JGQdK8oSiv++VnITIIytEgHzFWaxfKBpR+ZKpuxqjAX8m27OMItJ6+Wgf9VLU poQQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778968249; x=1779573049; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=G0/9c9gSiN4XRxsYGfKRyHDq04dFdoTxsO0IbAMqJlA=; b=rFnvRJCyz2/n/kObEIXWmV3DLm0cUmJipduYyjmAl40Faik7wzw2NgT8BrVYSq++SN 7/oHbVZAIYwVbbwS16Jh+IGlIlyhR58sM/ZdkfvfT+5i+YywFiVu9tFCvGRje955AXet i/GgxbZ6sz23OzwUQDS4xcLg+2A9j9DDYtqohnE5NxAXJsN1NVpS151Qm1Cqz7drUGyr raKSGgHQPG8a99LZi6dmKSJ57/r1Z7BByxfIuQObMSlVSd/yDOv/kncC1ZGB/ginv43U ADkGI2YCzYBM7JeGKDQQHdUeklrLbMJjJ7ee6gDUFVGWKaV04TTaEsYGmTCyyVOcLpOt uc4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778968249; x=1779573049; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=G0/9c9gSiN4XRxsYGfKRyHDq04dFdoTxsO0IbAMqJlA=; b=bkCjuhw03z6WmsQpBYnSyzfeik+PCb/AjZ6eiGriM47yp93KbetGcK18T0IELKUyZi y5+j2NxugmcyYP2049EasjXwO9dbD0/WPO73oOH6JuKkbGHBvpS9Vo4zgMx0OaV9croG hFwuIFckWbUWRJBUtHNHRT4/Nrz/pcVAg5gjJv6Kovokb4FRqJICuPn8WQ3gbNq3ZPb7 iOtSQFuC1TIHPG0gLfOxS6K7TMQGH2tpE9x8RxhaaBw1NdxfYwjyiia1yG2FfTQl7oMD bPGYBM6gRuete43XtqcHPotRoNClTnkWo0SrtuwJNT91sKhfPjf/S14SHJ/D9SzBI6wy ufAQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ+jnietVBGRAVm5+3s/WvqWrY3CBIl1eKOFHP20DplLEOnlUSQC07HWpPhWmcEyBLM1FRATBdXeOq26@gnusha.org X-Gm-Message-State: AOJu0YyOleAbK2fmWb/g+4rPJW+8aPC0d7aBJiDI5cEvSqXOJlbTFrLG abZ0TpxroOedhqXq1V29FVPCd83HH14SFq3EwfeLxj02W/l6ZmZYaZCo X-Received: by 2002:a05:6808:c1e9:b0:463:bef4:c9d5 with SMTP id 5614622812f47-482e55abfc0mr6833858b6e.6.1778968249278; Sat, 16 May 2026 14:50:49 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMO7+Pnfwki8E/i33LJqq39VxPaC1ZXHAAn5dnkMkK49+w==" Received: by 2002:a05:6870:2116:b0:416:1b5c:16df with SMTP id 586e51a60fabf-43a01ef5ebals2341771fac.2.-pod-prod-08-us; Sat, 16 May 2026 14:50:45 -0700 (PDT) X-Received: by 2002:a05:6808:67c1:b0:46a:c987:ba00 with SMTP id 5614622812f47-482e5760189mr6515284b6e.32.1778968244961; Sat, 16 May 2026 14:50:44 -0700 (PDT) Received: by 2002:ab3:7109:0:b0:301:73d0:a528 with SMTP id a1c4a302cd1d6-30173ef51cemsc7a; Sat, 16 May 2026 10:58:40 -0700 (PDT) X-Received: by 2002:a05:651c:b10:b0:394:3b62:b6aa with SMTP id 38308e7fff4ca-39561c5ec5cmr31239751fa.12.1778954318657; Sat, 16 May 2026 10:58:38 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1778954318; cv=pass; d=google.com; s=arc-20240605; b=L0czI68J/4J1381sWqhE5gUJw7s9teBunsG9EUZGxJt/V2QkcVcdHxwp3XoFutnV1i rnXouR3MpMi1hbXApH889i2iHDrePtk9jkGQrfjLGP07qB9gDnVABg276kFTSPKR7KsW Js27Y4X7yJufwX8evcpnZhwQ5omrVmE6AlXSgpVGfS9gEVwIKebK4NDoFD2XJmdvpasv 2JH/ZzhqFEFh5hro56jP6AEUS4Ia1NZuFFiGQ2HEnMJcpASxua9FZzimvDAxRQV7Mn7Q MCo6K6BetHZhG4T3AKdzUMUC817dWRKUya5LPnSh/69sGeo32aAIjliVMW/qZNB51+CA yVJQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=8gEGcy9IduJUxcvQG4mPqUiecxYi/GvDPv1K1icRECs=; fh=Q807foRYPGaZK4FeW0jFqivz1zCKMpHJbF4ZNW3naxc=; b=UunZdihYyozxeEE688SVxxPawzwz1AjeCe3lN+6x+rsOrpc7iDLSmRg41p92JByuLr 9753GAso1fdP6IdvBFPALI9kjM+PyGvkFHeeXsLPYpO9g2uOj5v9ZG+QCPAwAbCh5EzI eaEI5RoNfq++0omgTFFllwiHL+ROXgoHUIdl+iAfA/p6lLJenWTQzcWpYtNiEjJ5mC3L 6kSA9qTiGxgvhPRG07gx+5PzoD23pzsO/drpFB2c70FRZuKPfQJkGj1ap+WW7axueKu3 IaR12IduEqDjrG4jMMQzyCOCbwVALM46JVVat1er1pTQlwTI+gw1xuTsjanY+uEkcVa6 +a3g==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=exNxNOHK; arc=pass (i=1); spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com. [2a00:1450:4864:20::12f]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-3945ca677casi1607931fa.8.2026.05.16.10.58.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 May 2026 10:58:38 -0700 (PDT) Received-SPF: pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) client-ip=2a00:1450:4864:20::12f; Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-5a88de2b52eso1318372e87.2 for ; Sat, 16 May 2026 10:58:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778954318; cv=none; d=google.com; s=arc-20240605; b=EOmfpfNPrqWb8XHYOgYjD5hWqVPXNBtRQcNgcbc5OAQUZtMMTrfdZAOKJree0iw6IR S7iGIRPlVXDLAjA7rt+XKBcjUzrYtbOZvg2RHzF9V44u9XpBzqirm4LFex83NBLRMhIp muqzrOEdZpKGXc77cqSxLdWl2lHGizVCtWFrJRY3CPVx+COwVZt6YVkWdYzX4/KgWYxB 63NzBiJ1XSGExuKVmKINpeWiUfZR69JWH0HItBDbE8LUw1iWwwOrjiXGxvyvcCN/ipoF LUWcvn1f8anwMukdFNmbE+S8WD0SO3pJmOjbwkv2ge9ANTFX1HpppIub9XQngyf3CnpI xSyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=8gEGcy9IduJUxcvQG4mPqUiecxYi/GvDPv1K1icRECs=; fh=Q807foRYPGaZK4FeW0jFqivz1zCKMpHJbF4ZNW3naxc=; b=jFaNB8PloNOslqx6K5ft4mXdZI0qZuP7FuMalfWAQsT03f0AvqU1GIY1M7W8STQZS8 dYlvuC7Sj8cjXf6LJKlUUWZL3zHScBo86KEhgpdd3uZ28dymtH8acF3vs9xqV5GH1Pe9 DI7HOqISJtbM7/hJWyLVv1adD9IMA2r4VKmxWEbaNK7/AVm7Au32eOi1Vk8LQX8jr6bU nFh4ax1jPMYMFoLWdQZ6bYp6D+N3eKBNpXXAKO8sMQWdupMzghTrF9ocORG5jZhG6WAT XWNZ4GnsKP7I1yajtwdKSoZZPi00GZx7FxSFvPod7BPnDyxLhr6jZOfO7V2JTnI2SrrR YGDA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: Acq92OHwnlI9d4Wi5wZx3OvLCwpMCz6YwtchaM4ZXyS8nczTD6Z08SKN/wfAqPaCa7P nUwKjodyibwBBLCx4LQFyPsgLxkAEKDjl0FaU0w99jNMgd6tfTaBYUShsISDfYiK4NmSbHnwbFb 9yC75VRTVJLXjqspsfRo1TMFD2t/GZznt/ISDe2lSu8TwPk0fvIH4WOAKoQoh8E+ruo6dAB9zKO 8FEUi1FOuGI6hhNMtXgPgOtXFToBEq3DHNp1Oetc9oh1pYfDZZZPjjWX4zlfzbl1WqVbC4V19mk tU03vFZPXkctQj9q+0fC0NMbUhAaSSBdt2/daFE= X-Received: by 2002:a05:6512:318c:b0:5a8:8b19:3506 with SMTP id 2adb3069b0e04-5aa0e6140e2mr2900050e87.18.1778954317734; Sat, 16 May 2026 10:58:37 -0700 (PDT) MIME-Version: 1.0 References: <19616822-8a03-4de1-99be-72d50479208fn@googlegroups.com> <02c201dce227$e808e050$b81aa0f0$@voskuil.org> <002301dce4cf$27bc3040$773490c0$@voskuil.org> In-Reply-To: <002301dce4cf$27bc3040$773490c0$@voskuil.org> From: Saint Wenhao Date: Sat, 16 May 2026 19:58:24 +0200 X-Gm-Features: AVHnY4IhD755Zi7Kd5vWqL9WwFc-T1wHOB2tMRaAjtghFKZxQKq-j5HZDMyR1Rk Message-ID: Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing To: eric@voskuil.org Cc: Bitcoin Development Mailing List , Fabian , Anthony Towns Content-Type: multipart/alternative; boundary="0000000000002e258c0651f3149c" X-Original-Sender: saintwenhao@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=exNxNOHK; arc=pass (i=1); spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com 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.5 (/) --0000000000002e258c0651f3149c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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=3D5480200 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 napisa=C5=82(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 stor= e > 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 i= t. > 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 transitio= ns > 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 b= it > > 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 tim= e. > > 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 =C3=97 8,000 =3D 640,000 Mb > 640,000 =C3=B7 39 =E2=89=88 16,410 seconds > 16,410 =C3=B7 3,600 =E2=89=88 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 =C3=97 8,000 =3D 2,748,000 Mb > 2,748,000 =C3=B7 100 =3D 27,480 seconds > 27,480 =C3=B7 3,600 =E2=89=88 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 =C3=97 8,000 =3D 5,913,600 Mb > 5,913,600 =C3=B7 308 =3D 19,200 seconds > 19,200 =C3=B7 3,600 =3D 5.333=E2=80=A6 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 utx= o > > snapshot at block 935000 being under 9GB. At 100Mbps with perfectly wel= l- > > behaved peers, that's about 15m to download. Adding in another 8GB-34GB > > of actual block data to download (assuming that the utxo snapshot peopl= e > use > > will be between 4 and 17 weeks out of date) brings that up to 30 minute= s > 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 o= n > 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 th= at > 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. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/002301dce4cf%2427bc3040%2477= 3490c0%24%40voskuil.org > . > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CACgYNOJVvO9BgMHspYKyKtcOZZpXqERbwgxnLi%3DecTXO8HuM4Q%40mail.gmail.com. --0000000000002e258c0651f3149c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> 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 o= thers. You can read some examples on forums, where people run full nodes, a= nd post their progress on a regular basis: https://bitcointalk.org/index.php?topic=3D548= 0200

Currently, I started Initial Blockchain Download on some no= de. 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 Int= ernet speed may be better than that, then still: it is limited by what my p= eers can provide. And if I check 10 connected nodes, and all use NETWORK_LI= MITED flag, so all are in pruned mode, and all just act as proxies, fetchin= g blocks from other full, archival nodes, then guess what: it is limited to= the weakest link, the slowest node in the chain of connections.

Whe= n I did the same experiment some months ago, but this time from some VPS, r= unning 24/7, my results were quite similar. Waiting around a week to be ful= ly synced is normal for me, and I got used to that.

Also, I understa= nd, why full, archival nodes, use rate limits: because otherwise, they woul= d pay more bandwidth fees, if everyone would be able to get everything inst= antly, 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 incentiv= e to provide more, than the bare minimum they can handle.

sob., 16 maj 2026 o 03:01 <eric@= voskuil.org> napisa=C5=82(a):
> From: Anthony Towns

> On Tue, May 12, 2026 at 11:56:33AM -0400, eric@voskuil.org wrote:
> > > AssumeUTXO=C2=A0 is a UX improvement for those interested in= running a
> > > fully validating node. The option to get started in a very l= imited
> > > 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 scenar= io, and not worthy of protocol support.

If you have not fully validated every block in history, you have not valida= ted at all. The validity of a block requires the validity of all prior bloc= ks.

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 certain= ly 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 trustin= g 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. Accepti= ng this as a matter of protocol is irresponsible.

If you want a reduced (vs. zero) level of security while downloading and va= lidating the chain, I suggest implementing an SPV wallet that transitions t= o a full node wallet after downloading and validating the full chain.

> Obtaining the full Bitcoin blockchain currently requires downloading a= bout
> 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 bottle= neck,
> with modern PCs being able to validate the blockchain in about that ti= me.

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 =C3=97 8,000 =3D 640,000 Mb
640,000 =C3=B7 39 =E2=89=88 16,410 seconds
16,410 =C3=B7 3,600 =E2=89=88 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 =C3=97 8,000 =3D 2,748,000 Mb
2,748,000 =C3=B7 100 =3D 27,480 seconds
27,480 =C3=B7 3,600 =E2=89=88 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 =C3=97 8,000 =3D 5,913,600 Mb
5,913,600 =C3=B7 308 =3D 19,200 seconds
19,200 =C3=B7 3,600 =3D 5.333=E2=80=A6 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 (m= edian block ~1MB in 2016), coupled with segwit 4MB limit impact.

> AssumeUTXO significantly reduces the download requirement, with the ut= xo
> snapshot at block 935000 being under 9GB. At 100Mbps with perfectly we= ll-
> behaved peers, that's about 15m to download. Adding in another 8GB= -34GB
> of actual block data to download (assuming that the utxo snapshot peop= le use
> will be between 4 and 17 weeks out of date) brings that up to 30 minut= es 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 exceedin= g Moore's Law. This perception has fed the spam debacle. This perceptio= n is rooted in the reality that sequential indexation (even without validat= ion) 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 expone= ntial. Even Satoshi reasoned this out. What he didn't do in his prototy= pe was provide a scalable implementation - he left that to us. Necessary do= wnload and validation time/cost is shrinking. Eventually downloading and va= lidating 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 und= er 5 hours. That's less time than it took almost 10 years ago on the sa= me machine - and my real Internet cost today is about half what it was at t= hat time.

So I reiterate my NACK. This is a very unwise idea, without justification f= or network protocol integration.

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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0023= 01dce4cf%2427bc3040%24773490c0%24%40voskuil.org.

--
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/bitcoindev/CACgYNOJVvO9BgMHspYKyKtcOZZpXqERbwgxnLi%3DecTXO8HuM4Q%40ma= il.gmail.com.
--0000000000002e258c0651f3149c--