{
 "number": 36603,
 "input_hash": "af844bda17a7e33c",
 "model": "ledger",
 "prompt_hash": null,
 "created": "2026-10-30T01:12:40+00:00",
 "result": {
  "summary": "Replaces the sequential assumeutxo snapshot loader with a multithreaded pipeline that reads, hashes, serializes, and writes UTXO entries directly into LevelDB. Staging snapshot data through CCoinsViewCache and per-batch fsync calls are eliminated in favor of committing the chainstate directory once loading completes. The PR also adds a txoutsetsummary subcommand to bitcoin-util for inspecting snapshot statistics, serialization hashes, and MuHash commitments offline.",
  "problem": "Loading an assumeutxo snapshot with loadtxoutset is slow and memory-heavy because snapshot data is staged in CCoinsViewCache up to -dbcache limits, gated by repeated fsync writes, and hashed sequentially after LevelDB population finishes.",
  "card": "Accelerates assumeutxo snapshot imports in loadtxoutset by replacing the sequential loader with a concurrent pipeline that reads, hashes, serializes, and writes coins directly into LevelDB. It removes CCoinsViewCache staging, avoids intermediate fsync calls during bulk writing, and introduces an offline txoutsetsummary tool in bitcoin-util to verify snapshot statistics and MuHash values. Currently, snapshot loading is serialized, bottlenecked by cache flush cycles, and calculates hashes only after population completes. The author notes that this pipeline shifts the performance bottleneck entirely to LevelDB CPU consumption. Work on P2P UTXO set sharing (#35054) builds on these changes.",
  "evidence": [
   "Author description: 'Significantly improves loadtxoutset performance via a number of changes: parallel threads for decoding, hashing, serializing and writing to leveldb; no fsync() gating writes; no redundant loading into CoinsView.'",
   "Author description: 'On my systems, performance ends up bottlenecked by leveldb CPU usage.'",
   "Commit 49aa42ccaa: 'The dump is no longer staged in a CCoinsViewCache and then hashed and flushed out of it, so -dbcache worth of cached coins during a mainnet load are gone along with the flush cycles. In addition, the hashing of the dump takes place in parallel with the import, rather than after it completes.'"
  ],
  "scope_notes": "Adds a reusable thread-safe BlockingQueue utility (src/util/blockingqueue.h) and a nosync mode to CDBWrapper that wraps LevelDB writable files to suppress synchronous disk flushes during bulk population. The largest files implementing the multithreaded import pipeline and bitcoin-util tool are truncated in the diff.",
  "changed_since_previous": "No structural changes to the design or commit sequence; contains rebases and minor test refinements.",
  "thread": {
   "last_event_at": "2026-10-23T11:35:03Z",
   "events": 3,
   "head_sha": "fbda3acde3914cf9ce14a58070467c8989429881",
   "schema_floor": 2,
   "schema": 2
  },
  "waiting_on": [
   {
    "at": "2026-10-23",
    "id": "c:6363949408",
    "on": "reviewer",
    "url": "https://github.com/bitcoin/bitcoin/pull/36603#issuecomment-6363949408",
    "what": "l0rinc to review the author's response on AssumeUTXO complexity and load performance"
   }
  ],
  "risk": {
   "level": "high",
   "touches": [
    "validation"
   ],
   "why": "Flaws in outpoint ordering or direct-to-disk LevelDB batch writing could silently corrupt the assumeutxo chainstate, causing consensus validation failures or forks."
  },
  "discussion": {
   "author_status": "last statement processed 2026-10-23",
   "open_concerns": [
    "l0rinc: Adds AssumeUTXO-specific complexity and pollutes the codebase with multiple chainstates, making consensus-critical paths harder to reason about"
   ],
   "resolved_concerns": [
    "l0rinc: Why is an 11-minute load considered too slow, and is that preventing adoption enough to justify complexity in load-bearing code? (answered by ajtowns 2026-10-23)"
   ]
  },
  "reviewability": {
   "state": "Ready",
   "label": "Ready",
   "reason": "Nothing known that would invalidate a review now."
  },
  "agreement": {
   "state": "Mild",
   "summary": "Mild: objection that needs a change was answered, no reply from the objector (l0rinc: Adds AssumeUTXO-specific complexity and pollutes the codebase with multiple chainstates, making consensus-critical paths)",
   "reason": "Reviewed author's updated performance benchmark comment; claims and participant status remain unchanged.",
   "evidence": [
    "l0rinc (objection, maintenance, must be changed, answered): Adds AssumeUTXO-specific complexity and pollutes the codebase with multiple chainstates, making consensus-critical paths harder to reason about"
   ],
   "objections": [
    {
     "reviewer": "l0rinc",
     "association": "MEMBER",
     "type": "question",
     "kind": "usefulness",
     "harm": "",
     "request": "",
     "question": "Why is an 11-minute load considered too slow, and is that preventing adoption enough to justify complexity in load-bearing code?",
     "text": "Why is an 11-minute load considered too slow, and is that preventing adoption enough to justify complexity in load-bearing code?",
     "clears_with": "answer",
     "blocking": false,
     "status": "answered",
     "status_note": "author replied explaining that excessive compactions and memory usage cause unnecessary slowness",
     "cleared": true,
     "author_replied": true,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [
      "c:6363949408"
     ],
     "evidence": "2026-10-23: 'Why do you consider an 11-minute load too slow? Is there a reason to think this is what's preventing people from using it - enough to justify yet more complexity in the most \"load-bearing\" parts of th'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36603#issuecomment-6359437508",
     "id": "c:6359437508",
     "at": "2026-10-23",
     "status_at": "2026-10-23",
     "status_by": "ajtowns",
     "resolution_evidence": "2026-10-23: ajtowns: 'I don't consider it too slow; though it's possible it could be on slower systems than the ones I test on.'",
     "pin": null,
     "from_schema": 2
    },
    {
     "reviewer": "l0rinc",
     "association": "MEMBER",
     "type": "objection",
     "kind": "maintenance",
     "harm": "Adds AssumeUTXO-specific complexity and pollutes the codebase with multiple chainstates, making consensus-critical paths harder to reason about",
     "request": "",
     "question": "",
     "text": "Adds AssumeUTXO-specific complexity and pollutes the codebase with multiple chainstates, making consensus-critical paths harder to reason about",
     "clears_with": "change",
     "blocking": true,
     "status": "answered",
     "status_note": "author replied arguing AssumeUTXO is a better solution for fast node startup than IBD optimizations",
     "cleared": false,
     "author_replied": true,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [
      "c:6363949408"
     ],
     "evidence": "2026-10-23: 'This change adds *even* more AssumeUTXO-specific complexity, which is exactly why we're considering removing it completely. ... many of us are not comfortable polluting the code with multiple chainsta'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36603#issuecomment-6359437508",
     "id": "c:6359437508#2",
     "at": "2026-10-23",
     "status_at": "2026-10-23",
     "status_by": "ajtowns",
     "resolution_evidence": "2026-10-23: ajtowns: 'I think the assumeutxo approach is a much better approach to resolving the \"fast startup of a new node\" challenge than t'",
     "pin": null,
     "from_schema": 2
    }
   ],
   "support": [],
   "participants": [
    {
     "login": "l0rinc",
     "stance": "objection",
     "note": "objected to adding AssumeUTXO complexity to consensus-critical paths and questioned the motivation",
     "association": "MEMBER",
     "comments": 1,
     "first": "2026-10-23",
     "last": "2026-10-23"
    }
   ],
   "derivation": "objection that needs a change was answered, no reply from the objector (l0rinc: Adds AssumeUTXO-specific complexity and pollutes the codebase with multiple chainstates, making consensus-critical paths)",
   "model_state": null,
   "corrections": [],
   "notes": "Reviewed author's updated performance benchmark comment; claims and participant status remain unchanged."
  },
  "dependencies": {
   "depends_on": [],
   "enables": [
    "#35054"
   ]
  },
  "categories": [
   {
    "name": "mempool",
    "member": false,
    "evidence": "Touches validation.cpp exclusively for chainstate and snapshot initialization, not mempool or transaction relay policy.",
    "band": "Unranked",
    "reason_tag": "speedup",
    "score": 0.0,
    "factors": {
     "bug_severity": 0,
     "leverage": 2,
     "performance": 3,
     "security_stability": 1,
     "user_value": 2
    },
    "rationale": "Does not alter mempool data structures, eviction, fee estimation, or policy rules."
   },
   {
    "name": "rpc",
    "member": false,
    "evidence": "src/rpc/blockchain.cpp diff (+3/-3) only updates call sites for the internal loadtxoutset interface.",
    "band": "Unranked",
    "reason_tag": "speedup",
    "score": 0.0,
    "factors": {
     "bug_severity": 0,
     "leverage": 2,
     "performance": 3,
     "security_stability": 1,
     "user_value": 2
    },
    "rationale": "Does not change RPC interfaces or endpoints; changes only the underlying validation implementation that loadtxoutset exposes."
   },
   {
    "name": "tests",
    "member": false,
    "evidence": "Changes to test files (such as validation_chainstatemanager_tests.cpp and fuzz tests) only exercise the new snapshot loading and utility code.",
    "band": "Unranked",
    "reason_tag": "test coverage",
    "score": 0.0,
    "factors": {
     "bug_severity": 0,
     "leverage": 2,
     "performance": 3,
     "security_stability": 1,
     "user_value": 2
    },
    "rationale": "Tests pin the behavior of the snapshot loader and utilities rather than modifying general test framework infrastructure."
   },
   {
    "name": "tools",
    "member": true,
    "evidence": "src/bitcoin-util.cpp (+137/-0) adds an offline txoutsetsummary tool.",
    "band": "P3",
    "reason_tag": "new feature",
    "score": 0.35,
    "factors": {
     "bug_severity": 0,
     "leverage": 2,
     "performance": 3,
     "security_stability": 1,
     "user_value": 2
    },
    "rationale": "The PR adds a txoutsetsummary subcommand to bitcoin-util for inspecting snapshot statistics, serialization hashes, and MuHash commitments offline. This provides a useful offline inspection tool for operators and developers handling assumeutxo snapshots."
   },
   {
    "name": "utils",
    "member": true,
    "evidence": "src/util/blockingqueue.h (+135/-0) introduces a general-purpose synchronization utility.",
    "band": "P3",
    "reason_tag": "new feature",
    "score": 0.3,
    "factors": {
     "bug_severity": 0,
     "leverage": 2,
     "performance": 3,
     "security_stability": 1,
     "user_value": 2
    },
    "rationale": "Adds a reusable thread-safe BlockingQueue utility in src/util/blockingqueue.h with dedicated unit tests. While created to support the pipeline, it constitutes a new general concurrency primitive for node utilities."
   },
   {
    "name": "validation",
    "member": true,
    "evidence": "Substantially alters assumeutxo snapshot loading, chainstate LevelDB writing, and UTXO coins handling across src/validation.cpp, src/node/utxo_snapshot.cpp, and src/txdb.cpp.",
    "band": "P2",
    "reason_tag": "speedup",
    "score": 0.7,
    "factors": {
     "bug_severity": 0,
     "leverage": 2,
     "performance": 3,
     "security_stability": 1,
     "user_value": 2
    },
    "rationale": "Significantly accelerates assumeutxo snapshot loading by replacing sequential loading with a parallelized pipeline and direct LevelDB writes. It removes the intermediate CCoinsViewCache staging and redundant flush cycles, addressing a major bottleneck in node bootstrap performance."
   }
  ],
  "confidence": "high",
  "uncertainties": [],
  "needs": [
   "rest_of_diff",
   "benchmark_numbers"
  ]
 },
 "cost_usd": 0.0,
 "source": {
  "record": "2026-10-30T01:12:40+00:00",
  "code": "2026-10-30T01:17:03+00:00",
  "judgments": 6
 }
}