#35054 p2p: UTXO set sharing

ReviewabilityReviewsAgreementSize
#35054 fjahr p2p: UTXO set sharingWaiting on author0 -5Blocked943 + 771 tests
  • Distribute AssumeUTXO snapshots directly over the P2P network instead of requiring out-of-band downloads.
  • Reduces onboarding friction and avoids centralized distribution points for users wanting fast initial sync.
  • Needs rebase and CI is failing.
  • Author has been silent for 146 days.
  • Blocked by unaddressed objections while author has been silent (andrewtoth, narula, josibake, nkaretnikov)
  • Unaddressed objection: peer can cause immediate out-of-memory crash via data length field (andrewtoth)
  • Unaddressed objection: activation failure leaves download manager permanently stuck (andrewtoth)
  • Objections to dual chainstate complexity and unvalidated snapshots in P2P (l0rinc, stickies-v, evoskuil)
  • Tested snapshot download, activation, and background validation on mainnet demo node (svanstaa)
  • 943 lines added or modified outside tests
  • 771 lines added or modified in tests
  • 1 lines removed in total
  • 27 files, 13 commits
P2P#28 of 71
P2 · new feature
  • P2 because it adds in-band snapshot sharing over P2P, significantly reducing node onboarding friction.
  • Introduces wire protocol extensions that require review of new denial-of-service and bandwidth risks.
  • Ranking pass: Benefit is contested by sustained concept opposition, so it sits last among equally banded features.
Ranking notes
RPC / REST / ZMQ#49 of 55
P4 · new feature
  • P4 after comparing with the other PRs here (assessed alone as P3): Lowered to P4 and moved down 16: within rpc its contribution is one new method with no external consumer asking; the substance belongs to p2p.
  • P3 because it adds a new downloadutxoset RPC to trigger snapshot fetching without breaking existing methods.
Ranking notes
Validation#27 of 53
P2 · new feature
  • P2 because it triggers in-process snapshot activation and coordinates with background chainstate validation.
  • Increases maintenance complexity across block reorgs, wallet rescanning, and block pruning.
Ranking notes
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.

Goal

Implements a draft BIP protocol for sharing UTXO set snapshots across the P2P network using chunks verified against a Merkle root. Adds the NODE_UTXO_SET service bit, P2P messages to query and fetch chunks, and a downloadutxoset RPC to trigger asynchronous fetching and snapshot activation.

Problem: Using assumeutxo currently requires acquiring a snapshot file out-of-band through third-party web downloads or torrents, introducing friction and centralized distribution points for users who want fast node onboarding.

Reviewability

Paused · Waiting on author

Open objections from andrewtoth, danielabrozzoni, josibake with no author reply for 15 days; review would repeat what has been asked.

Waiting on (from the thread read):

  • author: addressing open objections and questions regarding DoS vectors and snapshot activation failure 2026-04-12

Agreement

Blocked

objection that needs a change, nobody has replied (andrewtoth, eynhaender, narula, nkaretnikov, josibake)

Thread notes: Added Sjors to participants and support with a Concept ACK regarding P2P AssumeUTXO snapshot sharing.

Objections, suggestions, and questions:

