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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aiKx8i0GSCEh2g5U%40erisian.com.au.
