From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 16 May 2026 14:50:46 -0700 Received: from mail-oo1-f64.google.com ([209.85.161.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wOMuC-0005I6-VX for bitcoindev@gnusha.org; Sat, 16 May 2026 14:50:46 -0700 Received: by mail-oo1-f64.google.com with SMTP id 006d021491bc7-69649771a5asf1768830eaf.2 for ; Sat, 16 May 2026 14:50:44 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1778968238; cv=pass; d=google.com; s=arc-20240605; b=Qtl9iwj3A4g0xmBSiY19rZs0Cx7ddkM5ywYk89khwdlNgAQmbp+OdelorpoPzhmG+e VpSrPOJ64Y2Yple9EqZC1cxGYyNUWKgBU5f2MbwxVxi2/SO5LwNSDCSEcIizes8yRPy7 KEAzE+CjtopBfcuTE7tCgADRKsf4uxKu8E/mzXQgvuk15SusM2fyk3bLsI4WnBX4UvkU myqIZlLZg5XDeX1RfXNfRvj7qRU+Fp5X1dTrJznyk+6bvkqNtCAbsJ1U6a1xxZJVQcW3 Nw7Doxso6Ag6wG6HBfKvmHUqOOTgr/IJLMsubDcvYD101wfHCpYZD2yyI725KRbIJYEK P0Sg== ARC-Message-Signature: i=2; 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=DRi9kKiMnJD/TUbovY2WzXyAm21R7Ji7N5ixAv4wEhA=; fh=oM8Ty3uSbRJgZtwYgx3PMNJ3TBrGCemnQ4RvU9BhWEw=; b=egg6gfjOvX2r36jJcFC5lz3RZCYVCdQTMGFUJVc6xC1Ql+cM1sOVg2tsf1qydhN3MO 9mH5zCdzs5iIUxJtJ1ib9xdmMFOA/JehK1fgcny5VCcGzPg71of/N0OUyt+KD71riE6e rW6FwYCjYkITCQf1oV40M4Xcs+tY3H35nWIP6s/vfga1usyR+mUaQ1PDyqFOUOWZcRIq 9g0XatUXwBVP2MBqKeqmnDI6Yg1c0dO8i8WkzOv2Tzsu6NxH5otb/z/7u5Gs+ypYOMCc f3lUN16s1WOUHuXxL7yc27j9HLNrbHm/YavtLE9G4VLDGz8HShPECeMkICw2OE+JZw1q +DhA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=lUtC1MDd; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1778968238; x=1779573038; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=DRi9kKiMnJD/TUbovY2WzXyAm21R7Ji7N5ixAv4wEhA=; b=Zf9ZLLveyVy9jP07iYge1SdS8lWgz/9OdJLruw/d4BoQRMTW4AHOUNok/WsGWpuvOz M91jOIGzBmyUx/jgVahvrJuDYyW36XhwQ6txWDG9WU3XtLx0nC07KWZhN/4gVfRX7NdD QYURNxC526bD3YQqXaD9COS1/hfjKFYYZuyMWQ882KhxkAOMF4pkoBvJWH4JcgY/nD/2 hmSuEgyIXn8Y4hYOLtljUjkzV6ceKZYU3C3iJMIO3hxvXKVa9EHK4Qj6i3kvxYMeJJ+E 7alwAkEbJdSs3sHGY5vWaCfoPeXkG0ydp2wXtgjjr4VEgUjNeXxX3gIfmdlRfx27oC6y 5GMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778968238; x=1779573038; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DRi9kKiMnJD/TUbovY2WzXyAm21R7Ji7N5ixAv4wEhA=; b=nzJCsA79soi50ZzJJoWRqfdFQRQ129ZKfVvyA9YbHp+g1/+U2byUvGn5ntsA1HTnKG 0egh5J3TvL0gms3ISueVzvW2gapx0Y5Ap5djV2FXtDZAoJDcSWRd9S8fVgnaAiaeIwWf 1Zvn7cBApHQBuk8zQznS3972NZp0XeGoSrsRxAnyZcQZOc+UdvKbQZD9VwdAElAlPxOr QiEiA1puumrGzBMGQFkdDnbssJpPlRt4aSMRMmAutMgtp5mOYk5Xwsg/ZKOat9pmAEdp wUUG3zgoXCf56R3rXPOu5m5JKZWiTkL+mKoTPEkbSb4/HhgrdiY3sxJaxkfizfcQ65vs qOMA== X-Forwarded-Encrypted: i=2; AFNElJ9N19zthXlNmyoquFOWqUQDFpMB496dCppbzRxLwx3n9sqCP7vnnT73iBlbLyoeASUWhNPj6OPrd3rZ@gnusha.org X-Gm-Message-State: AOJu0YzL2D5fagufWbPYEkzfAzoxwJWmx5aiRi/U+Ww9IB60Yw2OKZA9 62FXhVDCT6UPQ+rDpSYgUIYHp3mKKw6DfXA3Qa1/DL4+skvwxYW58heq X-Received: by 2002:a05:6820:20e:b0:696:8e8b:2097 with SMTP id 006d021491bc7-69c942ee111mr6890533eaf.21.1778968237726; Sat, 16 May 2026 14:50:37 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOs3xHA3TdkLz2uVO7bIQkc7NDgELF89q8x8K3b+XpcZQ==" Received: by 2002:a05:6870:a083:b0:422:c0f1:a9e4 with SMTP id 586e51a60fabf-43a0119a7cdls2144641fac.0.-pod-prod-08-us; Sat, 16 May 2026 14:50:33 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8not4N9jsQK9hbA6IihUoGg7cmTYzKUouarVlVhso8LGxxYOoPkEFSg8s3zx2/gQT87gwMZ2PamfiM@googlegroups.com X-Received: by 2002:a05:6808:6f87:b0:479:d7ea:ae34 with SMTP id 5614622812f47-482e572bb20mr6204432b6e.24.1778968233212; Sat, 16 May 2026 14:50:33 -0700 (PDT) Received: by 2002:a05:600c:1688:b0:488:965a:b7a8 with SMTP id 5b1f17b1804b1-48fc95da45ams5e9; Sat, 16 May 2026 14:48:49 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+9r29kUwuezShAkwPG3kzPtTnhsZiIIXj+afOf6K64o3HztIBH2SpFZgxBrMmGteR5k47Nh09CzEQs@googlegroups.com X-Received: by 2002:a05:600c:a309:b0:48e:8741:fd53 with SMTP id 5b1f17b1804b1-48fe61f1e37mr103129145e9.15.1778968127921; Sat, 16 May 2026 14:48:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778968127; cv=none; d=google.com; s=arc-20240605; b=R+4YJUgc+qW9yZRvZTo1DGTHMge3yNyvcHNuiSwjP/kPclnsRxYSIRf6ojsKOrcYei en1dVSPu9A4aBYDV5ZyxjbzV+sX51ReC4aJtAQbqbp9X3Oeg+yotuqvdzmQ6ivRpvgXy U9E7Vz9iw4nx0fJp++M7yhxk3bPNbEXScts7YKrVVd1xzIdT4d3adjN3H4R3zQMQZ94m 2EXlWj7nefaWlYDyFchGflcEKqorvuCY373707YnpX7RIeixmf3xfOtEAM6wwT12eNNp 4tTA30JtAW8FC49qHb72X3mmyIskyQhSMWvOkhWwnjcYnq6XwXaFxsG33+TmNemysqqd 56Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=QQNPGOWdkMBZ+kcjeDOPHO5PX1y49/E15TeiH94jiqc=; fh=oix5SEmgyfSF++/+xHQLrmqUot8tWr/YeddMIAiQalU=; b=E/rfSBqtG8Oz/Wc0CZh0lEg77nqkn/jDqV8TeiRXULkdF+UN2547go4BgPfIGEvGaa 6Qc+Xm80whXf+qAPav9vOyRaTgxbKMO3g5XDJIbBIaAn61bcwZHwjhV2cv/lakSmIG18 HilTSnsDzttP/LRAyMZISUr6fPhlZdl3i9JVhQTP4QryFqYPaMpwSvWIIMkSqZC2Mzf3 D4HTUuY1hpxKb7ZeIcBR1Cgfg3is8c7QyWsT8ArK/BFNCuy/8i1XE8oenaA+uFL9vl4/ q7E2ONtY0SZJ5En2waC9f1uqyNas1U1V3gbwkwVI+Mpt0M0pCylpUoa7DoIteIeNXvNG bq9A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=lUtC1MDd; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-45da0c0564esi207354f8f.6.2026.05.16.14.48.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 May 2026 14:48:47 -0700 (PDT) Received-SPF: pass (google.com: domain of fjahr@protonmail.com designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22; Date: Sat, 16 May 2026 21:48:41 +0000 To: Saint Wenhao From: "'Fabian' via Bitcoin Development Mailing List" Cc: eric@voskuil.org, Bitcoin Development Mailing List , Anthony Towns Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing Message-ID: In-Reply-To: References: <19616822-8a03-4de1-99be-72d50479208fn@googlegroups.com> <02c201dce227$e808e050$b81aa0f0$@voskuil.org> <002301dce4cf$27bc3040$773490c0$@voskuil.org> Feedback-ID: 5067558:user:proton X-Pm-Message-ID: cc7289f8c58e6d2208fa7d27f8e2661427181f11 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_Rd8a6fPvmB7dPCx7XCToFnZ4e17aZl380TTQWpMtmU" X-Original-Sender: fjahr@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=lUtC1MDd; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Fabian Reply-To: Fabian 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: -1.0 (-) --b1=_Rd8a6fPvmB7dPCx7XCToFnZ4e17aZl380TTQWpMtmU Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eric, Sorry for the late reply. I'm responding to bits of both your last emails s= ince they made closely related points. > It's not at all clear to me how this is a UX improvement. Get started doi= ng what? Aside from the most obvious case that was already named, receiving payments= for goods and services, I would name mining without a centralized template prov= ider as an equally important use case. > Receiving payments without having validated is an exceedingly unwise scen= ario, > and not worthy of protocol support. For most merchants this scenario is much preferred to not receiving payment= s at all for an extended period of time if they don't have great hardware and ba= ndwidth at their store or home. I also need to add that an AssumeUTXO node is not "not validated". The header chain is fully validated before the snapshot is loaded, and the historical blocks are validated in the background. The work= is the same, only the node becomes usable earlier. That IBD sync time has been a real deterrent for users choosing a fully validating node for their PoS setup is demonstrated by the fact that BTCPay= Server shipped their own AssumeUTXO equivalent before AssumeUTXO existed: https://= docs.btcpayserver.org/Docker/fastsync/ They also did so with a worse trust model than what is proposed here, a tar= ball from a single trusted source. > 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 certainl= y also > implement SPV and use it while downloading/validating, though that elimin= ates > the use case for trusted utxo state. No such software exists, and I think the reason is that most users would no= t bother validating anymore once they have turned to SPV. With AssumeUTXO the situation is different: there is no option to skip background validation of= the chain. There will always an alternative solution available for those who don't wan= t to or can't wait for IBD to finish, and it will always be a worse one than wha= t is being proposed here. Why should users bother with SPV then? We will continu= e to lose users to custodial solutions if we are not willing to offer alterna= tives with a UX that at least comes somewhat close to what today's consumers are used to. Being able to transact with IBD running in the background also takes away t= he economic and other pressure off of those who need to get a node started qui= ckly. > But of course this presents another problem, that of the cost of validati= ng > them, requiring full validation of the chain. So this inevitably leads to= miner > commitments. AssumeUTXO is anchored to a hash that is hardcoded in Bitcoin Core and revi= ewed in the open. Anyone running a fully validating node can independently repro= duce it from their own UTXO set. That has no relationship to miner behaviour or PoW-based commitments, and Strateman's concern with about a >50% attacker creating new bitcoin, does not apply to it. If anything, providing a workin= g P2P path for snapshot distribution reduces the pressure for any future commitme= nt scheme rather than enabling one, because the user-facing problem that motiv= ates commitments is already addressed. > Even if for some reason you cannot comment, I and others can. I did comment, I just pointed out that I cannot disprove something that doe= sn't exist. I have not been part of any such conversations and I have not heard = of anyone being part of them. > It is not hypothetical, and it is dangerous. This understanding is at lea= st > 11 years old: Old mailing list conversations are useful context but they don't prove anyt= hing. The author of the original Bitcoin Prototype software also wrote, "I don't believe a second, compatible implementation of Bitcoin will ever be a good = idea" (https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/69/#2), an= d that does not seem to have stopped you from working on libbitcoin. The Stra= teman quote is a sound warning about a specific scheme, but it is not a scheme th= is BIP proposes. > These aren't limitations inherent in protocol. The implementation details= of a given > node aren't relevant. The protocol's job here is to enable obtaining UTXO state from peers rather= than from a third-party website. What each implementation does with that capability i= s, indeed, implementation. While AssumeUTXO is the primary motivation right now, there= may be other interesting use cases for this down the road. > Median U.S. broadband speed > Despite a 4x max block size increase in 2016, download time is decreasing= . Those figures use US-median broadband. Globally the picture is significantl= y different, and a meaningful fraction of users rely on mobile or metered connections where the difference between "over lunch" and "multiple days" decides whether they run a node at all. The same applies to the 32 GB RAM minimum noted for libbitcoin (https://nitter.net/evoskuil/status/2054456087= 252816267), which already excludes a large share of consumer hardware outside high-inco= me regions. I think disregarding hardware and network requirements of users in less dev= eloped countries is causing much higher centralization pressures today than this U= TXO set sharing proposal ever could. Following the trajectory of the last few y= ears to its conclusion, the minimum is likely to be 64 GB next year, then 128 GB= the year after, and validating with libbitcoin will soon require the latest gen= eration of Nvidia chips. Validation time will keep going down on that path, but the user base it serves will keep shrinking. I am obviously exaggerating somewhat to make a point: it is easy to constru= ct a plausible-sounding slippery slope argument, including one about libbitcoin'= s hardware trajectory. And I don't think you are able to prove today that lib= bitcoin will not follow this path in the future. That is exactly why I don't find your similar argument persuasive. And in all seriousness, I think at least some Bitcoin implementations shoul= d aim to be accessible with low bandwidth and minimum hardware requirements compatib= le with widely available consumer hardware outside high-income regions. That i= s what many of the developers I work with are aiming for. Best, Fabian On Saturday, May 16th, 2026 at 7:58 PM, Saint Wenhao wrote: >> 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 the= ir progress on a regular basis: https://bitcointalk.org/index.php?topic=3D5= 480200 > > 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 "Netwo= rk Traffic" tab from the GUI client. Even if my Internet speed may be bette= r 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 i= n 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 s= lowest node in the chain of connections. > > When I did the same experiment some months ago, but this time from some V= PS, running 24/7, my results were quite similar. Waiting around a week to b= e fully synced is normal for me, and I got used to that. > > Also, I understand, why full, archival nodes, use rate limits: because ot= herwise, they would pay more bandwidth fees, if everyone would be able to g= et 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 the= y 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 sce= nario, and not worthy of protocol support. >> >> If you have not fully validated every block in history, you have not val= idated at all. The validity of a block requires the validity of all prior b= locks. >> >> There seems to be a common misapprehension that using a trusted utxo sto= re is something akin to SPV. This is not the case. A node/wallet could cert= ainly also implement SPV and use it while downloading/validating, though th= at eliminates the use case for trusted utxo state. >> >> Using a trusted utxo store for transacting is equivalent to a fully trus= ting wallet. The person is 100% trusting that the state of their node is va= lid - having not validated any of it until having validated all of it. Acce= pting 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 transition= s to a full node wallet after downloading and validating the full chain. >> >>> Obtaining the full Bitcoin blockchain currently requires downloading ab= out >>> 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 bottlen= eck, >>> 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 *decreasi= ng*. >> >> 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 requirem= ent/time. >> >> What has been increasing is the perception of increased block data excee= ding Moore's Law. This perception has fed the spam debacle. This perception= is rooted in the reality that sequential indexation (even without validati= on) does not (cannot) fully take advantage of advancing hardware. This is a= n implementation issue. >> >> Chain growth is linearly bounded. Hardware growth at a given cost is exp= onential. Even Satoshi reasoned this out. What he didn't do in his prototyp= e was provide a scalable implementation - he left that to us. Necessary dow= nload and validation time/cost is shrinking. Eventually downloading and val= idating the chain will be as cheap as texting a video clip has become. It w= asn'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 unde= r 5 hours. That's less time than it took almost 10 years ago on the same ma= chine - and my real Internet cost today is about half what it was at that t= ime. >> >> So I reiterate my NACK. This is a very unwise idea, without justificatio= n for network protocol integration. >> >> Best, >> Eric >> >> -- >> You received this message because you are subscribed to the Google Group= s "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n email to [bitcoindev+unsubscribe@googlegroups.com](mailto:bitcoindev%2Bun= subscribe@googlegroups.com). >> To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/002301dce4cf%2427bc3040%24773490c0%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/= RiAeHX6Gt48YabQbYIIOFyMF63Pziq12Czi1gSAHlXZ3dBWHIs6l5P-egzOYpyShLUQKVcIeb1p= W358WsHR5pALr6T5xAHoN6Igg9Hg0NS0%3D%40protonmail.com. --b1=_Rd8a6fPvmB7dPCx7XCToFnZ4e17aZl380TTQWpMtmU Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

Sorry for the late reply. I'm res= ponding to bits of both your last emails since
they = made closely related points.

> It'= s not at all clear to me how this is a UX improvement. Get started doing wh= at?

Aside from the most obvious case = that was already named, receiving payments for
goods= and services, I would name mining without a centralized template provider<= /span>
as an equally important use case.
<= br>
> Receiving payments without having validated is an = exceedingly unwise scenario,
> and not worthy of = protocol support.

For most merchants = this scenario is much preferred to not receiving payments at
all for an extended period of time if they don't have great hardwa= re and bandwidth
at their store or home. I also need= to add that an AssumeUTXO node is not
"not validate= d". The header chain is fully validated before the snapshot is
=
loaded, and the historical blocks are validated in the backgroun= d. The work is
the same, only the node becomes usabl= e earlier.

That IBD sync time has bee= n a real deterrent for users choosing a fully
valida= ting node for their PoS setup is demonstrated by the fact that BTCPayServer=
shipped their own AssumeUTXO equivalent before Assu= meUTXO existed: https://docs.btcpays= erver.org/Docker/fastsync/
They also did so with= a worse trust model than what is proposed here, a tarball from
a single trusted source.

= > There seems to be a common misapprehension that using a trusted utxo s= tore is
> something akin to SPV. This is not the = case. A node/wallet could certainly also
> implem= ent SPV and use it while downloading/validating, though that eliminates
> the use case for trusted utxo state.
<= div>
No such software exists, and I think the reason is= that most users would not
bother validating anymore= once they have turned to SPV. With AssumeUTXO the
s= ituation is different: there is no option to skip background validation of = the
chain.

The= re will always an alternative solution available for those who don't want t= o
or can't wait for IBD to finish, and it will alway= s be a worse one than what is
being proposed here. W= hy should users bother with SPV then? We will continue
to lose users to custod= ial solutions if we are not willing to offer alternatives
= with a UX that at least comes somewhat close to what today's con= sumers
are used to.

Being able to transact with IBD runnin= g in the background also takes away the
economic and= other pressure off of those who need to get a node started quickly.=

> But of course this presents another pr= oblem, that of the cost of validating
> them, req= uiring full validation of the chain. So this inevitably leads to miner
> commitments.

= AssumeUTXO is anchored to a hash that is hardcoded in Bitcoin Core and revi= ewed
in the open. Anyone running a fully validating = node can independently reproduce
it from their own U= TXO set. That has no relationship to miner behaviour or
PoW-based commitments, and Strateman's concern with about a >50% att= acker
creating new bitcoin, does not apply to it. If= anything, providing a working P2P
path for snapshot= distribution reduces the pressure for any future commitment
scheme rather than enabling one, because the user-facing problem t= hat motivates
commitments is already addressed.

> Even if for some reason you cannot c= omment, I and others can.

I did comme= nt, I just pointed out that I cannot disprove something that doesn't=
exist. I have not been part of any such conversations and = I have not heard of
anyone being part of them.

> It is not hypothetical, and it is dan= gerous. This understanding is at least
> 11 years= old:

Old mailing list conversations = are useful context but they don't prove anything.
Th= e author of the original Bitcoin Prototype software also wrote, "I don't
believe a second, compatible implementation of Bitcoin= will ever be a good idea"
that does= not seem to have stopped you from working on libbitcoin. The Strateman
quote is a sound warning about a specific scheme, but i= t is not a scheme this
BIP proposes.

> These aren't limitations inhere= nt in protocol. The implementation details of a given
> node aren't relevant= .

The protoco= l's job here is to enable obtaining UTXO state from peers rather than from<= /span>
a third-p= arty website. What each implementation does with that capability is, indeed= ,
impleme= ntation. While AssumeUTXO is the primary motivation right now, there may
be othe= r interesting use cases for this down the road.

=
> Median U.S. broadband speed

> Despite a 4x max block size increase in 2016, download time is = decreasing.

Those figures use US-medi= an broadband. Globally the picture is significantly
= different, and a meaningful fraction of users rely on mobile or metered
connections where the difference between "over lunch" a= nd "multiple days"
decides whether they run a node a= t all. The same applies to the 32 GB RAM
= which already excludes a large share of consumer hardware outside high-inco= me
regions.

I = think disregarding hardware and network requirements of users in less devel= oped
countries is causing much higher centralization= pressures today than this UTXO
set sharing proposal= ever could. Following the trajectory of the last few years
to its conclusion, the minimum is likely to be 64 GB next year, the= n 128 GB the
year after, and validating with libbitc= oin will soon require the latest generation
of Nvidi= a chips. Validation time will keep going down on that path, but the<= /div>
user base it serves will keep shrinking.
<= br>
I am obviously exaggerating somewhat to make a point: i= t is easy to construct a
plausible-sounding slippery= slope argument, including one about libbitcoin's
ha= rdware trajectory. And I don't think you are able to prove today that libbi= tcoin
will not follow this path in the future. That = is exactly why I don't find
your similar argument pe= rsuasive.

And in all seriousness, I t= hink at least some Bitcoin implementations should aim to
<= span>be accessible with low bandwidth and minimum hardware requirements com= patible
with widely available consumer hardware outs= ide high-income regions. That is
what many of the de= velopers I work with are aiming for.

= Best,
Fabian
On Saturday, May 16th, 2026 at 7:58 PM, Saint Wenhao <saintwenha= o@gmail.com> wrote:
> I commonly see people expecting IBD to ta= ke a week or more

Because it is true, at least for me, and maybe als= o for some others. You can read some examples on forums, where people run f= ull nodes, and post their progress on a regular basis: https://bitcointalk= .org/index.php?topic=3D5480200

Currently, I started Initial Bloc= kchain Download on some node. It is now around block 250,000, after few hou= rs. 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 limi= ted by what my peers can provide. And if I check 10 connected nodes, and al= l 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 connect= ions.

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 othe= rwise, 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 t= heir connections, to not share too much data too fast, it is what it is. An= d 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 <eric@voskuil.org> na= pisa=C5=82(a):
&= gt; 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 runn= ing 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 sta= rted 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-34G= B
> 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 perception is= rooted in the reality that sequential indexation (even without validation)= does not (cannot) fully take advantage of advancing hardware. This is an i= mplementation 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 prototype w= as provide a scalable implementation - he left that to us. Necessary downlo= ad and validation time/cost is shrinking. Eventually downloading and valida= ting 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 under 5= hours. That's less time than it took almost 10 years ago on the same machi= ne - and my real Internet cost today is about half what it was at that 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 "= 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/002301dce4cf%2427bc3040%247= 73490c0%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/= RiAeHX6Gt48YabQbYIIOFyMF63Pziq12Czi1gSAHlXZ3dBWHIs6l5P-egzOYpyShLUQKVcIeb1p= W358WsHR5pALr6T5xAHoN6Igg9Hg0NS0%3D%40protonmail.com.
--b1=_Rd8a6fPvmB7dPCx7XCToFnZ4e17aZl380TTQWpMtmU--