ReviewerTypeHarm, request, or questionStatusMust beAuthor repliedQuote
andrewtoth (member)objection, correctnessdownload manager remains stuck indefinitely in COMPLETE state if snapshot activation failsopenchangedno2026-04-12: 'If ActivateSnapshot fails, download manager is forever in COMPLETE state.'
andrewtoth (member)objection, safetya malicious peer can set data_length in utxosetinfo to an enormous value causing an immediate out-of-memory crash on the receiving nodeopenchangedno2026-04-12: 'Server can set `utxosetinfo`'s `data_length` field to 10 PB, which causes the receiving node to allocate >60 GB immediately.'
andrewtoth (member)objection, interfacewhy invoke an RPC instead of a configuration option that could later be set by defaultopenchangedno2026-04-12: 'Why invoke an RPC, instead of a configuration option (which can be set by default at a later point)?'
danielabrozzoni (member)question, interfacewhether the node could determine snapshot height automatically in the future without requiring user inputopenansweredno2026-04-29: 'do you think that in the future we could be smarter and decide the height by ourselves, without the user specifying it?'
evoskuil (none)objection, approachintroducing trust vectors and unvalidated UTXO blobs into the P2P network undermines trustless verificationcontested · author referred to mailing list replies in c:4468303593; evoskuil continued to oppose in c:4502401913 and subsequent commentschangedyes2026-05-05: 'One is free to add trust vectors to his own node implementation. Shoving that into the p2p network is not acceptable.'
Status from: 2026-05-20: evoskuil: 'It has been anticipated for many years that degrading performance would lead to these exact calls to abandon validation.'
eynhaender (none)objection, approachviolates trustless verification by introducing a protocol-level dependency on hardcoded chainparams Merkle roots for accepting snapshotsopen · author in c:4468303593 deflected discussion to the mailing list without addressing the concern on GitHubchangedyes2026-05-06: 'This 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 peer'
l0rinc (member)objection, maintenancedual chainstate complicates validation code paths across reorgs, rescanning, and pruning for a temporary security downgradecontested · author replied in c:4468360424 asking for examples; l0rinc pushed back with detailed examples in c:4488453829 and reaffirmed Concept NACK in c:6095180069changedyes2026-05-13: 'the dual chainstate complicates every code path that touches validation - reorgs, wallet rescanning, pruning, the `*DANGER` suffixed methods.'
Status from: 2026-05-19: l0rinc: 'My objection is that `assumeUTXO` makes the most critical part of the codebase harder to read and reason about, and this'
stickies-v (member)objection, maintenanceAssumeUTXO and multiple chainstates add excessive validation complexity for limited benefits that could be handled at higher layerscontested · author replied in c:4468360424; stickies-v pushed back in c:4479458931 citing PR 34521 and kernel decoupling issueschangedyes2026-05-13: 'It adds a ton of validation complexity, and the benefits to me seem limited... Concept NACK any changes that add more AssumeUTXO complexity.'
Status from: 2026-05-18: stickies-v: 'In my experience, many PRs involving validation logic are made more complex simply by having to reason about multiple ch'
stickies-v (member)question, interfacewhy allow the user to specify block height when only hardcoded serialized hashes can be activatedopenansweredno2026-05-13: '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?'
yancyribbens (contributor)suggestion, approachsnapshots could be fetched via https, ssh, ftps, or other encrypted mechanisms instead of adding P2P distributionopenansweredno2026-05-19: 'Even if true, it could easily be https/ssh/ftps or other encrypted internal mechanism, possibly even distributed.'
narula (contributor)objection, maintenanceadds validation code complexity to the project for a low-priority featureopenchangedno2026-05-20: 'Concept NACK, for the same reasons @l0rinc has articulated very well'
sipa (member)question, approachwhether AssumeUTXO with P2P sync but without background re-validation would be preferableanswered · fjahr rejected removing background re-validation in c:4530515268answeredyes2026-05-20: '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?'
Status from: 2026-05-24: fjahr: 'I don’t find AssumeUTXO interesting if we don’t fully validate IBD in the background.'
nkaretnikov (none)objection, approachincurs trust assumptions, implementation complexity, potential bugs, and data usage despite uncertain demand and adoptionopenchangedno2026-05-25: 'this proposal comes with a bunch of concrete downsides: trust assumptions, implementation complexity leading to longer reviews and potential bugs, data usage.'
josibake (member)objection, approachbuilds P2P distribution on top of an unsound AssumeUTXO foundation instead of prioritizing optimizations for full verificationopenchangedno2026-05-28: 'AssumeUTXO is a bad proposal and adding the P2P mechanism on top of it is building on an unsound foundation.'
yancyribbens (contributor)question, safetyhow the trust model is affected when running alternate node implementations using the kernel libopenansweredno2026-05-28: '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 '

Support:

  • andrewtoth (member) (Concept ACK, 2026-04-12) [read]: supports in-band UTXO set acquisition over P2P
  • svanstaa (contributor) (Concept ACK, 2026-04-20) [tested]: successfully tested snapshot download, activation, and subsequent validation against the demo node on mainnet
  • danielabrozzoni (member) (Concept ACK, 2026-04-30) [read]: appreciates UX benefits of P2P UTXO sharing over external sourcing
  • ajtowns (member) (2026-06-05) [read]: supports PRs that make AssumeUTXO more useful while the feature remains supported in the codebase
  • Sjors (member) (Concept ACK, 2026-10-17) [read]: on the general idea of AssumeUTXO snapshot sharing over p2p

Participants:

  • andrewtoth (member, objection, 2 statements 2026-04-12 to 2026-04-30): Concept ACK, but reported an OOM DoS vulnerability and an unhandled snapshot activation failure state
  • svanstaa (contributor, support, 1 statements 2026-04-20 to 2026-04-20): Concept ACK after testing snapshot download, activation, and background validation on mainnet demo node
  • danielabrozzoni (member, support, 4 statements 2026-04-29 to 2026-05-18): Concept ACK; appreciates UX benefits of P2P UTXO sharing, though questioned prioritization against SwiftSync
  • evoskuil (none, objection, 4 statements 2026-05-05 to 2026-05-25): Concept NACK; opposes introducing trust assumptions and unvalidated snapshot distribution into the P2P network
  • eynhaender (none, objection, 1 statements 2026-05-06 to 2026-05-06): Concept NACK; argues protocol reliance on hardcoded chainparams Merkle roots violates trustless verification
  • l0rinc (member, objection, 3 statements 2026-05-13 to 2026-10-10): Concept NACK on extending current AssumeUTXO design; supports alternative architecture without background validation
  • stickies-v (member, objection, 4 statements 2026-05-13 to 2026-05-20): Concept NACK; argues AssumeUTXO and dual chainstate add excessive validation complexity for minimal benefit
  • josibake (member, objection, 3 statements 2026-05-19 to 2026-05-28): Concept NACK; opposes building P2P distribution on AssumeUTXO, arguing resources should focus on optimizing full verification
  • yancyribbens (contributor, question, 2 statements 2026-05-19 to 2026-05-28): asked why nodes cannot fetch snapshots via encrypted out-of-band protocols and raised trust questions for kernel lib consumers
  • narula (contributor, objection, 1 statements 2026-05-20 to 2026-05-20): Concept NACK; agreed with l0rinc regarding validation code complexity impact for a low-priority feature
  • sipa (member, neutral, 2 statements 2026-05-20 to 2026-05-20): suggested considering P2P UTXO sync without background re-validation to evaluate costs and benefits, taking no explicit stance
  • nkaretnikov (none, objection, 1 statements 2026-05-25 to 2026-05-25): Concept NACK; cited implementation complexity, review burden, data overhead, and lack of demonstrated demand
  • ajtowns (member, support, 1 statements 2026-06-05 to 2026-06-05): supports making AssumeUTXO more useful while it exists in the codebase
  • Sjors (member, support, 1 statements 2026-10-17 to 2026-10-17): Concept ACK on AssumeUTXO snapshot sharing over P2P, noting background sync could be dropped first

