{ "number": 35054, "repo": "bitcoin/bitcoin", "url": "https://github.com/bitcoin/bitcoin/pull/35054", "title": "p2p: UTXO set sharing", "author": "fjahr", "author_association": "CONTRIBUTOR", "created_at": "2026-04-10T21:58:50Z", "updated_at": "2026-08-24T13:33:55Z", "age_days": 159, "draft": true, "labels": [ "P2P", "Needs rebase", "CI failed" ], "milestone": null, "base": "master", "head_sha": "cf5d5b9533e182c2e01b165160edbd09ad5d1ef9", "head_ref": "2026-02-utxo-set-share-safe-take-2", "head_repo": "fjahr/bitcoin", "head_history": [], "additions": 1714, "deletions": 1, "changed_files": 27, "commit_count": 13, "size_bucket": "XL", "mergeable_state": "dirty", "bot": { "drahtbot": { "present": true, "reviews": { "concept_nack": [ { "login": "eynhaender", "url": "https://github.com/bitcoin/bitcoin/pull/35054#issuecomment-4389294334" }, { "login": "l0rinc", "url": "https://github.com/bitcoin/bitcoin/pull/35054#issuecomment-4441289838" }, { "login": "stickies-v", "url": "https://github.com/bitcoin/bitcoin/pull/35054#pullrequestreview-4282043084" }, { "login": "evoskuil", "url": "https://github.com/bitcoin/bitcoin/pull/35054#issuecomment-4381238874" }, { "login": "narula", "url": "https://github.com/bitcoin/bitcoin/pull/35054#issuecomment-4500604664" }, { "login": "nkaretnikov", "url": "https://github.com/bitcoin/bitcoin/pull/35054#issuecomment-4530630413" } ], "concept_ack": [ { "login": "andrewtoth", "url": "https://github.com/bitcoin/bitcoin/pull/35054#issuecomment-4232617678" }, { "login": "svanstaa", "url": "https://github.com/bitcoin/bitcoin/pull/35054#issuecomment-4282948342" } ] }, "conflicts": [ { "number": 35148, "title": "refactor: Remove confusing DataStream::in_avail() alias", "author": "maflcko" }, { "number": 34860, "title": "mining: always pad scriptSig at low heights, drop include_dummy_extranonce", "author": "Sjors" }, { "number": 34628, "title": "p2p: Replace per-peer transaction rate-limiting with global rate limits", "author": "ajtowns" }, { "number": 34075, "title": "fees: Introduce Mempool Based Fee Estimation to reduce overestimation", "author": "ismaelsadeeq" }, { "number": 33421, "title": "node: add `BlockTemplateCache`", "author": "ismaelsadeeq" }, { "number": 31974, "title": "Drop testnet3", "author": "Sjors" }, { "number": 28690, "title": "build: Introduce internal kernel library", "author": "sedited" } ] } }, "acks_parsed": { "andrewtoth": { "kind": "concept_ack", "hash": null, "t": "2026-04-12T19:50:55Z", "stale": false }, "svanstaa": { "kind": "concept_ack", "hash": null, "t": "2026-04-20T17:30:13Z", "stale": false }, "danielabrozzoni": { "kind": "concept_ack", "hash": null, "t": "2026-04-30T16:45:53Z", "stale": false }, "evoskuil": { "kind": "concept_nack", "hash": null, "t": "2026-05-05T16:44:26Z", "stale": false }, "eynhaender": { "kind": "concept_nack", "hash": null, "t": "2026-05-06T14:53:15Z", "stale": false }, "narula": { "kind": "concept_nack", "hash": null, "t": "2026-05-20T16:47:06Z", "stale": false }, "nkaretnikov": { "kind": "concept_nack", "hash": null, "t": "2026-05-25T00:16:04Z", "stale": false } }, "acks_tally": { "ack": 0, "stale_ack": 0, "concept_ack": 3, "approach_ack": 0, "nack": 0, "concept_nack": 4, "approach_nack": 0 }, "reviews": { "approved": 0, "changes_requested": 0, "distinct_reviewers": [ "ajtowns", "andrewtoth", "danielabrozzoni", "evoskuil", "eynhaender", "josibake", "l0rinc", "narula", "nkaretnikov", "sipa", "stickies-v", "svanstaa", "yancyribbens" ] }, "signals": { "needs_rebase": true, "ci_failed": true, "mergeable_state": "dirty", "last_author_activity": "2026-05-24T23:34:13Z", "last_reviewer_activity": "2026-06-05T07:20:43Z", "last_reviewer": "ajtowns", "author_silent_days": 115, "waiting_on_author_days": 104, "days_since_update": 24 }, "refs": { "mentioned": [], "depends_on": [], "fixes": [], "linked_issues": [], "references": [], "conflicts": [ 35148, 34860, 34628, 34075, 33421, 31974, 28690 ] }, "stack": { "shares_commits_with": [], "based_on": [], "base_for": [] }, "review_paths": [ "src/node/utxo_set_share.cpp", "src/rpc/blockchain.cpp" ], "body": "This implements a [draft BIP](https://github.com/bitcoin/bips/pull/2137) for a protocol to share a UTXO set over P2P. Ideally, please review the BIP draft along side this PR if you already want to look at the code.\n\n### Motivation\n\nThe motivation is to make it possible to use the assumeutxo feature without having to acquire a snapshot from a third party.\n\n### UX\n\nThe UX for the user is very similar to how `loadtxoutset` works today:\n\n- The user starts their new node and has to wait until the headers have synced\n- The user then invokes the RPC `downloadutxoset` with their selected height\n- The utxo set download finishes in the background\n- Upon completion the snapshot is compared to assumeutxo params and if those match, it is activated\n\n### Design choices\n\n- Capability to serve UTXO sets is signaled with a service bit\n- The UTXO set is shared in chunks of 3.9 MB\n- A merkle root of these chunks serves as integrity check to prevent sending useless data as a trivial DoS vector\n- UTXO set snapshots for sharing are placed in a `share` folder in the datadir, they are atomically loaded on startup and then shared\n- A node that downloaded a snapshot will share it themselves until the snapshot has been deleted from their share folder\n- The merkle root is introduced to the assumeutxo data in the chainparams to ensure peers can not lie to us about it\n\n### Status\n\nThis is certainly still rough around the edges and the merkle roots in the chain params have not all been filled in yet. I am primarily looking for concept and approach feedback as well as potentially overlooked DoS vectors to start.\n\nIf you find a DoS vector on the serving side feel free to crash the live demo node below for bragging rights. Just please give me a heads up afterwards :)\n\n### Live demo\n\nThe feature can be tried out on mainnet:\n\n1. Build this branch (duh)\n2. Start with a fresh node (datadir) and `-connect=178.104.141.103:8333 -debug=utxosetshare`. You can also use `addnode` but this will make it harder to watch the logs since historical blocks are still synced at the same time. Note that since the demo node is pruned, your node will need to be restarted to sync blocks after snapshot validation if you are using `-connect`.\n4. Wait until the headers have synced, then use `bitcoin-cli downloadutxoset 935000`\n5. Watch the logs to see the the chunks come in and then see the completed snapshot getting activated", "commits": [ { "sha": "350985da5e7f602d3aef84fa69b6e3348fbb3074", "date": "2026-04-09T20:30:49Z", "message": "net: Add NODE_UTXO_SET service bit and message types\n\nAdd NODE_UTXO_SET (bit 12) service flag indicating the node can\nserve a UTXO set over P2P.\n\nAlso add the P2P message types for UTXO set sharing." }, { "sha": "34fd9f6c3e0681e094eb3e63c441b9721e48594a", "date": "2026-04-09T20:30:50Z", "message": "log: Add UTXOSETSHARE category" }, { "sha": "78969203f561045273b2be1aa3407ee35a0829c3", "date": "2026-04-09T21:46:34Z", "message": "consensus: Expose ComputeMerklePath and add merkle proof verification\n\nAllows reuse of ComputeMerklePath() for UTXO set chunk Merkle proofs." }, { "sha": "9a6fd56aea32dd23d9ae156e74ba42cf3e04bd82", "date": "2026-04-09T21:46:42Z", "message": "net: Define P2P message serialization for UTXO set sharing" }, { "sha": "d16e35ac62b1c81648ac62a85907fba97ab44738", "date": "2026-04-09T22:10:43Z", "message": "node: Implement UTXO set share provider\n\nScans a share directory for valid dumptxoutset snapshot files, validates\nthem against known assumeutxo parameters and then serves chunks with Merkle\nproofs. A sidecar file is generated to cache the necessary data and\nsignal the file has already been verified in future restarts." }, { "sha": "3f8e5c0dc955286842b3267eddfcaac9c8040eab", "date": "2026-04-09T22:11:05Z", "message": "init: Scan share folder in datadir for sharable snapshots" }, { "sha": "ef15e22d584d33ab180021ea5cb73b1ddfacf4e6", "date": "2026-04-09T22:11:26Z", "message": "net: Handle getutxostinf and getutxoset P2P messages" }, { "sha": "a00eebc6b5fbdc8ef6f8dd3313c5e67990043b51", "date": "2026-04-09T22:12:53Z", "message": "node: Implement UTXO set download manager\n\nThe fetched UTXO set is written to the share dir so the node can\nserve the downloaded snapshot afterwards." }, { "sha": "0943ed1f179fe57752720de994aeec8433a655af", "date": "2026-04-10T21:49:37Z", "message": "rpc: Add downloadutxoset RPC" }, { "sha": "0cda5f60a1c9575542e41db9f0f94232adacc1f5", "date": "2026-04-10T21:49:40Z", "message": "contrib: Add snapshot merkle root tool\n\nStandalone script that computes the merkle root of a\ndumptxoutset snapshot file. The output can be used to set\nthe chunk_merkle_root field in the assumeutxo chain params." }, { "sha": "b131adeb2598192f6d4d1bc9e0ac58d7e9ade234", "date": "2026-04-10T21:49:40Z", "message": "net: Validate chunk Merkle root against assumeutxo chain params\n\nAdd chunk_merkle_root to AssumeutxoData so the download manager can\nreject peers that advertise a different Merkle root than expected.\nThis prevents a peer serving a UTXO set where the merkle root does\nnot correspond to the UTXO set a the expected height or has the\ncorrect serialized hash.\n\nCheck is skipped for now if no value is set for easier testing and\nbackwards compatibility." }, { "sha": "3fffb9f085da68add78d4cdffcf2634b71184ea1", "date": "2026-04-10T21:49:40Z", "message": "test: Add functional test for P2P UTXO set sharing\n\nMakes the necessary changes to the functional test framework\nlike adding constants.\n\nAlso tests common failure cases:\n- Disconnect on wrong block hash\n- Disconnect on wrong height\n- Non-serving node doesn't advertise NODE_UTXO_SET\n- Non-serving node ignores getutxostinf\n- RPC error on downloadutxoset with invalid height\n- RPC error on duplicate downloadutxoset calls" }, { "sha": "cf5d5b9533e182c2e01b165160edbd09ad5d1ef9", "date": "2026-04-10T21:49:41Z", "message": "chainparams: Add missing snapshot merkle roots" } ], "timeline": [ { "t": "2026-04-12T19:50:55Z", "kind": "comment", "who": "andrewtoth", "assoc": "CONTRIBUTOR", "text": "Concept ACK\n\nWhy invoke an RPC, instead of a configuration option (which can be set by default at a later point)?\n\nIf ActivateSnapshot fails, download manager is forever in COMPLETE state. Not sure what we should do in that case. It would mean something is very wrong if our committed merkle root doesn't result in a correct snapshot, or there's disk error. Probably want to abort?\n\nDoS on downloading side:\nServer can set `utxosetinfo`'s `data_length` field to 10 PB, which causes the receiving node to allocate >60 GB immediately.\nRecommend committing the `data_length` field alongside the merkle root." }, { "t": "2026-04-20T17:30:13Z", "kind": "comment", "who": "svanstaa", "assoc": "CONTRIBUTOR", "text": "Concept ACK\n\nBuilt the branch, set up fresh data dir, connected exclusively to the demo node (-connect=178.104.141.103:8333 -debug=utxosetshare). Waited for headers to sync, then started the snapshot download: bitcoin-cli downloadutxoset 935000.\n\nObservations:\n- snapshot was activated and node came up at height 935000\n- restarted without -connect to reconnect to the broader network\n- Node synced from the snapshot to current tip normally\n- Background validation from genesis also started\n\nOverall feature works as advertised.\n\nAlso tried to shoot down the test node via several methods, but it survived all attempts. Will do another post later with the details." }, { "t": "2026-04-29T16:21:47Z", "kind": "review_comment", "who": "danielabrozzoni", "assoc": "MEMBER", "path": "src/rpc/blockchain.cpp", "commit": "cf5d5b9533e182c2e01b165160edbd09ad5d1ef9", "in_reply_to": null, "text": "I think this is fine for the first implementation, but do you think that in the future we could be smarter and decide the height by ourselves, without the user specifying it? Based on what we have in chainparams, or what we see in utxosetinfo" }, { "t": "2026-04-29T17:02:12Z", "kind": "review_comment", "who": "danielabrozzoni", "assoc": "MEMBER", "path": "src/node/utxo_set_share.cpp", "commit": "cf5d5b9533e182c2e01b165160edbd09ad5d1ef9", "in_reply_to": null, "text": "@andrewtoth said:\n[quoted text omitted]\n\nYes, I think right now if a peer sends us a `utxosetinfo` with the wrong data length, we would record it and never notice the mistake, since we are currently only processing the first `utxosetinfo` message that we receive that contains the `merkle_root` we're interested in (we switch to `DOWNLOADING` state in L268)" }, { "t": "2026-04-30T16:45:53Z", "kind": "review", "who": "danielabrozzoni", "assoc": "MEMBER", "state": "COMMENTED", "commit": "cf5d5b9533e182c2e01b165160edbd09ad5d1ef9", "text": "Concept ACK!\n\nI'm slowly going through the BIP and the code, haven't tested yet :) I left a couple of questions." }, { "t": "2026-04-30T16:50:16Z", "kind": "review_comment", "who": "andrewtoth", "assoc": "CONTRIBUTOR", "path": "src/node/utxo_set_share.cpp", "commit": "cf5d5b9533e182c2e01b165160edbd09ad5d1ef9", "in_reply_to": 3162786292, "text": "It's also a little worse than that currently, maybe I wasn't clear. If they specify a size of say 10 petabytes (or just uint64 max) then the receiving node will allocate 60 GB or more just to track the chunks. So immediate OOM DoS by a malicious server." }, { "t": "2026-05-05T16:44:26Z", "kind": "comment", "who": "evoskuil", "assoc": "NONE", "text": "Concept NACK. One is free to add trust vectors to his own node implementation. Shoving that into the p2p network is not acceptable." }, { "t": "2026-05-05T22:57:51Z", "kind": "comment", "who": "fjahr", "assoc": "CONTRIBUTOR", "text": "Temporarily moving this to draft status since it's out of sync with the latest version of the BIP and I will need a few days until I can get to it catch up the code." }, { "t": "2026-05-06T14:53:15Z", "kind": "comment", "who": "eynhaender", "assoc": "NONE", "text": "Concept NACK\n\nThis PR violates \"don't trust, verify\" by introducing a new protocol-level dependency on trusted, hardcoded data (Merkle roots in chainparams) for accepting a UTXO set snapshot from untrusted P2P peers." }, { "t": "2026-05-13T12:52:18Z", "kind": "review_comment", "who": "stickies-v", "assoc": "CONTRIBUTOR", "path": "src/rpc/blockchain.cpp", "commit": "cf5d5b9533e182c2e01b165160edbd09ad5d1ef9", "in_reply_to": 3162547283, "text": "This parameter confuses me. Don't we only allow the specific hardcoded `CChainParams::m_assumeutxo_data::hash_serialized` to be activated? Then why allow the user to specify block height?" }, { "t": "2026-05-13T13:05:11Z", "kind": "comment", "who": "l0rinc", "assoc": "CONTRIBUTOR", "text": "I'm also leaning towards a concept NACK, I'd rather see a proposal to completely remove assumeUTXO from our codebase. Barely anyone uses it (I'm one of the torrent seeders), it downloads more total data than a normal IBD, and the dual chainstate complicates every code path that touches validation - reorgs, wallet rescanning, pruning, the `*DANGER` suffixed methods. All for a short-lived security downgrade that users may not even realize they're operating under. Adding P2P distribution on top makes this even more complex without addressing the fundamental issues." }, { "t": "2026-05-13T13:24:40Z", "kind": "review", "who": "stickies-v", "assoc": "CONTRIBUTOR", "state": "COMMENTED", "commit": "cf5d5b9533e182c2e01b165160edbd09ad5d1ef9", "text": "I'm increasingly convinced that AssumeUTXO and having multiple chainstates was directionally a mistake for this project. It adds a ton of validation complexity, and the benefits to me seem limited. It also seems like more of a wallet than a node concern.\n\nFor that reason, I'm Concept NACK any changes that add more AssumeUTXO complexity." }, { "t": "2026-05-16T21:52:51Z", "kind": "comment", "who": "fjahr", "assoc": "CONTRIBUTOR", "text": "@evoskuil @eynhaender Your NACKs are noted but I think your critique is better addressed by [my responses on the mailing list](https://groups.google.com/g/bitcoindev/c/rThmyI8ZN3Q?pli=1). I would like to keep the conversation here focussed on the code being added here and it's impact on the code base. If you disagree and have specific critique based on the code here please continue to respond here, of course." }, { "t": "2026-05-16T22:08:45Z", "kind": "comment", "who": "fjahr", "assoc": "CONTRIBUTOR", "text": "@l0rinc @stickies-v\n\nThanks for sharing your thoughts. You make almost identical points, so I will respond to you both together.\n\n[quoted text omitted]\nI don't think the torrent seeders are a good indication for usage but certainly it isn't where we hoped it would be when we added the support for it. This proposal addresses that, projects like prepackaged nodes and BTCPayServer have had AssumeUTXO on their wishlists for a long time but since implementation was much harder without this change, they have kept pushing it back.\n\n[quoted text omitted]\nI would say this was probably true when the initial assumeutxo PR was merged. But since then a ton of cleanup has been done and I find the current state of the assumeutxo code quite easy to reason about. Can you point at specific projects or PRs that have been slowed down by assumeutxo being present in the project?\n\n[quoted text omitted]\nEven if assumeutxo adds notable complexity to this project's other code paths this PR certainly does not make it worse. This is the most self-contained piece of code I have ever worked on in Bitcoin Core I think. It barely touches any other lines of code outside of what it adds.\n\n[quoted text omitted]\n@stickies-v Can you explain how a wallet would implement this?\n\n[quoted text omitted]\n@l0rinc Please provide evidence for this claim.\n\n[quoted text omitted]\n@l0rinc What are \"the fundamental issues\"?" }, { "t": "2026-05-18T14:04:41Z", "kind": "comment", "who": "danielabrozzoni", "assoc": "MEMBER", "text": "Expanding a little bit on my initial concept ACK:\n\nI think assumeutxo is a useful feature, and sharing the UTXO set over p2p makes the UX more intuitive, since users don't need to get it through external channels.\n\nThat said, I think it's more important to work on ways to speed up initial IBD, like SwiftSync. I'm also wondering how many contributors see these two projects as competing with each other: maybe we can realistically have one but not the other, because supporting both would make the validation code too complex and spread contributor time too thin.\n\nSo my concept ACK was a bit uninformed. It was more like: \"I really like the idea in theory, but I don't know whether this should be the direction the project takes\"\n\n[quoted text omitted]\nI wonder why this is the case!\n- Is it simply not a well-known feature among users? I honestly didn't know that assumeutxo was already merged in Bitcoin Core until a few months ago, and I found out only because I saw some assumeutxo PRs :sweat_smile:\n- Maybe it seems dangerous to download utxoset from torrent?\n- A lot of users I know run Bitcoin Core together with an Electrum server, so they can use Sparrow or Electrum as wallets. IIUC, you need to complete full IBD before the Electrum server is usable, so maybe assumeutxo just isn't useful for many of them." }, { "t": "2026-05-18T15:59:24Z", "kind": "comment", "who": "stickies-v", "assoc": "CONTRIBUTOR", "text": "[quoted text omitted]\n\nIn my experience, many PRs involving validation logic are made more complex simply by having to reason about multiple chainstates, e.g. [this](https://github.com/bitcoin/bitcoin/pull/34521#pullrequestreview-3761920357) is the most recent example that comes to mind.\n\nIt's also generally slowing down kernel development, for example forcing us to expose the `ChainstateManager` in the interface until further [(non-trivial) decoupling work](https://github.com/sedited/bitcoin/commits/chainmansplit/) is completed. (I recognize that the historical AssumeUTXO work probably also improved certain aspects wrt increased decoupling etc).\n\nI recently came across [this branch](https://github.com/josibake/bitcoin/tree/nuke-assumeutxo) that removes AssumeUTXO. I didn't author it and I presume it's not heavily reviewed / may be incorrect, but glossing over it it seems directionally correct and I think it again highlights how AssumeUTXO is a significant code patch, still affecting lots of critical code. If we prioritize avoiding consensus failure, making consensus code trivial to understand by current and future contributors is an important step.\n\n[quoted text omitted]\nLet a new user get started quickly with increased trust assumptions, by e.g. running an SPV node or trust (a quorum of) third parties with clear disclaimers until the full node has fully validated. Obviously, I would prefer users to be able to use a full node as soon as possible, my point is that I think the current set of trade-offs for AssumeUTXO don't make sense. I'm not against the concept of AssumeUTXO, I think it's reasonable to let users choose to make certain trade-offs for e.g. faster startup times. However, I don't think it's wise to add this much code complexity to do so, especially when it can be handled by higher-level layers in ways that make sense for the use case." }, { "t": "2026-05-19T10:46:37Z", "kind": "comment", "who": "josibake", "assoc": "MEMBER", "text": "[quoted text omitted]\n\nWhy aren't torrent seeders a good indication of usage? And the fact that usage isn't where we hoped it would be is a metric that should be seriously considered before building further on the project. \"People aren't using it because its not distributed via p2p\" seems like a bit of a leap to me. As I mentioned on the mailing list, why can't prepackaged nodes just ship the snapshots directly, provide them via their websites, or get them via bitcoincore.org?" }, { "t": "2026-05-19T11:07:49Z", "kind": "comment", "who": "fjahr", "assoc": "CONTRIBUTOR", "text": "[quoted text omitted]\n\nBecause it would require projects like prepackaged nodes to add Torrenting as a dependency to their nodes, which seems like a terrible idea to me and I don't think it's something they are interested in doing.\n\n[quoted text omitted]\nI haven't seen a response from you on the ML but this is what BTCPayServer has been doing with FastSync for example. But of course we would like them to not do that but rather use assumeutxo because it is safer. The projects I have spoken with say that have it high on their wishlist but they were just not able to get to it yet." }, { "t": "2026-05-19T11:20:41Z", "kind": "comment", "who": "josibake", "assoc": "MEMBER", "text": "[quoted text omitted]\n\nThis feels like a very subjective response to me. If people really *needed* assumeutxo, as in it was solving a real problem for them, I would expect people to use whatever means are available to them. That then creates momentum to further support the project. It seems like the opposite is happening: no one is using it, and we keep building on it trying to get people to use it.\n\n[quoted text omitted]\nLikely still pending. But I don't understand how this is safer? BTCPayServer gets a snapshot, likely from a fully validating node they own? This seems safer, trust wise, than getting it from the p2p network to then be compared against a hash they did not create. But regardless, we already have a hash snapshot in the binary, why can't BTCPayServer just download the snapshot from bitcoincore.org? If it doesn't match the hash in the binary, they don't use it. This is exactly the same trust model you are proposing here, without requiring us to change our p2p code." }, { "t": "2026-05-19T13:53:24Z", "kind": "comment", "who": "l0rinc", "assoc": "CONTRIBUTOR", "text": "First, I want to separate a few things: I appreciate the work @fjahr is doing here, and I think the implementation itself looks careful and very well done. I also agree that startup cost is a real problem - it is why I have been working full time on validation optimizations for years.\nI also do not think `assumeUTXO` is useless: I use it all the time for benchmarking serialization and UTXO-set related code - even if that use case is not enough to justify the feature by itself.\n\nMy objection is that `assumeUTXO` makes the most critical part of the codebase harder to read and reason about, and this PR extends that model further. That is the part I do not think is justified. It looks like sunk cost reasoning: we added `assumeUTXO`, usage is not where we hoped, and now we keep adding the next missing piece hoping this one will finally make it broadly adopted.\n\nConcrete examples, since you asked:\n\n* In https://github.com/bitcoin/bitcoin/pull/32975#discussion_r2263730260, a simple `assumevalid` logging change became chainstate-specific. A global/static state would have produced confusing output with `assumeUTXO`, because one chainstate can be validating new blocks while the background chainstate is still in IBD. The end result was that, for simplicity, warnings are not generated during `assumeUTXO`.\n* https://github.com/bitcoin/bitcoin/pull/31703#pullrequestreview-2566967750 is another example. Pieter's PR was not primarily about `assumeUTXO`, but it exposed an `assumeUTXO`-specific path where the warning did not trigger the way I expected. Pieter was focused on the main change rather than the snapshot-specific path, so I ended up taking over the `assumeUTXO` part to make sure the warning covered that path as well. This blocked the review path for months.\n* https://github.com/bitcoin/bitcoin/pull/34521#pullrequestreview-3761920357 was an ordinary UB fix in `LoadChainTip`, but review found an extra issue because `assumeUTXO` can have two `Chainstate`s, each with its own `setBlockIndexCandidates`. That is not theoretical complexity; it affected a concrete validation PR.\n* https://github.com/bitcoin/bitcoin/pull/33259 is a user-facing example. `getblockchaininfo` could report `verificationprogress=1` and `initialblockdownload=false` while background validation was still running. That required adding explicit `backgroundvalidation` state.\n* https://github.com/bitcoin/bitcoin/pull/28598 and https://github.com/bitcoin/bitcoin/pull/28616 show the same issue from the wallet side. We had to be careful not to present transactions as normally confirmed while background validation was incomplete.\n* https://github.com/bitcoin/bitcoin/issues/32029#issuecomment-2714449973 is another example of this being confusing even to developers. After a snapshot had supposedly been fully validated, I expected all traces of `assumeUTXO` seeding to be gone, but restart behavior still looked `assumeUTXO`-specific.\n* https://github.com/bitcoin/bitcoin/issues/32377#issuecomment-2851395816 is related too. If we want the baked-in snapshot hashes to be more defensible, we could theoretically harden them by checking the committed `assumeUTXO` values during normal IBD/reindex/reindex-chainstate as well. That would make the commitments less one-sided. But that idea did not get much traction. So we are adding more functionality on top of these commitments before doing the obvious consistency checks during ordinary validation.\n\nNone of these are catastrophic individually. The problem is that the complexity accumulates in validation-adjacent code, where readability and reviewer confidence matter most.\n\nOn the claim that users may not realize the temporary security downgrade: the evidence is not a user study. The evidence is that we already needed extra RPC and wallet state to avoid misleading users and developers. Before background validation finishes, the node is in a confusing dual state: it is validating current transactions on top of an assumed base state, while we still cannot say that this node has independently validated that base state. That may be an acceptable tradeoff for some users, but it is not the same security model as a normally synced full node.\n\nSo when I say \"fundamental issues\", I mean:\n\n* The node is temporarily operating in a weird partial-validation state: it is not providing the same security as a normally synced full node until background validation completes.\n* The dual-chainstate model has a continuing maintenance cost in validation-adjacent code.\n* Demand still seems weak relative to the complexity. Torrent usage may not be a perfect metric, but it is a smell.\n* This does not solve the bandwidth- or CPU-constrained cases in the way it is sometimes presented. If background validation completes, the user still downloads the UTXO snapshot plus historical blocks, so total bandwidth is higher than normal IBD. For CPU-constrained users, moving validation to the background does not remove the work. It just makes the node usable earlier under an assumption. But you all know this.\n\nIf the gain is mostly that a normal node avoids waiting overnight, I do not think that justifies extending this model further into P2P and chainparams. If the user is genuinely CPU- or bandwidth-starved, then the historical work still takes a long time in the background, and the user remains in this purgatory state during that period.\n\nFor a bandwidth-constrained user, downloading no UTXO set is better than downloading a multi-GB UTXO set. For a CPU-constrained user, putting the CPU work in the background does not remove it. If the problem is really the UTXO set or the cost of keeping state, then UTXO-less or accumulator-based experiments such as Utreexo seem like a cleaner direction to explore. They have their own tradeoffs, but they attack the state problem directly instead of adding P2P transport for assumed state blobs.\n\nMy objection is to extending `assumeUTXO` further into P2P and chainparams because I do not see why `assumeUTXO` is the right solution to that problem. I would rather see it removed and provided as an external service; I do not think it is \"Core\"." }, { "t": "2026-05-19T20:05:28Z", "kind": "comment", "who": "fjahr", "assoc": "CONTRIBUTOR", "text": "@josibake\n\n[quoted text omitted]\nThat is not the case, and I don't think such exaggerations are helpful for the discourse.\n\nSome prepackaged nodes or node setups do use it:\nhttps://github.com/Start9Labs/bitcoin-core-startos/blob/31.x/README.md\nhttps://github.com/FreeOnlineUser/bitcoin-pocket-node#-path-3-download-from-internet-assumeutxo-3-6-hours\n\nAnd there is quite some educational content available as well:\nhttps://blog.lopp.net/bitcoin-node-sync-with-utxo-snapshots/\n\"Sync your full node in an hour\" workshop @ https://btcplusplus.dev/ba24/talks\nhttps://yourdevice.ch/fullnode-schneller-syncen-mit-utxo-snapshots/\n\nSo I do think there is clear evidence that it is used, but it could be used more, and part of the barrier is the sourcing hoop that users have to jump through, which is the very thing this PR tries to fix. We don't have any telemetry on Bitcoin Core so the \"nobody uses it\" claim can probably be made about 90% of user-facing features that are not signaled on the network itself.\n\nI don't think this line of arguing will lead anywhere. If I showed evidence of more usage, you would simply flip your argument that this is evidence the change isn't needed because adoption is good enough. There will be no usage statistic that will convince you that this change is warranted.\n\nWhat actually matters in terms of usage is the following: Adoption could be better, and lowering the barrier for its usage will undoubtedly have a positive impact on it. Whether that justifies adding a sizable chunk of code (while very self-contained) is the question reviewers have to decide on. I am rather focused on the conditions that people try to set up nodes in and struggle with long IBD wait times and what AssumeUTXO could do for them if it were more accessible to them.\n\n[quoted text omitted]\nYou think an unverified utxo set dump from a single HTTP server, where it's unclear how safe it is, who hosts it, and who has access, is safer than this proposal? You also want their users to get the actual bitcoin core release build and verify the signatures, right? Not some custom bitcoin core build from BTCPayServer.\n\nThere are several websites that provide snapshots if you are looking for a centralized provider, by the way:\nhttps://bitcoin-snapshots.jaonoctus.dev/\nhttps://utxo.download/\n\nI would rather not send users to a centrally hosted server where they only know if the snapshot is valid when they have already loaded it into Bitcoin Core.\n\n[quoted text omitted]\nBecause bitcoincore.org doesn't host the snapshot. And I don't think we want to do that because it's another server we have to maintain, a centralizing entity and a single source of failure. But if this is something you would like to pursue as an alternative approach to help adoption of AssumeUTXO, of course you can. To me personally, this seems like a lot more work than maintaining the code I am proposing here." }, { "t": "2026-05-19T23:30:51Z", "kind": "comment", "who": "yancyribbens", "assoc": "CONTRIBUTOR", "text": "[quoted text omitted]\n\nWhy would that be the case? Even if true, it could easily be https/ssh/ftps or other encrypted internal mechanism, possibly even distributed." }, { "t": "2026-05-20T16:47:06Z", "kind": "comment", "who": "narula", "assoc": "CONTRIBUTOR", "text": "Concept NACK, for the same reasons @l0rinc has articulated very well here: https://github.com/bitcoin/bitcoin/pull/35054#issuecomment-4488453829\n\nside note: I wonder if there are concrete suggestions for how one might better collect this reasoning before doing a lot of work on a feature that many don't highly prioritize, and which has real code complexity impact." }, { "t": "2026-05-20T19:14:37Z", "kind": "comment", "who": "sipa", "assoc": "MEMBER", "text": "Before venturing into a general concept ack or nack, I want to offer a perspective on a different path forward. I don't know what the right path is, but framing it this way may help us figure out where fundamental costs/benefits lie.\n\nI want to start with two viewpoints I haven't often seen in this debate:\n\n* **P2P sync is a fundamental part of assumeutxo**. We cannot judge usefulness, interest, or adoption, of assumeutxo without P2P sync. assumeutxo is an optimization whose intention is lowering the bar for users to have fully validating nodes. As such, it competes *through ease of use* with alternatives that have worse trust assumptions, such as lightweight validation, and just downloading a precreated chainstate directory from a possibly unreliable trusted source. Without P2P sync, the user experience of assumeUTXO doesn't compare with those alternatives, and it entirely unsurprising that it is not used widely. It needs to work out of the box, or we shouldn't have it at all.\n\n* **Background re-validation is an anti-feature**. From the perspective of an end user, who is already trusting the software and the process that got it to them, the assumeutxo hash in the code is trusted already (because if it isn't, then that process might equally well remove critical consensus checks in validation code). They are *not* operating in a reduced partial level of validation before background re-validation is complete. The background re-validation adds a huge amount of bandwidth and processing, and simultaneously complicates our validation code significantly. It's there to keep the process honest, which all things equal is a good thing, but it's very bizarre to burden the users with what is effectively an extremely expensive mandatory self-check of the software they already trust.\n\nSo my question is: if we had the option of a assumeutxo *with* P2P sync, but *without* background re-validation, would that tilt the scales for commenters here, in one way or the other? The reduction in bandwidth, computation, and validation code complexity may make it more appealing. The fact that it intricately exposes how critically reliant on review the assumeutxo hash is (like all the rest of the code) may make it less appealing (and if it does to you, that's probably an argument against assumeutxo in the first place).\n\nNote that while I believe there is no categorical difference in trust assumptions between trusting the code and trusting the assumeutxo hash, that does not make them equal in all regards, and does not mean they should be equally acceptable to everyone. For one, the cost of review of the assumeutxo hash has a very different cost profile (need to sync a node without assumeutxo). Another is that from a trust minimization perspective, a need to trust the (process around) code is inevitable, while trust in a trust anchor for assumeutxo is not. Yet another one is education, because it makes it unclear to users (and developers, see this thread and the one on the ML...) what the trust assumptions exactly are.\n\n**Regarding synchronization off bitcoincore.org instead of P2P**: I really like that from an education perspective, as it aligns the data source with the trust assumptions. However, it is also completely unacceptable for other reasons, like DoS risks and logistics of operating the infrastructure." }, { "t": "2026-05-20T20:31:39Z", "kind": "comment", "who": "evoskuil", "assoc": "NONE", "text": "[quoted text omitted]\n\nIt may be the intention, but it is not the reality. As has been pointed out here, it increases this cost.\n\n[quoted text omitted]\nThe attempt to re-brand not validating as \"re-validating\" is noted.\n\nAssume utxo operates under the exact same security model as SPV, with notable deficiencies.\n\n1. startup cost is much higher (big download).\n2. wallet complexity is pushed into nodes (e.g. dual chainstate, see thread).\n3. inclusion proofs are not available for any tx supposedly confirmed within the assumption window.\n4. trust must be established in the assumption in order to prevent very costly DoS.\n5. degrades the formerly trustless p2p network.\n\nIt has been anticipated for many years that degrading performance would lead to these exact calls to abandon validation. If the argument is now that trust-me-bro is sufficient because you need to trust the software anyway, this project has failed." }, { "t": "2026-05-20T20:41:43Z", "kind": "comment", "who": "stickies-v", "assoc": "CONTRIBUTOR", "text": "[quoted text omitted]\n\nI wonder if most users who are (or would be) interested in AssumeUTXO install Bitcoin Core directly, or through node management software (Umbrel, etc) that focus on one-click install (and/or hardware to go along with it). I kinda suspect it'd be the latter, as the focus there is on gaining convenience at the cost of increased trust assumptions? If so, then I'm not sure your statement is true: node management software can easily hide the overhead of downloading the txoutset (e.g. from their website)? _(Of course, they could already achieve something similar by e.g. shipping datadirs, )_\n\n[quoted text omitted]\nI could be open to keeping AssumeUTXO without background sync around (depending on remaining complexity, and user demand), so it'd definitely tilt the scales somewhat more positive for me. However, I think I still would not support adding p2p set sharing to Bitcoin Core. In my view, people running fully validated full nodes should remain the default, and I don't think we need to go out of our way to facilitate the alternative. However, I would not strongly oppose it if there is widespread support amongst contributors and demand from users." }, { "t": "2026-05-20T21:33:42Z", "kind": "comment", "who": "sipa", "assoc": "MEMBER", "text": "[quoted text omitted]\n\nI agree. However, I believe that most of that added cost is due to background validation of chain prior to the pre-assumeutxo sync point.\n\n[quoted text omitted]\nI refer to the current approach of background validation of the chain prior to the pre-assumeutxo sync point as re-validation, because it is validating something that is already trusted to be correct anyway. I am arguing for - at least as a thought experiment - dropping that re-validation. That indeed means not validating it.\n\n[quoted text omitted]\nI don't see how. SPV is trusting hashrate majority to commit to a consensus-valid chain. Assumeutxo is trusting the development, review, and distribution process of the software you are using to only commit to a utxo set matching a particular block hash. Note that I am not claiming that that makes it a better (or worse) idea, just that categorically it belongs to the class of software-review assumptions and not hashrate assumptions.\n\n[quoted text omitted]\nWith re-validation, yes. Without it, it's replacing the pre-assumeutxo part of the chain with just its UTXO set.\n\n[quoted text omitted]\nThe dual chainstate is only there for re-validation. I am suggesting not doing that.\n\n[quoted text omitted]\nThat seems like an implementation aspect. Nothing prevents using similar techniques as SPV for transactions in the window if the user cares about them (filtering, inclusion proofs w.r.t. to the known and assumed-correct chain).\n\n[quoted text omitted]\nIndeed.\n\n[quoted text omitted]\nThe network is neutral in this regard. Many features of the network can be used in ways that minimize trust or not. For example, one can download blocks from an arbitrary node without any validation whatsoever. Or one can trust the hashrate majority like SPV does. Other features, like IP address relay are fundamentally unverifiable information to begin with, because there is no better option.\n\nTrustlessness is a property of the node software, not the network it connects to. Individual nodes participating in behavior that you find objectionable in no way degrades the usefulness of the network to you, as long as there are no compatibility issues.\n\nLet me be clear that I value your opinion and the discussion about the assumeutxo feature here. There are many interesting points to be made about its trust assumptions, engineering tradeoffs, and overall usefulness. However, this one in particular seems like a bizarre purity argument, and I don't think it has a place in a technical debate.\n\n[quoted text omitted]\nAssumeutxo is a pragmatic trade-off that exchanges validation time for a trust assumption, period. This is a trade-off that people are already making, and have been making forever, in the form of offering pre-packaged chainstates. This is what motivated assumeutxo in the first place, because having the utxo set hash reviewed by the same process you are already trusting for getting the consensus code implementation correct is better than having to additionally also trust j.random.website.com. And it's in my view - though I suspect you may disagree - also better than using a permanently lighter weight validation mode.\n\nIt's entirely fair to dislike the fact that people make such trade-offs, but they are, and I don't think dislike for reality is a reason to argue against an improvement of the status quo. There are however many other arguments against assumeutxo, like engineering costs and improvements to the state of the art in validation that don't need assumptions. I also listed others above, including the confusion about security assumptions it causes. I think getting rid of the background re-validation actually improves upon that, by ripping off the facade that makes it seem like something better than a trusted hash in the source code. I would have thought you'd appreciate that, actually." }, { "t": "2026-05-20T22:48:03Z", "kind": "comment", "who": "evoskuil", "assoc": "NONE", "text": "[quoted text omitted]\n\n[quoted text omitted]\nI don't see how that is relevant.\n\n[quoted text omitted]\n\"validating something that is already trusted to be correct anyway\"\n\nTrusted is not validated. You may be aware of the phrase, \"don't trust, validate.\"\n\n[quoted text omitted]\nInclusion of a tx is the only aspect of the design that is validating, exactly as with SPV. The author has made this specific argument on [bitcoin-dev](https://groups.google.com/g/bitcoindev/c/rThmyI8ZN3Q/m/CGGtqsUZCQAJ) that this is why it's secure.\n\n\"An incoming payment can only be confirmed in a mined block on the headers-validated chain. For an attacker to trick the user into accepting a transaction that spends UTXOs which exist only in a malicious snapshot, the majority of mining hashpower would have to be running nodes that accepted and continued to run based only on the same malicious snapshot.\" - Fabian\n\n[quoted text omitted]\nWhen we refer to security we are specifically not referring to trust. The *security* of this feature (as Fabian describes above) is SPV. Beyond that there is *trust*. We can wax philosophical about the need to trust the software, but if one accepts this argument - the project has failed.\n\n[quoted text omitted]\nLet's not be pedantic. The proposal enlists the P2P network into the distribution of multi-gigabyte blobs that cannot be validated without validating the entire chain.\n\n[quoted text omitted]\nThis statement justifies any imaginable use of the P2P network on the basis that others can ignore it. This is not a serious argument when the specific question is what should or should not be standardized network behavior.\n\n[quoted text omitted]\nPeriod or not, engineering tradeoffs have consequences.\n\n[quoted text omitted]\nThis restates my summary of what you previously said. I don't see any reason to keep repeating it.\n\nBitcoin is based on a simple principle - validation. If you don't want to validate, and instead just trust the bros (who might as well just be j.random.website.com), you do not have to. But standardizing that as a matter of protocol is inherently broken.\n\n[quoted text omitted]\nThis is NOT a stronger \"validation mode\". It is the SPV validation mode. There are only two actual modes of Bitcoin validation, and it has been that way since the paper. You are arguing for the permanent use of one as if it was the other. To think we all fought against these arguments a decade ago.\n\nFurthermore it's more costly, and requires a *to-be-determined* trust chain, from [bitcoin-dev](https://groups.google.com/g/bitcoindev/c/rThmyI8ZN3Q/m/CGGtqsUZCQAJ):\n\n\"The BIP intentionally leaves the source of the Merkle root to the implementation. The protocol's job is to enable transferring and verifying UTXO data once a root is known, not to dictate how each implementation establishes that root.\" - Fabian\n\n[quoted text omitted]\nDo not put words in my mouth. I never expressed any dislike for such tradeoffs. I rejected flawed arguments and standardizing this into the P2P protocol. You may have noticed that I pointed out that people already widely utilize SPV (which we support via a native electrum interface).\n\n[quoted text omitted]\nI do appreciate the fact that someone is finally being honest about the intent. Just 13 days ago on [bitcoin-dev](https://groups.google.com/g/bitcoindev/c/rThmyI8ZN3Q/m/V6FH_RcyAgAJ) there was a rejection of the slippery slope argument, made by the author:\n\n\"I can not refute critique of something that is not part of this proposal except for pointing out that what you are insinuating is not something I am working on or plan on working on and *I am not aware of anyone working on skipping IBD and I would not endorse such a proposal if it were to be published*. In contrast to some hypothetical dangerous future extension of this proposal that you are warning about, I am convinced that it does have real positive impact on users today, as I pointed out above.\" - Fabian\n\nDidn't even take 2 weeks." }, { "t": "2026-05-24T23:34:13Z", "kind": "comment", "who": "fjahr", "assoc": "CONTRIBUTOR", "text": "So, @evoskuil is already getting anxious on the mailing list that I haven\u2019t posted my view here again in the context of @sipa 's suggestion, despite himself making sure that my opinion is already present here by quoting me. Last time I checked, not posting didn\u2019t mean that one\u2019s opinion has quietly taken a 180, but that\u2019s where this conversation is now, I guess.\n\nTo make it clear again and prevent him from continuing to put words into my mouth, I don\u2019t find AssumeUTXO interesting if we don\u2019t fully validate IBD in the background. As I have said several times already, I find it an interesting feature to make it quicker and easier to get started with running a full node. This is in particular contrast to losing users to custodial solutions more and more. It takes the time it takes to run IBD out of the equation, and this has been made clear to me by many people I spoke with back when AssumeUTXO was actually implemented: that this would be useful in convincing merchants to run their own full nodes and to get people set up with pre-packaged full node projects and setup tutorials through a much nicer experience, for example. These effects are reinforced in the typical circumstances found in developing regions. If AssumeUTXO turns into a pruned-only feature without full background sync, I don\u2019t think that\u2019s valuable because that\u2019s not what the users I am thinking of actually want." }, { "t": "2026-05-25T00:16:04Z", "kind": "comment", "who": "nkaretnikov", "assoc": "NONE", "text": "Concept NACK.\n\nFirst, people disagree on the adoption rate of assumeUTXO, which this proposal builds on. So the usefulness of the proposal is also in question.\n\nIt was said that users are not using torrents, which is the closest existing thing to including this into the P2P network. So this must either not be used at all or they just download data from a different source. If this is not used, then no proposal is needed. If they use a different data source, then the solution already exists. But somehow the counterargument to that is that users are using untrusted sources. However, the BIP doesn\u2019t address the trust argument, it just changes the distribution method.\n\nOn adoption: including this into the P2P network also doesn\u2019t automatically help with adoption because the proposal is opt-in. Someone has to volunteer to publish the data first, and why would they if there is a simpler way of solving this?\n\nWith all that uncertainty, this proposal comes with a bunch of concrete downsides: trust assumptions, implementation complexity leading to longer reviews and potential bugs, data usage.\n\nFinally, I wish more projects followed OpenBSD\u2019s lead and actively removed unused code. So I would encourage removing assumeUTXO support if it\u2019s not useful, because almost always more code means more bugs." }, { "t": "2026-05-25T00:58:28Z", "kind": "comment", "who": "evoskuil", "assoc": "NONE", "text": "[quoted text omitted]\n\nYou favorably referenced the very post that proposed exactly what you had dismissed to me as a \"slippery slope\" argument, without so much as mentioning that you didn't support it. That's called implicit support in any universe.\n\nSo now, despite the fact that we slipped all the way down that slope in less than two weeks, I see that above you at least \"don't find that valuable\". That's great to hear.\n\nYou are welcome to do it in your node, but this is not something that should be even jokingly considered for protocol standardization by the community." }, { "t": "2026-05-28T09:34:20Z", "kind": "comment", "who": "josibake", "assoc": "MEMBER", "text": "I realise this PR has now drifted to a more general discussion of AssumeUTXO, but I'd prefer to respond here as this is where the relevant points I want to respond to are. I am also happy to continue this discussion in another place, if that is deemed more appropriate.\n\nTo start off, I realise I jumped in hastily before without fully letting my thoughts marinate. I had a strong reaction to the P2P proposal not because I think this change in isolation is a bad proposal, but rather because I think that AssumeUTXO is a bad proposal and adding the P2P mechanism on top of it is building on an unsound foundation. Apologies for not clearly articulating my point of view.\n\nI do agree with @sipa 's point that P2P is necessary for AssumeUTXO to compete with \"less good\" alternatives. But to me, this feels like the tail wagging the dog. I do not think we should be designing features to compete with users doing a \"bad thing.\" We should be designing features that are technically sound and ideologically aligned with the goals of this project.\n\nThe two main reasons I've seen given for AssumeUTXO (I'm not commenting on whether or not I think they are good reasons, only that they seem to be the most commonly quoted) are full IBD is slow and/or full IBD is too much data.\n\nFor slow IBD, I think we are nowhere near the limit and have plenty more work to do towards optimising this. @evoskuil 's libbitcoin-node is a testament to this. I applaud the efforts of the developers who have been doing work in this area. It is my personal view that this are of work is of utmost importance if we expect people to run their own nodes.\n\nFor bandwidth concerns, I think this is an area where more work can be done, as well. Some time ago there was a proposal for witness pruning which claimed something on the order of 40% bandwidth savings and a trust model that I consider vastly superior to AssumeUTXO. There has also been some discussion on block and transaction encodings (though I am less familiar with this area).\n\nI have mentioned several times in the past that I think these areas need to be explored more seriously before considering things like AssumeUTXO. I also am not fully convinced having users bootstrap from an unverified hash is the same as trusting the code of the node software. It seems easier to me to have a malicious hash introduced while leaving the majority of the critical code untouched, vs modifying consensus code to produce a malicious UTXO set whilst escaping detection.\n\nRegardless, I think my main point is there is still plenty of work on the table to make full verification optimised and viable for the most number of users." }, { "t": "2026-05-28T21:23:30Z", "kind": "comment", "who": "yancyribbens", "assoc": "CONTRIBUTOR", "text": "[quoted text omitted]\n\nThis to me is the elephant in the room. Would you feel the same way if the node software was from a different source? For example, it's now possible to run alternate node implementations using the kernel lib. And in such a case, what would your level of trust be then?" }, { "t": "2026-06-05T07:20:43Z", "kind": "comment", "who": "ajtowns", "assoc": "CONTRIBUTOR", "text": "[quoted text omitted]\n\nI think this PR is pretty clearly aimed at \"make AssumeUTXO more useful\", and that a conversation about \"AssumeUTXO is actively harmful and shouldn't be supported\" should be held elsewhere (eg on the mailing list if you want to discourage users from using it, or as a new issue if you think it should not even be a supported option).\n\nWhile we have AssumeUTXO in the codebase, I think having PRs that make it more useful is a good thing.\n\n[quoted text omitted]\nI don't think this is actually very expensive form a user's point-of-view -- it's just a bunch of extra processing happening in the background that doesn't delay them from using their node, which is fine unless their node is very resource constrained. It is somewhat expensive from a development/maintenance POV, but if the feature's useful, that can be okay.\n\nI think the self check is fairly valuable for keeping everyone honest. We could probably simplify the code by changing the way we do it though: eg, running the check-from-genesis as a separate process with separate p2p connections and a separate debug.log, then, if we reach the target block and end up with a different utxo set, just abort and display an error with recovery instructions, rather than doing an automatic reorg. (In that model, perhaps you could request a utxo-snapshot-set-revalidation at arbitrary times when you switch to new node software, even if you're not using assumeutxo yourself, making the \"self-test\" behaviour more widely available)" } ], "labels_log": [ { "t": "2026-04-10T21:58:57Z", "action": "labeled", "label": "P2P", "who": "DrahtBot" }, { "t": "2026-04-10T22:51:22Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2026-04-25T10:19:55Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" } ], "state_log": [ { "t": "2026-05-05T22:57:23Z", "kind": "convert_to_draft", "who": "fjahr" } ], "text_chars": 46086, "text_tokens_estimate": 11521, "changed_paths": [ "contrib/utxo-tools/utxo_snapshot_merkle.py", "src/CMakeLists.txt", "src/consensus/merkle.cpp", "src/consensus/merkle.h", "src/init.cpp", "src/kernel/chainparams.cpp", "src/kernel/chainparams.h", "src/logging.cpp", "src/logging/categories.h", "src/net_processing.cpp", "src/net_processing.h", "src/node/context.cpp", "src/node/context.h", "src/node/utxo_set_share.cpp", "src/node/utxo_set_share.h", "src/protocol.cpp", "src/protocol.h", "src/rpc/blockchain.cpp", "src/rpc/client.cpp", "src/test/CMakeLists.txt", "src/test/fuzz/rpc.cpp", "src/test/utxo_set_share_tests.cpp", "src/validation.cpp", "test/functional/p2p_utxo_set_share.py", "test/functional/test_framework/messages.py", "test/functional/test_framework/p2p.py", "test/functional/test_runner.py" ], "files": [ { "path": "contrib/utxo-tools/utxo_snapshot_merkle.py", "add": 73, "del": 0 }, { "path": "src/CMakeLists.txt", "add": 1, "del": 0 }, { "path": "src/consensus/merkle.cpp", "add": 1, "del": 1 }, { "path": "src/consensus/merkle.h", "add": 5, "del": 0 }, { "path": "src/init.cpp", "add": 20, "del": 0 }, { "path": "src/kernel/chainparams.cpp", "add": 13, "del": 0 }, { "path": "src/kernel/chainparams.h", "add": 6, "del": 0 }, { "path": "src/logging.cpp", "add": 1, "del": 0 }, { "path": "src/logging/categories.h", "add": 1, "del": 0 }, { "path": "src/net_processing.cpp", "add": 154, "del": 0 }, { "path": "src/net_processing.h", "add": 6, "del": 0 }, { "path": "src/node/context.cpp", "add": 1, "del": 0 }, { "path": "src/node/context.h", "add": 6, "del": 0 }, { "path": "src/node/utxo_set_share.cpp", "add": 434, "del": 0 }, { "path": "src/node/utxo_set_share.h", "add": 193, "del": 0 }, { "path": "src/protocol.cpp", "add": 1, "del": 0 }, { "path": "src/protocol.h", "add": 28, "del": 0 }, { "path": "src/rpc/blockchain.cpp", "add": 70, "del": 0 }, { "path": "src/rpc/client.cpp", "add": 1, "del": 0 }, { "path": "src/test/CMakeLists.txt", "add": 1, "del": 0 }, { "path": "src/test/fuzz/rpc.cpp", "add": 1, "del": 0 }, { "path": "src/test/utxo_set_share_tests.cpp", "add": 377, "del": 0 }, { "path": "src/validation.cpp", "add": 1, "del": 0 }, { "path": "test/functional/p2p_utxo_set_share.py", "add": 190, "del": 0 }, { "path": "test/functional/test_framework/messages.py", "add": 122, "del": 0 }, { "path": "test/functional/test_framework/p2p.py", "add": 6, "del": 0 }, { "path": "test/functional/test_runner.py", "add": 1, "del": 0 } ], "test_lines": 771, "git": { "head": "cf5d5b9533e182c2e01b165160edbd09ad5d1ef9", "head_matches_backup": true, "base": "7c6f1ab654a1a3a77fac24fbb08ba4c619acaa71", "commits": [ { "sha": "350985da5e", "subject": "net: Add NODE_UTXO_SET service bit and message types", "files": 2, "add": 29, "del": 0 }, { "sha": "34fd9f6c3e", "subject": "log: Add UTXOSETSHARE category", "files": 2, "add": 2, "del": 0 }, { "sha": "78969203f5", "subject": "consensus: Expose ComputeMerklePath and add merkle proof verification", "files": 7, "add": 189, "del": 1 }, { "sha": "9a6fd56aea", "subject": "net: Define P2P message serialization for UTXO set sharing", "files": 1, "add": 51, "del": 0 }, { "sha": "d16e35ac62", "subject": "node: Implement UTXO set share provider", "files": 3, "add": 302, "del": 0 }, { "sha": "3f8e5c0dc9", "subject": "init: Scan share folder in datadir for sharable snapshots", "files": 3, "add": 20, "del": 0 }, { "sha": "ef15e22d58", "subject": "net: Handle getutxostinf and getutxoset P2P messages", "files": 2, "add": 65, "del": 0 }, { "sha": "a00eebc6b5", "subject": "node: Implement UTXO set download manager", "files": 3, "add": 379, "del": 0 }, { "sha": "0943ed1f17", "subject": "rpc: Add downloadutxoset RPC", "files": 8, "add": 178, "del": 3 }, { "sha": "0cda5f60a1", "subject": "contrib: Add snapshot merkle root tool", "files": 1, "add": 73, "del": 0 }, { "sha": "b131adeb25", "subject": "net: Validate chunk Merkle root against assumeutxo chain params", "files": 5, "add": 110, "del": 0 }, { "sha": "3fffb9f085", "subject": "test: Add functional test for P2P UTXO set sharing", "files": 4, "add": 319, "del": 0 }, { "sha": "cf5d5b9533", "subject": "chainparams: Add missing snapshot merkle roots", "files": 1, "add": 1, "del": 1 } ], "patch_truncated": true }, "input_hash": "e94a13f2a2954c19", "extracted_at": "2026-09-17T16:15:31+00:00" }