From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 08 Jun 2026 05:10:35 -0700 Received: from mail-oo1-f58.google.com ([209.85.161.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wWYoM-0006DV-BF for bitcoindev@gnusha.org; Mon, 08 Jun 2026 05:10:35 -0700 Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-69d9f54ab77sf3679111eaf.0 for ; Mon, 08 Jun 2026 05:10:34 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1780920627; cv=pass; d=google.com; s=arc-20240605; b=fKVit4OLWx8COW9tzU3CObyPWaC4iZK03s80RuqCWkpOjt9L6QJK3TaserUsY456Cg E84g1iMUmQM2eM8IdQqxZWpBEBpvc2EZvd+q88RSqVJwIXaREWyUaJr1eDejCE7TEzaY dHOFWK9rsbH57z9fFaxwOUju5sHipOD7ge97YKgH342sFspgwco3PGzKyMa2tYbyBK7y Lp3EsipGKQVNKWMM688OQe39ntZt08FFLjFspgxrC+XU9txXwglosAXbIMruCQOkDW5f wlcolLdq8Dyf9t5d1cRP0PVo9Q992rBPz2XXEJHGJnW3C08B2IJOqcXkxkYY1+aofPrv TJUA== 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; bh=7tTu8NEqc0CyVm+IrabwmPjrFwTdEYUn6tHBU5mjJ9s=; fh=w7urQVDF18pIizfz5Y94N+HCRb5n/7MDP9CwFIKD5rI=; b=Fx8QUsMCVbSHJXsCvlFdhAXzsAfVFMkSTuEYEfPZRNkX4cNEsphPtN+OfPKuz7SaBo Lg4WgrmWhqTfXkWW1310sHPJi9mgv689rvQ6CSl6V9kknQDAmJsLrhXLGTXjK5REYjr/ cg0QqgckXl1oDvFqeKcyyZtHMYAsK0apfuJ5Sph53AYfvJOAIPO42WHMJFpEaA2b2ntb wHmmG0UE/tmpnrpdesttvkxaNWAszbxmOfY/VzBfxHE4ULejGo4y0emuCpPya8XZvtkT +S+myRnCWR20mwuM2XCsXW2IJB4M5iEPoUmhCauDYNmx4ykYU2/1cTsl9vvWTPZdTwNo OfQA==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@2140-dev.20251104.gappssmtp.com header.s=20251104 header.b=A6eizpZm; arc=pass (i=1); spf=none (google.com: josie@2140.dev does not designate permitted sender hosts) smtp.mailfrom=josie@2140.dev; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1780920627; x=1781525427; 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=7tTu8NEqc0CyVm+IrabwmPjrFwTdEYUn6tHBU5mjJ9s=; b=e9r5mpY2yAAOsQ5OMUpmuB87sKNPzISrrrs0g8KEie8YuOZjzkocf2QYYRRlp+Jay+ 83xgLTAo8idibKcJ1BtyVK5oAdHAXL/E7w+VkgLo+7HQqN2aFjEhXQiQ8CqP4b3o5qWl yGYkUduMJjXMrGdhdwBjsDS9CwRv/xauthmzVVQxFKHkTiBx8LLrQEU+xcsEd2i2qH/z FWmmAMvL4hxqD/GrN9glFqt8hXsxYCKZCZyHubqxvuxYQIKqxCVA34BxpMqjpVeV55Se DCgfPZFJtzG/mf6QPukhP7WnFNLRs4a0WTyQvqRff6ZsznNVNNZ7M4F++U1NFGyueK3G 5sDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780920627; x=1781525427; 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=7tTu8NEqc0CyVm+IrabwmPjrFwTdEYUn6tHBU5mjJ9s=; b=F13LgZ/Or2HDNu6f35GOcC2i0I4K/YjggBw3z6PCXI0NXVKSH91Ke0L70IXJOB+UYZ QOi7N7xBDQ65NLb3JOwCDob6yfdx1OObznYmYB44lXwbwuSSB7iOXgUOj9Jyxc1yO7yE FmrN7i76/ix/1JkvQi2yoCjU0MYPaZUA0w5nXOoH7bc8nEKAEjnOItVuLaSOUgFraciF SDR80B8z+Bwyqen6cO/klHXT0JpHxJ4q5GiJEYylNKolnB6i0k15n2OeQ9D8jSPyd0ZU b4P8HzGZTvpXo6OqbaBTVMBNwU9p/6p5MFvdtUlS4LF9WaEJF4igMXMIXT5U5DlYvjjI QFhA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ+pQ2fskxouXIPLgET62AazvpoqENEckuXIr5OKSnmQHvXXbwEa9kcZNsp2xC92iy6dlYqA3mCMf89X@gnusha.org X-Gm-Message-State: AOJu0Ywlaeshm0yudJEy/CvcQAbXC8v9bwnxhiftZgQCy4E5bMYRfei6 vAAdMcdHo0RJZeC6hZBSTRYlfuO08rifHGT3OupmK8ht07uofJ6ipLzU X-Received: by 2002:a05:6820:8591:20b0:69e:41d8:f7e3 with SMTP id 006d021491bc7-69e68c18c94mr5821891eaf.38.1780920627262; Mon, 08 Jun 2026 05:10:27 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUcCQqeOxOLiBSn/4W0l2e7wjtaKb3iGGDjwGBWe91GS5A==" Received: by 2002:a05:6820:61c:b0:696:833f:801d with SMTP id 006d021491bc7-69e591f12edls2765200eaf.1.-pod-prod-04-us; Mon, 08 Jun 2026 05:10:22 -0700 (PDT) X-Received: by 2002:a05:6808:10cc:b0:46e:c1cd:866a with SMTP id 5614622812f47-4868deb1172mr8483395b6e.27.1780920621921; Mon, 08 Jun 2026 05:10:21 -0700 (PDT) Received: by 2002:a05:6809:11:10b0:480:77ce:ad79 with SMTP id 5614622812f47-4868f468ab0msb6e; Mon, 8 Jun 2026 04:37:15 -0700 (PDT) X-Received: by 2002:a17:903:1aef:b0:2c2:7e17:39f6 with SMTP id d9443c01a7336-2c27e173ecfmr32727295ad.36.1780918634538; Mon, 08 Jun 2026 04:37:14 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1780918634; cv=pass; d=google.com; s=arc-20240605; b=Hl9wzgdw+qeV7xMZAu9B0jGZ8WR2LRd4MF5SGGb6lFPJ97PM4DOLkbIcVPfSWGi0cy 5w6bWYpCcJuDG9kKjXOebilNOhsyrnRSf93g5K/00mblKFdP+2xkyRlCoekdR54rrK24 S5xz+QaHI/mdKcfW1ecsjWTc63Hm9R92UBrHs/GtvWSHuoSViCrNytX3/6QGiBIxKxkP Yh53SfRDF91+8IaVTcRh1IwHF9KtMratieJ2BTKrGSiy+4+CvrZOkVuaDuCDhSrib4Dz qKRUrH/5sMkN/kVnyCBdvPj4Ww2MPQou5oV6UGx5OxeWU/2UeA5p+0FNsVe63HAp4RNo sBmg== 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=pgpv6Qq3MFtou0Ii2+LNdA9yn/NWCYFSJ9F9eW+lSbA=; fh=eQwyrPB7DiKLZfk3HA1+IBNTG62m+FxzJ3AFq+zftRc=; b=QcQKznHgYxI3mn5R9IYlzqo/gIRWl2Rw9Lfsgbnjp0/ll8itdBEvgPqj71dJ/LW5vB 4fC2uhpCn+Ffm67XQN4tNOfEBjBPfJFWuV0GSESrGov4MzuCy+ckLi/8GKcSFNLIQy/r NhgMx7gEzDTnY1eRAOj2OXc8Oz8bdTT+HBwGy3fSoxpSTaHHxh4uUETcjD3141i//ucc u0DdG8tWGYS86qClYlEDiFW/LF0Nlj4AQDxCzl2BLTSdJheAj2YJ9leHZXD0vQm14B3m YIckRwID1xIxi8LEtAqsvyVf25LIM0qozq9ioafN1NGX8PWw55pEAKaOb7bE1A0RUXXm xejg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@2140-dev.20251104.gappssmtp.com header.s=20251104 header.b=A6eizpZm; arc=pass (i=1); spf=none (google.com: josie@2140.dev does not designate permitted sender hosts) smtp.mailfrom=josie@2140.dev; dara=pass header.i=@googlegroups.com Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com. [2607:f8b0:4864:20::f30]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-2c164d6152dsi4906195ad.1.2026.06.08.04.37.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2026 04:37:14 -0700 (PDT) Received-SPF: none (google.com: josie@2140.dev does not designate permitted sender hosts) client-ip=2607:f8b0:4864:20::f30; Received: by mail-qv1-xf30.google.com with SMTP id 6a1803df08f44-8ce9df31130so69545096d6.1 for ; Mon, 08 Jun 2026 04:37:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780918634; cv=none; d=google.com; s=arc-20240605; b=EO/wY2bi73lxdYC4SLyT2HsQDfy1HeBm0WVL64XV+EFyb54xkKjl20K5t4l28HLP2N 5FfeLUQ+ddHjXEW3VNpqCifGzHIuKvQL+gyW8BiSPAz2nYrl/86sTlwGtrkzVZi+VEuz rmoCPZyLtfC+0Md87edxZOzenrCKDN5MrSOXOGHBaJFEd7v1F2aTDmMRddJlR1i4n78x jrc5On8ivGz4YR70NHTkE+exXS4TIKPd8iUjjgwFb7/+7ImNZicmAxP3ZDD6QNJ72akM oZG1N7h6+EXRwH7JyKy84P0deDzNxDd0ZdkcOstK/J46HKsPpfZ/QGLj4b1YpdgUsoTb fSaQ== 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=pgpv6Qq3MFtou0Ii2+LNdA9yn/NWCYFSJ9F9eW+lSbA=; fh=eQwyrPB7DiKLZfk3HA1+IBNTG62m+FxzJ3AFq+zftRc=; b=Upih6xzq5+LfCtAW4HgAWPkdewAfZ58FL8bek6cp4L3cUsUyZp72H8QU8vQIbdRA4F BXuEPZ0LdsnJb+Osoo6meMtYEtUSyIzvSJt5vDYwcTE1wHFCuh7SfuNi9OtH4esa5B8U 6eh5WiiuhiyZqsfZ3EoyaLjlZKdy0OrpfSkvZin2uWECttIyx6booZjge6k32f4Om/rW L4SdLFxSxPcsovUUPKBARz1KYVK7aWMCQAYM1QhyUPDuDFDL1Uhy6M/qWUZX7uxhQGQu C9B1n8iu2c0X2NXSOquAhcQyjWwMwqRu7kQWtadt7nJEHoLA9jkiXAwu09ggOUWvPf1V 6IHw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: Acq92OFIio3IJwx4cjaccTvuehlqQviINpZIw1UegKA22gg+YqRLshfStqDn24waR2F kEGGyNzV/QsmM1PR31Br1c9+D0cFjC0VVOUqE4Skx6rflGBrODSOEA3kqmm/KKOd1E/gSaVJv7L WM6+YNOI17fZe7rGBM7cC9HhaL/FyQvBwrmzL1+qdWcsaRbOwhFG2xoZkjl2x+OkAeRpoxQcbDo Bel3LWHsNo99ocpZ7abI/FtLqR0GnzaF5xGms5KwdkCIOsVG9v/1rHcW4X5FdFrESKTt2EbhMAw 3DHQLAZsxaqdqWhxRfq48XF9wmP0Djly7rqvbwMLYWLLQG7ZKQXySfGSu4N5BjujIg== X-Received: by 2002:a05:622a:400c:b0:517:7971:a234 with SMTP id d75a77b69052e-51795b729ffmr216118341cf.4.1780918633704; Mon, 08 Jun 2026 04:37:13 -0700 (PDT) MIME-Version: 1.0 References: <8661e699-47d8-46e4-a561-41c5d2fdc0e6n@googlegroups.com> In-Reply-To: From: Josie Baker Date: Mon, 8 Jun 2026 13:37:02 +0200 X-Gm-Features: AVVi8CfRtVJQnBz3BIFHtujRQjT0YW0JAwno9cSbnzU1ShwDLTiKH3rxBudWg5I Message-ID: Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing To: Anthony Towns Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000893ad80653bc6e77" X-Original-Sender: josie@2140.dev X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@2140-dev.20251104.gappssmtp.com header.s=20251104 header.b=A6eizpZm; arc=pass (i=1); spf=none (google.com: josie@2140.dev does not designate permitted sender hosts) smtp.mailfrom=josie@2140.dev; 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.7 (/) --000000000000893ad80653bc6e77 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi aj, I want to push back on this framing: > Trying to prevent other people from making different choices and helping their peers who make the same choices doesn=E2=80=99t seem a sensible use o= f your time. Disagreeing with a technical design, or arguing that it should not be merged into Bitcoin Core or added to the p2p protocol, is not the same thing as trying to prevent people from making different choices. People are free to build, maintain, fork, distribute, and use software with different trust and architectural tradeoffs. Most importantly, people are also free to offer critiques. This distinction matters. If every architectural objection gets reframed as =E2=80=9Cyou are trying to prevent people from choosing differently,=E2=80= =9D then review shifts away from the merits of the design and toward the motives of the reviewer. Bitcoin protocol review necessarily includes saying =E2=80=9CI do= not think this is a good idea,=E2=80=9D and sometimes even =E2=80=9CI think thi= s existing feature should be removed.=E2=80=9D That is how a conservative project avoi= ds accumulating complexity and compounding technical debt. Cheers, josie On Fri, Jun 5, 2026 at 1:24=E2=80=AFPM Anthony Towns wr= ote: > On Tue, May 19, 2026 at 02:32:33AM -0700, josie wrote: > > I'd like to instead take a step back and ask why is this being proposed > in > > the first place? Even if I agreed with the AssumeUTXO approach (I do > not), > > I would still push back on p2p sharing. AssumeUTXO's trust model is bui= lt > > around a hash committed to in the Bitcoin Core binary, which the snapsh= ot > > is then verified against. So why not just distribute the snapshot from > > bitcoincore.org along with the release? > > Is Bitcoin a P2P network, or a product from Bitcoin Core? Should we > design protocols that treat everyone in the P2P network as peers, or > should we give Bitcoin Core a privileged position? > > The current draft of the BIP gives a fixed formula for which blocks to > take snapshots from that any node developer can use, with no dependence > on when Bitcoin Core happens to make releases, defines a fixed format > for encoding those snapshots, and allows anyone interested to securely > distribute those snapshots, whether the use the same node software or > not. Isn't that fundamentally more in-tune with how Bitcoin should work > than "oh, just download and trust the data from this website" ? > > (Even if you don't think people should be running different clients, > having the *option* to do so avoids people being vendor lock-in being > used to gain undue influence; and having as much as possible happen over > P2P networks rather than client/server systems via well-known domains > is one step at reducing vendor lock-in) > > In practical terms, currently there are new releases hosted on > bitcoincore.org every month or two, which look like they include ~4GB of > debug-enabled archives, and maybe ~1GB of release data. Adding an extra > ~10GB every 3 or 6 months is probably okay, though the extra transfer > bandwidth for new installs might be significant and less reasonable. I'm > not sure what the speed of downloading the utxoset is likely to be -- > I get maybe 16MB/s currently, but maybe you'd expect that to go down > significantly if setting up a new node went from a 100MB to 100x that. > > > As you said, this is meant to be > > opt-in so why not keep it fully opt-in by not adding code and attack > > surface to the p2p code that everyone who runs Bitcoin Core will use? > > Part of being "opt-in" includes having the code already available, so > it's just a matter of setting a config option, rather than implementing > the spec yourself. > > > Furthermore, having the snapshot be distributed by Bitcoin Core makes t= he > > trust model explicitly clear: if you don't trust downloading a snapshot > > from the Bitcoin Core website then you certainly shouldn't be trusting > the > > hash committed to in the Bitcoin Core binary. > > If the download is secured by a hash, then issue isn't whether you trust > the download (you check the hash anyway), it's whether the download > might be unavailable, censored, or unreasonably slow. P2P distribution > gives you different, potentially better, tradeoffs there. > > > This also makes the feature > > available to any user who wants to use it, without requiring a certain > > number of peers on the network to also support it. I'd much rather > validate > > beforehand how many people are *actually* using this feature before we > > continue writing more code to support it. > > Hosting the data on a single centralised site is exactly equivalent to > one well-known node on the P2P network supporting it. > > > I'd also like to comment on the bandwidth arguments being used as a > > justification for AssumeUTXO. This does not make sense to me. Low > bandwidth > > areas are often on metered bandwidth and AssumeUTXO increases bandwidth > > usage, not decreases. > > The increase in bandwidth of downloading the utxo set and also downloadin= g > the entire blockchain history is about the same as maybe five weeks' > of block data. If you can't afford that, you likely can't afford IBD at > all. Conversely, if you've got some unmetered way of doing IBD, then you > can likely use the same method for the utxo set download. If that method > happens to be "I already have a local node that I want to duplicate", > then having utxo set sharing over p2p makes that more convenient. > > > Furthermore, if low bandwidth is a concern, has > > anyone taken the time to do the math and verify that the node will catc= h > up > > to the snapshot in a reasonable amount of time? As a reminder, the node > > also needs to keep up with new blocks and transaction relay, which woul= d > > take away available bandwidth/CPU from validating in the background. > > A node can run in blocksonly mode to avoid transaction relay costs, and > if a node can't keep up in blocksonly mode while doing background IBD, > it also likely can't catch up just doing foreground IBD -- it's the same > amount of data to receive and process either way. > > > I keep > > hearing "accepting payments" as the use case, which implies to me the > node > > would care a lot more about validating recently blocks and learning abo= ut > > transactions. This implies the node may never catch up, or catch up so > > slowly that it invalidates the trust model of AssumeUTXO. > > The time to download and reconstruct a particular recent utxo set from > a snapshot is significantly lower than the time taken to do an entire > IBD up to that same point. Without a utxo set (or a utreexo root) you > aren't yet running a node, so you can't do whatever you were wanting to > do with your node, which is presumably accepting payments. > > If you're willing to spend the time to IBD, or willing to adopt a > different trust model that takes even less time, that's fine, you > should continue using other approaches. Trying to prevent other people > from making different choices and helping their peers who make the same > choices doesn't seem a sensible use of your time. I realise I'm fighting > against the "there's a right way to do things; my way is that right way; > doing it any other way is wrong; and wrong things should be prevented > at every turn" meme, but oh well, that's my way, I guess. > > Of course, If there are some novel tradeoffs that would change people's > minds about whether AssumeUTXO is what they want if they knew about them, > then that's good to know about, but I don't think you've come up with > anything along those lines. > > Cheers, > aj > > --=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/= CADpMdeOx5c3yJ1b_0OC-07m5_uvObQRSAfwxKm3CvX59anCYhw%40mail.gmail.com. --000000000000893ad80653bc6e77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi aj,=C2=A0

I want to push back on this framing:
> Trying to prevent other people from making different choices and= helping their peers who make the same choices doesn=E2=80=99t seem a sensi= ble use of your time.

Disagreeing with a technical design, or arguin= g that it should not be merged into Bitcoin Core or added to the p2p protoc= ol, is not the same thing as trying to prevent people from making different= choices. People are free to build, maintain, fork, distribute, and use sof= tware with different trust and architectural tradeoffs. Most importantly, p= eople are also free to offer critiques.

This distinction matter= s. If every architectural objection gets reframed as =E2=80=9Cyou are tryin= g to prevent people from choosing differently,=E2=80=9D then review shifts = away from the merits of the design and toward the motives of the reviewer. = Bitcoin protocol review necessarily includes saying =E2=80=9CI do not think= this is a good idea,=E2=80=9D and sometimes even =E2=80=9CI think this exi= sting feature should be removed.=E2=80=9D That is how a conservative projec= t avoids accumulating complexity and compounding technical debt.

Che= ers,
josie

On Fri, Jun 5, 2026 at 1:24= =E2=80=AFPM Anthony Towns <aj@erisi= an.com.au> wrote:
On Tue, May 19, 2026 at 02:32:33AM -0700, josie wrote:
> I'd like to instead take a step back and ask why is this being pro= posed in
> the first place? Even if I agreed with the AssumeUTXO approach (I do n= ot),
> I would still push back on p2p sharing. AssumeUTXO's trust model i= s built
> around a hash committed to in the Bitcoin Core binary, which the snaps= hot
> is then verified against. So why not just distribute the snapshot from=
> bitcoincore.org along with the release?

Is Bitcoin a P2P network, or a product from Bitcoin Core? Should we
design protocols that treat everyone in the P2P network as peers, or
should we give Bitcoin Core a privileged position?

The current draft of the BIP gives a fixed formula for which blocks to
take snapshots from that any node developer can use, with no dependence
on when Bitcoin Core happens to make releases, defines a fixed format
for encoding those snapshots, and allows anyone interested to securely
distribute those snapshots, whether the use the same node software or
not. Isn't that fundamentally more in-tune with how Bitcoin should work=
than "oh, just download and trust the data from this website" ?
(Even if you don't think people should be running different clients, having the *option* to do so avoids people being vendor lock-in being
used to gain undue influence; and having as much as possible happen over P2P networks rather than client/server systems via well-known domains
is one step at reducing vendor lock-in)

In practical terms, currently there are new releases hosted on
bit= coincore.org every month or two, which look like they include ~4GB of debug-enabled archives, and maybe ~1GB of release data. Adding an extra
~10GB every 3 or 6 months is probably okay, though the extra transfer
bandwidth for new installs might be significant and less reasonable. I'= m
not sure what the speed of downloading the utxoset is likely to be --
I get maybe 16MB/s currently, but maybe you'd expect that to go down significantly if setting up a new node went from a 100MB to 100x that.

> As you said, this is meant to be
> opt-in so why not keep it fully opt-in by not adding code and attack > surface to the p2p code that everyone who runs Bitcoin Core will use?<= br>
Part of being "opt-in" includes having the code already available= , so
it's just a matter of setting a config option, rather than implementing=
the spec yourself.

> Furthermore, having the snapshot be distributed by Bitcoin Core makes = the
> trust model explicitly clear: if you don't trust downloading a sna= pshot
> from the Bitcoin Core website then you certainly shouldn't be trus= ting the
> hash committed to in the Bitcoin Core binary.

If the download is secured by a hash, then issue isn't whether you trus= t
the download (you check the hash anyway), it's whether the download
might be unavailable, censored, or unreasonably slow. P2P distribution
gives you different, potentially better, tradeoffs there.

> This also makes the feature
> available to any user who wants to use it, without requiring a certain=
> number of peers on the network to also support it. I'd much rather= validate
> beforehand how many people are *actually* using this feature before we=
> continue writing more code to support it.

Hosting the data on a single centralised site is exactly equivalent to
one well-known node on the P2P network supporting it.

> I'd also like to comment on the bandwidth arguments being used as = a
> justification for AssumeUTXO. This does not make sense to me. Low band= width
> areas are often on metered bandwidth and AssumeUTXO increases bandwidt= h
> usage, not decreases.

The increase in bandwidth of downloading the utxo set and also downloading<= br> the entire blockchain history is about the same as maybe five weeks' of block data. If you can't afford that, you likely can't afford IB= D at
all. Conversely, if you've got some unmetered way of doing IBD, then yo= u
can likely use the same method for the utxo set download. If that method happens to be "I already have a local node that I want to duplicate&qu= ot;,
then having utxo set sharing over p2p makes that more convenient.

> Furthermore, if low bandwidth is a concern, has
> anyone taken the time to do the math and verify that the node will cat= ch up
> to the snapshot in a reasonable amount of time? As a reminder, the nod= e
> also needs to keep up with new blocks and transaction relay, which wou= ld
> take away available bandwidth/CPU from validating in the background.
A node can run in blocksonly mode to avoid transaction relay costs, and
if a node can't keep up in blocksonly mode while doing background IBD,<= br> it also likely can't catch up just doing foreground IBD -- it's the= same
amount of data to receive and process either way.

> I keep
> hearing "accepting payments" as the use case, which implies = to me the node
> would care a lot more about validating recently blocks and learning ab= out
> transactions. This implies the node may never catch up, or catch up so=
> slowly that it invalidates the trust model of AssumeUTXO.

The time to download and reconstruct a particular recent utxo set from
a snapshot is significantly lower than the time taken to do an entire
IBD up to that same point. Without a utxo set (or a utreexo root) you
aren't yet running a node, so you can't do whatever you were wantin= g to
do with your node, which is presumably accepting payments.

If you're willing to spend the time to IBD, or willing to adopt a
different trust model that takes even less time, that's fine, you
should continue using other approaches. Trying to prevent other people
from making different choices and helping their peers who make the same
choices doesn't seem a sensible use of your time. I realise I'm fig= hting
against the "there's a right way to do things; my way is that righ= t way;
doing it any other way is wrong; and wrong things should be prevented
at every turn" meme, but oh well, that's my way, I guess.

Of course, If there are some novel tradeoffs that would change people's=
minds about whether AssumeUTXO is what they want if they knew about them, then that's good to know about, but I don't think you've come u= p with
anything along those lines.

Cheers,
aj

--
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/ms= gid/bitcoindev/CADpMdeOx5c3yJ1b_0OC-07m5_uvObQRSAfwxKm3CvX59anCYhw%40mail.g= mail.com.
--000000000000893ad80653bc6e77--