Files

771 lines under test/bench/ci.

  • src/node/utxo_set_share.cpp +434/-0
  • src/test/utxo_set_share_tests.cpp +377/-0
  • src/node/utxo_set_share.h +193/-0
  • test/functional/p2p_utxo_set_share.py +190/-0
  • src/net_processing.cpp +154/-0
  • test/functional/test_framework/messages.py +122/-0
  • contrib/utxo-tools/utxo_snapshot_merkle.py +73/-0
  • src/rpc/blockchain.cpp +70/-0
  • src/protocol.h +28/-0
  • src/init.cpp +20/-0
  • src/kernel/chainparams.cpp +13/-0
  • src/kernel/chainparams.h +6/-0
  • src/net_processing.h +6/-0
  • src/node/context.h +6/-0
  • test/functional/test_framework/p2p.py +6/-0
  • src/consensus/merkle.h +5/-0
  • src/consensus/merkle.cpp +1/-1
  • src/CMakeLists.txt +1/-0
  • src/logging.cpp +1/-0
  • src/logging/categories.h +1/-0
  • src/node/context.cpp +1/-0
  • src/protocol.cpp +1/-0
  • src/rpc/client.cpp +1/-0
  • src/test/CMakeLists.txt +1/-0
  • src/test/fuzz/rpc.cpp +1/-0
  • src/validation.cpp +1/-0
  • test/functional/test_runner.py +1/-0

Card

The short text the ranking pass compares across PRs.

This PR implements a draft BIP protocol for sharing assumeutxo snapshots over the P2P network using Merkle-proven chunks, aiming to eliminate third-party snapshot hosting as a prerequisite for fast bootstrapping. It adds P2P messages, service flag NODE_UTXO_SET, chunk download management, and a downloadutxoset RPC. The problem is strategically important for node onboarding, but the PR faces severe concept opposition from multiple contributors who view assumeutxo and P2P snapshot sharing as architectural mistakes. The PR is currently a stale draft with failing CI and merge conflicts, with no author activity for nearly four months.

Data

dossier JSON · extract JSON · model ledger, generated 2026-10-18T01:15, confidence high, input hash da1ad7df8743c638
thread read through 2026-10-17 (36 statements), head cf5d5b9533
labels: P2P, Needs rebase, CI failed · draft

Categories

P2P

P2 · new feature (ranking pass: Benefit is contested by sustained concept opposition, so it sits last among equally banded features.)

Adds in-band P2P distribution for AssumeUTXO snapshots according to a draft BIP, significantly lowering onboarding friction for users currently forced to acquire snapshots out-of-band. Protocol extension requires deliberate review of DoS vectors and network resource usage.

Membership: Carries the P2P label and adds the NODE_UTXO_SET service bit and new P2P wire messages to query and fetch snapshot chunks.

Factors: security/stability 1, bug 0, performance 1, user value 2, leverage 1

RPC / REST / ZMQ

P4 · new feature (assessed alone as P3; Lowered to P4 and moved down 16: within rpc its contribution is one new method with no external consumer asking; the substance belongs to p2p.)

Adds the `downloadutxoset` RPC method to initiate and manage background snapshot fetching and activation. It introduces a new control interface without breaking existing RPC methods.

Membership: Implements the new downloadutxoset RPC method in src/rpc/blockchain.cpp to trigger asynchronous fetching and snapshot activation.

Factors: security/stability 1, bug 0, performance 1, user value 2, leverage 1

Validation

P2 · new feature

Deeply impacts assumeutxo workflows by triggering in-process snapshot activation and dual chainstate management. Reviewers in discussion heavily contested the validation complexity and maintenance burdens associated with dual chainstates across reorgs and pruning.

Membership: Implements snapshot activation pipelines and dual chainstate handling for assumeutxo, modifying src/consensus/merkle.cpp and coordinating with background chainstate validation.

Factors: security/stability 1, bug 0, performance 1, user value 2, leverage 1