{
 "number": 36543,
 "input_hash": "e23d1c518a967867",
 "model": "ledger",
 "prompt_hash": null,
 "created": "2026-10-26T01:22:38+00:00",
 "result": {
  "summary": "Verifies the hardcoded AssumeUTXO commitment during normal Initial Block Download when block connection reaches the snapshot height and block hash. Pending UTXO modifications are synchronously flushed to disk, the serialized UTXO set is hashed, and a mismatch or failure causes the node to shut down with a fatal error. To prevent repeated multi-minute hashing passes during IBD, chainparams is simplified to store only the single most recent AssumeUTXO commitment per network, deprecating older snapshot activations.",
  "problem": "AssumeUTXO relies on hardcoded snapshot hashes compiled into the node binary. Even though nodes running standard IBD independently reconstruct the exact UTXO set from genesis, they never compare it against the hardcoded commitment, passing up crowd-sourced verification of baked-in snapshot commitments against history (#32377).",
  "card": "This PR verifies the hardcoded AssumeUTXO snapshot hash during standard Initial Block Download when block connection reaches the commitment height, triggering a fatal error and node shutdown on a mismatch. Full nodes independently rebuild the UTXO set from genesis during IBD, but previously never checked whether their reconstructed UTXO set matched the baked-in commitments (#32377). To avoid multiple expensive UTXO hashing passes during IBD, chainparams is changed to retain only the single latest AssumeUTXO commitment per network, retiring support for loading older snapshots.",
  "evidence": [
   "Linked issue #32377 ('AssumeUTXO: crowdsource trust through independent snapshot verification') notes that every syncing full node could automatically audit hardcoded snapshot hashes during standard IBD.",
   "Commit 36a2a70452 explains: 'This checks the developer-provided commitment against the UTXO set that every node reconstructs during IBD (see #32377).'"
  ],
  "scope_notes": "Retaining only the single latest snapshot commitment is a breaking change for loading older AssumeUTXO snapshots or restarting snapshot chainstates built against retired commitments.",
  "changed_since_previous": "Propagates snapshot verification errors out of ConnectTip as runtime errors instead of reporting success, and refines interruption handling so interrupted hashing during shutdown is not recorded as a validation failure.",
  "thread": {
   "last_event_at": "2026-10-25T11:38:48Z",
   "events": 4,
   "head_sha": "97b2138e39ce34e239039e7d38d95e15f3c19a9d",
   "schema_floor": 2,
   "schema": 2
  },
  "waiting_on": [
   {
    "at": "2026-10-25",
    "id": "r:5643008477",
    "on": "author",
    "url": "https://github.com/bitcoin/bitcoin/pull/36543#pullrequestreview-5643008477",
    "what": "addressing objections and suggestions from Sjors, optout21, ajtowns, and fametrano's assert bug report"
   }
  ],
  "risk": {
   "level": "medium",
   "touches": [
    "validation"
   ],
   "why": "It inserts a synchronous disk flush, multi-minute UTXO hashing pass, and potential fatal error exit into ConnectTip during normal block validation."
  },
  "discussion": {
   "author_status": "last statement processed 2026-10-25",
   "open_concerns": [
    "Sjors: Stopping the node on a mismatch risks introducing an effective checkpoint that prevents normal sync if the snapshot commitment is malicious",
    "Sjors: Limit the scope of the PR by checking the latest hash without deleting the older commitments yet",
    "Sjors: Provide benchmark numbers in the PR description showing minimal performance impact",
    "Sjors: How does flushing chainstate to disk before hashing interact with current IBD flush frequency?",
    "optout21: Add a configuration option to bypass or ignore the AssumeUTXO hash check",
    "optout21: Keep non-latest AssumeUTXO commitments in source for visibility instead of dropping them",
    "ajtowns: What is the performance impact when hitting an AssumeUTXO commitment block during validation?",
    "ajtowns: Crashing an IBD node on snapshot mismatch penalizes nodes with fully verified valid data while failing to protect snapshot users from following an incorrect chain",
    "ajtowns: Consider predictable snapshot points (e.g. BIP 452) or including the block's muhash in the AssumeUTXO commitment to make verification easier and less disruptive",
    "fametrano: A node failing the check aborts on an assertion due to inconsistent chainstate/coins tip, and a plain restart syncs past the commitment without checking it again"
   ],
   "resolved_concerns": []
  },
  "reviewability": {
   "state": "Paused",
   "label": "Waiting on author",
   "reason": "Open objections from Sjors, ajtowns, fametrano with no author reply for 7 days; review would repeat what has been asked."
  },
  "agreement": {
   "state": "Blocked",
   "summary": "Blocked: objection that needs a change, nobody has replied (Sjors, fametrano)",
   "reason": "fametrano gave a Concept ACK but reported a concrete correctness objection: an assertion failure occurs when the check fails because coins update before the chain tip, which also allows a restart to skip the check.",
   "evidence": [
    "Sjors (objection, safety, must be changed, open): Stopping the node on a mismatch risks introducing an effective checkpoint that prevents normal sync if the snapshot commitment is malicious",
    "Sjors (suggestion, scope, must be answered, open): Limit the scope of the PR by checking the latest hash without deleting the older commitments yet",
    "Sjors (suggestion, maintenance, must be answered, open): Provide benchmark numbers in the PR description showing minimal performance impact",
    "Sjors (question, correctness, must be answered, open): How does flushing chainstate to disk before hashing interact with current IBD flush frequency?",
    "optout21 (suggestion, interface, must be answered, open): Add a configuration option to bypass or ignore the AssumeUTXO hash check",
    "optout21 (suggestion, scope, must be answered, open): Keep non-latest AssumeUTXO commitments in source for visibility instead of dropping them",
    "ajtowns (question, maintenance, must be answered, open): What is the performance impact when hitting an AssumeUTXO commitment block during validation?",
    "ajtowns (objection, safety, must be answered, open): Crashing an IBD node on snapshot mismatch penalizes nodes with fully verified valid data while failing to protect snapshot users from following an incorrect chain",
    "ajtowns (suggestion, approach, must be answered, open): Consider predictable snapshot points (e.g. BIP 452) or including the block's muhash in the AssumeUTXO commitment to make verification easier and less disruptive",
    "fametrano (objection, correctness, must be changed, open): A node failing the check aborts on an assertion due to inconsistent chainstate/coins tip, and a plain restart syncs past the commitment without checking it again",
    "Sjors: Concept ACK \u2014 see #32377, with two caveats",
    "optout21: Concept ACK \u2014 As there is a hash provided that requires trust, the more checks the better. It makes sense to use all nodes performing IBD to also perform this check, as it's relatively cheap to do.",
    "fametrano: Concept ACK"
   ],
   "objections": [
    {
     "reviewer": "Sjors",
     "association": "MEMBER",
     "type": "objection",
     "kind": "safety",
     "harm": "Stopping the node on a mismatch risks introducing an effective checkpoint that prevents normal sync if the snapshot commitment is malicious",
     "request": "",
     "question": "",
     "text": "Stopping the node on a mismatch risks introducing an effective checkpoint that prevents normal sync if the snapshot commitment is malicious",
     "clears_with": "change",
     "blocking": true,
     "status": "open",
     "status_note": "",
     "cleared": false,
     "author_replied": false,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [],
     "evidence": "2026-10-17: 'I think this risks introducing a new effective checkpoint. If the snapshot were malicious, normal users couldn't sync'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36543#issuecomment-6229005853",
     "id": "c:6229005853",
     "at": "2026-10-17",
     "status_at": null,
     "status_by": null,
     "resolution_evidence": "",
     "pin": null,
     "from_schema": 2
    },
    {
     "reviewer": "Sjors",
     "association": "MEMBER",
     "type": "suggestion",
     "kind": "scope",
     "harm": "",
     "request": "Limit the scope of the PR by checking the latest hash without deleting the older commitments yet",
     "question": "",
     "text": "Limit the scope of the PR by checking the latest hash without deleting the older commitments yet",
     "clears_with": "answer",
     "blocking": false,
     "status": "open",
     "status_note": "",
     "cleared": false,
     "author_replied": false,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [],
     "evidence": "2026-10-17: 'Maybe limit the scope of this PR by only _checking_ the latest hash, but not (yet) deleting the other hashes.'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36543#issuecomment-6229005853",
     "id": "c:6229005853#2",
     "at": "2026-10-17",
     "status_at": null,
     "status_by": null,
     "resolution_evidence": "",
     "pin": null,
     "from_schema": 2
    },
    {
     "reviewer": "Sjors",
     "association": "MEMBER",
     "type": "suggestion",
     "kind": "maintenance",
     "harm": "",
     "request": "Provide benchmark numbers in the PR description showing minimal performance impact",
     "question": "",
     "text": "Provide benchmark numbers in the PR description showing minimal performance impact",
     "clears_with": "answer",
     "blocking": false,
     "status": "open",
     "status_note": "",
     "cleared": false,
     "author_replied": false,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [],
     "evidence": "2026-10-17: 'It would be good to provide some numbers in the PR description.'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36543#issuecomment-6229005853",
     "id": "c:6229005853#3",
     "at": "2026-10-17",
     "status_at": null,
     "status_by": null,
     "resolution_evidence": "",
     "pin": null,
     "from_schema": 2
    },
    {
     "reviewer": "Sjors",
     "association": "MEMBER",
     "type": "question",
     "kind": "correctness",
     "harm": "",
     "request": "",
     "question": "How does flushing chainstate to disk before hashing interact with current IBD flush frequency?",
     "text": "How does flushing chainstate to disk before hashing interact with current IBD flush frequency?",
     "clears_with": "answer",
     "blocking": false,
     "status": "open",
     "status_note": "",
     "cleared": false,
     "author_replied": false,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [],
     "evidence": "2026-10-17: 'I'm not up to speed on how often and when we flush the chainstate to disk during IBD nowadays. How does this interact with that?'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36543#issuecomment-6229005853",
     "id": "c:6229005853#4",
     "at": "2026-10-17",
     "status_at": null,
     "status_by": null,
     "resolution_evidence": "",
     "pin": null,
     "from_schema": 2
    },
    {
     "reviewer": "optout21",
     "association": "CONTRIBUTOR",
     "type": "suggestion",
     "kind": "interface",
     "harm": "",
     "request": "Add a configuration option to bypass or ignore the AssumeUTXO hash check",
     "question": "",
     "text": "Add a configuration option to bypass or ignore the AssumeUTXO hash check",
     "clears_with": "answer",
     "blocking": false,
     "status": "open",
     "status_note": "",
     "cleared": false,
     "author_replied": false,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [],
     "evidence": "2026-10-17: 'Introduce an option to skip the new AssumeUTXO hash check (may be a hidden option)'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36543#issuecomment-6230060049",
     "id": "c:6230060049",
     "at": "2026-10-17",
     "status_at": null,
     "status_by": null,
     "resolution_evidence": "",
     "pin": null,
     "from_schema": 2
    },
    {
     "reviewer": "optout21",
     "association": "CONTRIBUTOR",
     "type": "suggestion",
     "kind": "scope",
     "harm": "",
     "request": "Keep non-latest AssumeUTXO commitments in source for visibility instead of dropping them",
     "question": "",
     "text": "Keep non-latest AssumeUTXO commitments in source for visibility instead of dropping them",
     "clears_with": "answer",
     "blocking": false,
     "status": "open",
     "status_note": "",
     "cleared": false,
     "author_replied": false,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [],
     "evidence": "2026-10-17: 'So not checking the non-latest hashes is fine, but it's useful to keep them for visibility.'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36543#issuecomment-6230060049",
     "id": "c:6230060049#2",
     "at": "2026-10-17",
     "status_at": null,
     "status_by": null,
     "resolution_evidence": "",
     "pin": null,
     "from_schema": 2
    },
    {
     "reviewer": "ajtowns",
     "association": "MEMBER",
     "type": "question",
     "kind": "maintenance",
     "harm": "",
     "request": "",
     "question": "What is the performance impact when hitting an AssumeUTXO commitment block during validation?",
     "text": "What is the performance impact when hitting an AssumeUTXO commitment block during validation?",
     "clears_with": "answer",
     "blocking": false,
     "status": "open",
     "status_note": "",
     "cleared": false,
     "author_replied": false,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [],
     "evidence": "2026-10-24: 'What's the performance impact when hitting such a block?'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36543#issuecomment-6379792380",
     "id": "c:6379792380",
     "at": "2026-10-24",
     "status_at": null,
     "status_by": null,
     "resolution_evidence": "",
     "pin": null,
     "from_schema": 2
    },
    {
     "reviewer": "ajtowns",
     "association": "MEMBER",
     "type": "objection",
     "kind": "safety",
     "harm": "Crashing an IBD node on snapshot mismatch penalizes nodes with fully verified valid data while failing to protect snapshot users from following an incorrect chain",
     "request": "",
     "question": "",
     "text": "Crashing an IBD node on snapshot mismatch penalizes nodes with fully verified valid data while failing to protect snapshot users from following an incorrect chain",
     "clears_with": "answer",
     "blocking": false,
     "status": "open",
     "status_note": "",
     "cleared": false,
     "author_replied": false,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [],
     "evidence": "2026-10-24: 'Doesn't this make the result of a release including bad snaphot data worse for everyone -- Alice who does IBD has her node crash despite having good data that she fully verified, and Bob who uses the '",
     "url": "https://github.com/bitcoin/bitcoin/pull/36543#issuecomment-6379792380",
     "id": "c:6379792380#2",
     "at": "2026-10-24",
     "status_at": null,
     "status_by": null,
     "resolution_evidence": "",
     "pin": null,
     "from_schema": 2
    },
    {
     "reviewer": "ajtowns",
     "association": "MEMBER",
     "type": "suggestion",
     "kind": "approach",
     "harm": "",
     "request": "Consider predictable snapshot points (e.g. BIP 452) or including the block's muhash in the AssumeUTXO commitment to make verification easier and less disruptive",
     "question": "",
     "text": "Consider predictable snapshot points (e.g. BIP 452) or including the block's muhash in the AssumeUTXO commitment to make verification easier and less disruptive",
     "clears_with": "answer",
     "blocking": false,
     "status": "open",
     "status_note": "",
     "cleared": false,
     "author_replied": false,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [],
     "evidence": "2026-10-24: 'Having predictable snapshot points (every 14112 blocks [per bip452]) would allow every node to calculate the appropriate hash... Including the block's muhash in the assumeutxo set would also probably '",
     "url": "https://github.com/bitcoin/bitcoin/pull/36543#issuecomment-6379792380",
     "id": "c:6379792380#3",
     "at": "2026-10-24",
     "status_at": null,
     "status_by": null,
     "resolution_evidence": "",
     "pin": null,
     "from_schema": 2
    },
    {
     "reviewer": "fametrano",
     "association": "CONTRIBUTOR",
     "type": "objection",
     "kind": "correctness",
     "harm": "A node failing the check aborts on an assertion due to inconsistent chainstate/coins tip, and a plain restart syncs past the commitment without checking it again",
     "request": "",
     "question": "",
     "text": "A node failing the check aborts on an assertion due to inconsistent chainstate/coins tip, and a plain restart syncs past the commitment without checking it again",
     "clears_with": "change",
     "blocking": true,
     "status": "open",
     "status_note": "",
     "cleared": false,
     "author_replied": false,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [],
     "evidence": "2026-10-25: 'a node that fails the new check aborts on an assertion, and a plain restart then syncs past the commitment without checking it again'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36543#pullrequestreview-5643008477",
     "id": "r:5643008477",
     "at": "2026-10-25",
     "status_at": null,
     "status_by": null,
     "resolution_evidence": "",
     "pin": null,
     "from_schema": 2
    }
   ],
   "support": [
    {
     "reviewer": "Sjors",
     "reason": "see #32377, with two caveats",
     "substantive": true,
     "verdict": "Concept ACK",
     "id": "c:6229005853",
     "url": "https://github.com/bitcoin/bitcoin/pull/36543#issuecomment-6229005853",
     "at": "2026-10-17",
     "association": "MEMBER",
     "evidence": "none",
     "areas": []
    },
    {
     "reviewer": "optout21",
     "reason": "As there is a hash provided that requires trust, the more checks the better. It makes sense to use all nodes performing IBD to also perform this check, as it's relatively cheap to do.",
     "substantive": true,
     "verdict": "Concept ACK",
     "id": "c:6230060049",
     "url": "https://github.com/bitcoin/bitcoin/pull/36543#issuecomment-6230060049",
     "at": "2026-10-17",
     "association": "CONTRIBUTOR",
     "evidence": "none",
     "areas": []
    },
    {
     "reviewer": "fametrano",
     "reason": "",
     "substantive": false,
     "verdict": "Concept ACK",
     "id": "r:5643008477",
     "url": "https://github.com/bitcoin/bitcoin/pull/36543#pullrequestreview-5643008477",
     "at": "2026-10-25",
     "association": "CONTRIBUTOR",
     "evidence": "both",
     "areas": [
      "ConnectTip",
      "ConnectBlock",
      "CheckBlockIndex",
      "feature_assumeutxo.py"
     ]
    }
   ],
   "participants": [
    {
     "login": "Sjors",
     "stance": "objection",
     "note": "Concept ACK with caveats; objects to stopping on mismatch as an effective checkpoint, suggests keeping older commitments, and asks about flushing",
     "association": "MEMBER",
     "comments": 1,
     "first": "2026-10-17",
     "last": "2026-10-17"
    },
    {
     "login": "optout21",
     "stance": "support",
     "note": "Concept ACK; suggests an option to skip the check and keeping older commitments for visibility",
     "association": "CONTRIBUTOR",
     "comments": 1,
     "first": "2026-10-17",
     "last": "2026-10-17"
    },
    {
     "login": "ajtowns",
     "stance": "objection",
     "note": "objects that crashing IBD on mismatch makes bad snapshot releases worse for everyone, asks about performance impact, and suggests alternative approaches",
     "association": "MEMBER",
     "comments": 1,
     "first": "2026-10-24",
     "last": "2026-10-24"
    },
    {
     "login": "fametrano",
     "stance": "objection",
     "note": "Concept ACK, but objects to assertion failure on mismatch leaving coins cache and chain tip out of sync, allowing restarts to bypass the check",
     "association": "CONTRIBUTOR",
     "comments": 1,
     "first": "2026-10-25",
     "last": "2026-10-25"
    }
   ],
   "derivation": "objection that needs a change, nobody has replied (Sjors, fametrano)",
   "model_state": null,
   "corrections": [],
   "notes": "fametrano gave a Concept ACK but reported a concrete correctness objection: an assertion failure occurs when the check fails because coins update before the chain tip, which also allows a restart to skip the check."
  },
  "dependencies": {
   "depends_on": [],
   "enables": []
  },
  "categories": [
   {
    "name": "docs",
    "member": false,
    "evidence": "Documentation updates (doc/assumeutxo.md, release notes) merely accompany the code changes.",
    "band": "Unranked",
    "reason_tag": "cleanup",
    "score": 0.0,
    "factors": {
     "bug_severity": 0,
     "leverage": 1,
     "performance": 0,
     "security_stability": 1,
     "user_value": 1
    },
    "rationale": "Non-member; doc changes follow the validation change."
   },
   {
    "name": "kernel",
    "member": false,
    "evidence": "Changes to src/kernel/chainparams.cpp only update hardcoded snapshot commitments and do not alter the kernel C/C++ API or library boundary.",
    "band": "Unranked",
    "reason_tag": "cleanup",
    "score": 0.0,
    "factors": {
     "bug_severity": 0,
     "leverage": 1,
     "performance": 0,
     "security_stability": 1,
     "user_value": 1
    },
    "rationale": "Non-member; touches chainparams without altering kernel interfaces."
   },
   {
    "name": "mempool",
    "member": false,
    "evidence": "Keyword matches in validation files do not touch mempool acceptance or policy logic.",
    "band": "Unranked",
    "reason_tag": "cleanup",
    "score": 0.0,
    "factors": {
     "bug_severity": 0,
     "leverage": 1,
     "performance": 0,
     "security_stability": 1,
     "user_value": 1
    },
    "rationale": "Non-member; does not touch mempool or transaction relay policy."
   },
   {
    "name": "rpc",
    "member": false,
    "evidence": "src/rpc/blockchain.cpp edits are minor adjustments following chainparams assumeutxo changes.",
    "band": "Unranked",
    "reason_tag": "cleanup",
    "score": 0.0,
    "factors": {
     "bug_severity": 0,
     "leverage": 1,
     "performance": 0,
     "security_stability": 1,
     "user_value": 1
    },
    "rationale": "Non-member; RPC behavior is not the subject of this change."
   },
   {
    "name": "tests",
    "member": false,
    "evidence": "Test modifications in validation_chainstatemanager_tests and feature_assumeutxo pin the validation changes rather than the test runner framework.",
    "band": "Unranked",
    "reason_tag": "test coverage",
    "score": 0.0,
    "factors": {
     "bug_severity": 0,
     "leverage": 1,
     "performance": 0,
     "security_stability": 1,
     "user_value": 1
    },
    "rationale": "Non-member; test changes follow validation behavior."
   },
   {
    "name": "utils",
    "member": false,
    "evidence": "Incidental removal of unused utility code in src/util/vector.h.",
    "band": "Unranked",
    "reason_tag": "cleanup",
    "score": 0.0,
    "factors": {
     "bug_severity": 0,
     "leverage": 1,
     "performance": 0,
     "security_stability": 1,
     "user_value": 1
    },
    "rationale": "Non-member; utility file modification is purely incidental."
   },
   {
    "name": "validation",
    "member": true,
    "evidence": "Has the Validation label and modifies block connection and chainstate flushing logic in src/validation.cpp to audit AssumeUTXO commitments during IBD.",
    "band": "P2",
    "reason_tag": "new feature",
    "score": 0.6,
    "factors": {
     "bug_severity": 0,
     "leverage": 1,
     "performance": 0,
     "security_stability": 1,
     "user_value": 1
    },
    "rationale": "Crowdsources verification of baked-in snapshot commitments against history during standard IBD. As noted in #32377, full nodes currently reconstruct the full UTXO set without auditing hardcoded AssumeUTXO commitments, leaving a trust gap in snapshot validation."
   }
  ],
  "confidence": "high",
  "uncertainties": [],
  "needs": []
 },
 "cost_usd": 0.0,
 "source": {
  "record": "2026-10-26T01:22:38+00:00",
  "code": "2026-10-17T01:21:37+00:00",
  "judgments": 7
 }
}