{ "number": 36578, "input_hash": "6b61a3eddd634c33", "model": "ledger", "prompt_hash": null, "created": "2026-10-26T01:22:49+00:00", "result": { "summary": "Updates 1P1C package construction in TxDownloadManagerImpl to check if candidate orphan transactions are already in the mempool. If a candidate child exists in the mempool, it is erased from the orphanage and skipped. This preserves the invariant that package evaluation never receives an already-admitted child, retaining the Assume(false) assertion for MEMPOOL_ENTRY in net_processing.", "problem": "Orphan transactions that enter the mempool through non-peer mechanisms such as RPC submission are not automatically evicted from the orphanage. When a reconsiderable parent subsequently arrives from a peer, Find1P1CPackage could select that orphan as a package child, resulting in a MEMPOOL_ENTRY acceptance result that triggers an Assume(false) assertion failure in debug builds.", "card": "This PR fixes a debug assertion failure during 1P1C package relay when an orphan child is already present in the mempool. Transactions entering the mempool through RPC or other non-peer paths are not pruned from the orphanage, previously allowing Find1P1CPackage to pick them as children for reconsiderable parents and triggering an Assume(false) on MEMPOOL_ENTRY during package evaluation. The change inspects candidate orphans in Find1P1CPackage, erasing them from the orphanage and skipping them if they are already in the mempool. A functional test is added to reproduce and verify the fix.", "evidence": [ "PR description: 'An orphan that enters the mempool other than through peer relay (e.g. by RPC) stays in the orphanage, so Find1P1CPackage can pick it as the child of a reconsiderable parent, and package evaluation then reports it as MEMPOOL_ENTRY, which hits Assume(false).'", "The added functional test (test_orphan_in_mempool) reproduces the exact issue: an orphan submitted via submitpackage enters the mempool while remaining in the orphanage, triggering the code path upon receiving the reconsiderable parent." ], "scope_notes": "", "changed_since_previous": "Rather than removing the Assume(false) assertion in ProcessPackageResult and handling MEMPOOL_ENTRY as an acceptance notification, the PR now intercepts the case inside Find1P1CPackage, erasing the child from the orphanage and skipping it to keep the assertion intact.", "thread": { "last_event_at": "2026-10-25T07:50:36Z", "events": 7, "head_sha": "a93bdc83202e00375b643e6df3b9daa801f7de23", "schema_floor": 2, "schema": 2 }, "waiting_on": [ { "at": null, "id": "", "on": "nothing", "url": null, "what": "no pending items or requests" } ], "risk": { "level": "medium", "touches": [ "p2p" ], "why": "A flaw in mempool existence checks or orphan erasure could prematurely discard valid orphan transactions or cause 1P1C package construction to fail during peer transaction relay." }, "discussion": { "author_status": "last statement processed 2026-10-25", "open_concerns": [], "resolved_concerns": [ "ismaelsadeeq: Clean the orphanage proactively on mempool entry via TransactionAddedToMempool so orphans entering by any path are removed, rather than reactive cleanup (answered by instagibbs 2026-10-21)" ] }, "reviewability": { "state": "Ready", "label": "Ready", "reason": "Nothing known that would invalidate a review now." }, "agreement": { "state": "Strong", "summary": "Strong: substantive support, no open objection (fametrano)", "reason": "Added fametrano's Tested ACK confirming the bug reproduction and fix, and supporting the reactive cleanup approach over mempool hooks.", "evidence": [ "Yudis-bit: Tested ACK \u2014 tested on Windows", "fametrano: Tested ACK \u2014 verified Assume(false) reproduces on master via sendrawtransaction and that this PR fixes it; agrees with keeping a mempool hook out of this PR" ], "objections": [ { "reviewer": "ismaelsadeeq", "association": "MEMBER", "type": "suggestion", "kind": "approach", "harm": "", "request": "Clean the orphanage proactively on mempool entry via TransactionAddedToMempool so orphans entering by any path are removed, rather than reactive cleanup", "question": "", "text": "Clean the orphanage proactively on mempool entry via TransactionAddedToMempool so orphans entering by any path are removed, rather than reactive cleanup", "clears_with": "answer", "blocking": false, "status": "answered", "status_note": "author switched to Find1P1CPackage strategy but declined async sweep for now", "cleared": true, "author_replied": true, "others_replied": true, "fix_pushed": false, "replies": [ "c:6316850266", "c:6317864893", "c:6395070625" ], "evidence": "2026-10-21: 'I'd rather we clean the orphanage proactively on mempool entry, via `TransactionAddedToMempool`? so an orphan that enters by any path is removed regardless.'", "url": "https://github.com/bitcoin/bitcoin/pull/36578#issuecomment-6313515799", "id": "c:6313515799", "at": "2026-10-21", "status_at": "2026-10-21", "status_by": "instagibbs", "resolution_evidence": "2026-10-21: instagibbs: 'swtiched to the Find1P1CPackage strategy for now; can still be convinced the extra machinery to async sweep them and tak'", "pin": null, "from_schema": 2 } ], "support": [ { "reviewer": "Yudis-bit", "reason": "tested on Windows", "substantive": false, "verdict": "Tested ACK", "id": "c:6286975704", "url": "https://github.com/bitcoin/bitcoin/pull/36578#issuecomment-6286975704", "at": "2026-10-20", "association": "NONE", "evidence": "tested", "areas": [] }, { "reviewer": "fametrano", "reason": "verified Assume(false) reproduces on master via sendrawtransaction and that this PR fixes it; agrees with keeping a mempool hook out of this PR", "substantive": true, "verdict": "Tested ACK", "id": "c:6395070625", "url": "https://github.com/bitcoin/bitcoin/pull/36578#issuecomment-6395070625", "at": "2026-10-25", "association": "CONTRIBUTOR", "evidence": "both", "areas": [ "net_processing.cpp" ] } ], "participants": [ { "login": "Yudis-bit", "stance": "support", "note": "Tested ACK on Windows", "association": "NONE", "comments": 1, "first": "2026-10-20", "last": "2026-10-20" }, { "login": "ismaelsadeeq", "stance": "objection", "note": "suggests proactive orphanage cleanup via TransactionAddedToMempool rather than reactive cleanup", "association": "MEMBER", "comments": 2, "first": "2026-10-21", "last": "2026-10-21" }, { "login": "fametrano", "stance": "support", "note": "Tested ACK; verified Assume(false) bug on master and fix with this PR, agrees with reactive cleanup", "association": "CONTRIBUTOR", "comments": 1, "first": "2026-10-25", "last": "2026-10-25" } ], "derivation": "substantive support, no open objection (fametrano)", "model_state": null, "corrections": [], "notes": "Added fametrano's Tested ACK confirming the bug reproduction and fix, and supporting the reactive cleanup approach over mempool hooks." }, "dependencies": { "depends_on": [], "enables": [] }, "categories": [ { "name": "p2p", "member": true, "evidence": "Carries the P2P label and modifies orphan handling and package transaction download in src/node/txdownloadman_impl.cpp and src/net_processing.cpp.", "band": "P3", "reason_tag": "bug fix", "score": 0.45, "factors": { "bug_severity": 1, "leverage": 0, "performance": 0, "security_stability": 1, "user_value": 0 }, "rationale": "Fixes an orphan handling edge case where orphans admitted to the mempool via RPC trigger an Assume(false) assertion in net_processing. As described, 'An orphan that enters the mempool other than through peer relay (e.g. by RPC) stays in the orphanage, so Find1P1CPackage can pick it as the child of a reconsiderable parent, and package evaluation then reports it as MEMPOOL_ENTRY, which hits Assume(false).'" } ], "confidence": "high", "uncertainties": [], "needs": [] }, "cost_usd": 0.0, "source": { "record": "2026-10-26T01:22:49+00:00", "code": "2026-10-23T01:20:33+00:00", "judgments": 1 } }