From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 05 Jun 2026 04:40:40 -0700 Received: from mail-oi1-f186.google.com ([209.85.167.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wVSul-0007Y9-EO for bitcoindev@gnusha.org; Fri, 05 Jun 2026 04:40:39 -0700 Received: by mail-oi1-f186.google.com with SMTP id 5614622812f47-48638069322sf1834406b6e.1 for ; Fri, 05 Jun 2026 04:40:39 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1780659633; cv=pass; d=google.com; s=arc-20240605; b=lb5a+lbfiBJkEvMdAQDA66aBR3BdjjsDKjWTOu4kynYARlK3RNctUp3nUpv4YaZBnD CAb7SRUHlcrzhqzY0O9Wg/JiKMNMbadieoyohDNtSZdRB8IED2p5zFlPjyqQnOjOdfd9 uTh0w4QyZVwuWVe26/UzkaTgmGs99v+lXJm4w7BD4JZYmRD8Sx82uJ0ZhCnXpp7XHi1L F8OU93fPJnEP97B3Xf+zyO//6ThmBEMiy1kJ4HuD6qKiLkTVcq1QATj/wRrbq4SywEuT LrD5he5XbKP2vIo2He276FyDcIOFgPiBy3g1R1vC03D0NDjlRkRFq0b2jVteQh5CN8ss thHg== 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:in-reply-to:content-disposition :mime-version:message-id:subject:cc:to:from:date:sender :dkim-signature; bh=Lw8mounPq6Bf1OuXUuyu7TMh3GFbshphPtLc2mAObnU=; fh=TxpOJECphbRGWWsnnAulE56jYylSYeqLlvZjqG2gnHU=; b=CU2yjGa3NmK1IyoNb64LxXLWXYTQhW61D0q4PeViFkgcizhB4eBzcIisPgueRD+kGh nCDaLya93rFS/cgc57uMz1gwfOMSZsROlxUVl8ikA93Il50bFapv71XO/JNlU4saLKA/ jnQ0MHdL5hRlozNPJbVJUf5k4VzXX83BiyhGkpO4RLAL9zU4mgH2ecZJbJgl1EK00Ysc Pn4pAooDzGxzpat4OBWgEndWxRc1huMCl92VsBAzdELsy776DXNPUXuK15pJzx9frY0z RR/9bNMQ639WdUTqdM0YoyZdJgnVHKV+NEbt0z2UFbWAhclX/ANR6EqAt+QO2jtYicjZ HopQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1780659633; x=1781264433; 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:in-reply-to:content-disposition:mime-version :message-id:subject:cc:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=Lw8mounPq6Bf1OuXUuyu7TMh3GFbshphPtLc2mAObnU=; b=RNq/aq4cRc7B8qu0z6DoL/ZYmNpSqindPRPbPncGvY228RW+G7838pYEmNjpcyhti+ AxoU+3bj+GOjbRsuXWrWhXyBWTQ8TVJRBqRd77ZPYUYykWOAQvrhkccfjsDswTPqbFhP qTjs7dxcwqb6RxRgQ/wPc+7Tsk0uOIobfDd70/YVH4D9niLeh9zYCvsOVCSqh36BOpKj JimOyydXDqTIZROmkNg4BMV4bo9Oc6Ba9en+csyW2vng+uiLgtBxrzeuHCQRxG/ploin fpcVcsA8A04Gfnp3VE6IPE+SEfJxObmtr1KAC3/9w7f6vwsKMrHia65XFIePtLBLlLEh bMUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780659633; x=1781264433; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :message-id:subject:cc:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=Lw8mounPq6Bf1OuXUuyu7TMh3GFbshphPtLc2mAObnU=; b=aYwUtZDjRgwORaRK0gd5/nxU1Ue+kiKnps6IM3pTQvRyklsr723RfspSEub56c/NjP ZRRLxVPdpm0gYB6VUc+xmT+A2q6xQCzRYOwzOzvskwIGT/tJL8SFveVjQWXgxH9Yvtja /yAxRTbyiMeyd2zdOUxUDEcve3dSKTKtr/UMagc7qxOmv8pKpf2PutkosYuOCi0gZJ0L M/ilfeqMb/SRT8gHJ1IShzCciPmoBj3r1UIYO6EkxzVWETUqLGDZ3UMM78d8+09kafOu y8mw6fQGm5E5e8fYwgxLGmgjc43vp4l5lHZvxiboESokcK9DKaKa64W/V83aOnSZ4e2/ UK6A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ9jcXRaOizPjaEFpgyciXh1gttTjJlJtI3DfI99G1Pny2uyAYho+7G2lJQcydEfwUzShDPeqJGdDatC@gnusha.org X-Gm-Message-State: AOJu0Yyw/vzFFrcW7INdOZSJKE/VSt/CZz9u+XJqfDpbV3CdtbxROMt5 sHTy1sp/IYaL8q5RvMVgWp/RMpbDPXldIYXllCRoZ2j2vcnrUadw+/Gb X-Received: by 2002:a05:6808:1b2a:b0:485:d347:f1d1 with SMTP id 5614622812f47-4868de25223mr1767340b6e.11.1780659633304; Fri, 05 Jun 2026 04:40:33 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUeCE9atTwSwPoycq4ek9pMkggurB70YBrIfR9J6WwFRWQ==" Received: by 2002:a05:6871:3313:b0:43f:a4c9:acab with SMTP id 586e51a60fabf-44109606c3fls1755000fac.0.-pod-prod-03-us; Fri, 05 Jun 2026 04:40:27 -0700 (PDT) X-Received: by 2002:a05:6808:144c:b0:472:cd4c:c36f with SMTP id 5614622812f47-4868dddb82amr1553298b6e.3.1780659627358; Fri, 05 Jun 2026 04:40:27 -0700 (PDT) Received: by 2002:a05:6808:8193:20b0:479:9f23:6621 with SMTP id 5614622812f47-4868f800c0fmsb6e; Fri, 5 Jun 2026 04:24:42 -0700 (PDT) X-Received: by 2002:a05:6871:6c0a:b0:430:3591:26c4 with SMTP id 586e51a60fabf-4413d6a1654mr1413673fac.7.1780658681720; Fri, 05 Jun 2026 04:24:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780658681; cv=none; d=google.com; s=arc-20240605; b=JXDAtvC3QPUrDkSSevV2gMZEgC6o9vzuHtz3O3vgOC2fZjH/Mwc1YvGXFkIBhRG54s FTDZ1YbzQGdL8lnFcZV7F1LlgpmBYnMuH9Fc0P5phI5CXune9T7b3xsGG9yw4eP5DOA7 xtJUnJ9t9YPak8XO6D7a/uomg+d5A9L4nmt/sJ6oWvOvhXwS/MAEl2xhL4B/C3uXR24h gD8U20Rp6Elb7ziYRRFpzDqw9jhbYnGRUgvaDywr6TGTO9q+/uCFpLdxBckGXGBaSz4q egtz5MHB+iz05oJE3oKM5GpZQBRdumO2PFZVC9bYqxa4e2MiPUc7ILxKlOT56ehaDwyu Wnxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=in-reply-to:content-disposition:mime-version:message-id:subject:cc :to:from:date; bh=i6FQDGUHQU9IQjImO6fOsRSPcRlgX3LsHwiFho3p+qU=; fh=kcu2TuYsAhFPPIH08dMhXO1Q08MxqNa/Ln77l7XY83M=; b=d4Cs5cgZWK8/DjBMbhdKjIFy1HhJRDPiwxfehBQUAroEUJzteV6YksBoNmtQYXaswC +Zd656sqE8QYQXQ1ABn3BpvP4rF2Io3R6eJjvSOjDcwOir5I5Dnnz28sgP4vddB1GO7+ xzJPBYX8R9Oc6dZ11sqX/fGvffxnAlo++KDejqzpbF/Q4fj7kUsAmedc6hBUC2nNbxCN MhlpKZMNzJsPLFwNodoeWsf43j/9k36gNOTiY3ANanY8Rk/JLNBmBPzZFDHdZ5SJTO32 iPm/Z+4ExA4gXqRfYke3Kv2s4F/XEn41bpJZdsLkVrAHZXhAKiWMKQjd2Pu1qubuF3c2 UAIg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au Received: from cerulean.erisian.com.au (azure.erisian.com.au. [172.104.61.193]) by gmr-mx.google.com with ESMTPS id 586e51a60fabf-440d8465d7bsi313144fac.6.2026.06.05.04.24.41 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2026 04:24:41 -0700 (PDT) Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193; Received: from aj@azure.erisian.com.au by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wVSfF-0007tJ-0D; Fri, 05 Jun 2026 21:24:39 +1000 Received: by email (sSMTP sendmail emulation); Fri, 05 Jun 2026 21:24:34 +1000 Date: Fri, 5 Jun 2026 21:24:34 +1000 From: Anthony Towns To: josie Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <8661e699-47d8-46e4-a561-41c5d2fdc0e6n@googlegroups.com> X-Spam_score: -0.0 X-Spam_bar: / X-Original-Sender: aj@erisian.com.au X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au 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.8 (/) 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 built > around a hash committed to in the Bitcoin Core binary, which the snapshot > 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 the > 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 downloading 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 catch 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 would > 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 about > 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 -- 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/aiKx8i0GSCEh2g5U%40erisian.com.au.