{
 "number": 36328,
 "input_hash": "4936175e16bf7e15",
 "model": "ledger",
 "prompt_hash": null,
 "created": "2026-09-29T01:25:21+00:00",
 "result": {
  "summary": "Updates `AcceptPackage` validation handling so package transactions evicted by `LimitMempoolSize()` immediately after acceptance return `TX_RECONSIDERABLE` with `FeeFailure` rather than `TX_MEMPOOL_POLICY`. This covers multi-transaction package submissions, transactions accepted individually earlier in the same call, and transactions already present in the mempool (including same-txid different-witness entries) that are subsequently trimmed. It also records the effective feerate and calculation inputs so package retry logic has the necessary context.",
  "problem": "When a package is accepted at the bottom of the mempool and pushes it over its size limit, the package transactions are immediately evicted. Because they return `TX_MEMPOOL_POLICY` rather than `TX_RECONSIDERABLE`, the evicted transactions (such as the parent in a 1p1c package) enter peer reject filters and cannot be fetched or re-evaluated with higher-fee child bumps until a new block arrives.",
  "card": "Updates package mempool acceptance so that transactions accepted and immediately evicted by mempool size limits return TX_RECONSIDERABLE instead of TX_MEMPOOL_POLICY. Previously, if a low-feerate package pushed the mempool over capacity and was trimmed, the parent entered peer reject filters, preventing subsequent higher-fee children from bumping it until the next block. The PR fixes this unneeded censorship across all trimmed package transactions by returning reconsiderable fee failure results. Author notes this was uncovered by Loupe and verified by Red Team.",
  "evidence": [
   "Author description: 'In-master, if a package is entered into mempool at the lowerst chunk feerate, pushing the mempool oversize, this causes that transaction (package) to be trimmed immediately... but the returned validation result TX_MEMPOOL_POLICY precludes the now-evicted parent from being considered again (i.e. fetched / processed as package) until after another block is found.'",
   "Author description: 'Related to finding made by Loupe, and subsequently Red Team.'"
  ],
  "scope_notes": "Small validation logic change in `MemPoolAccept::AcceptPackage()` with unit test coverage in `txpackage_tests.cpp` and functional coverage in `p2p_opportunistic_1p1c.py`.",
  "changed_since_previous": "",
  "thread": {
   "last_event_at": "2026-09-28T16:12:19Z",
   "events": 1,
   "head_sha": "3c6cd0c00ab3d81ec6c9615ed812a8976083749c",
   "schema_floor": 2,
   "schema": 2
  },
  "waiting_on": [
   {
    "at": "2026-09-28",
    "id": "c:5873964246",
    "on": "reviewer",
    "url": "https://github.com/bitcoin/bitcoin/pull/36328#issuecomment-5873964246",
    "what": "initial review"
   }
  ],
  "risk": {
   "level": "medium",
   "touches": [
    "validation",
    "mempool_policy"
   ],
   "why": "A mistake in package accept result classification or feerate tracking could bypass mempool reject filters or mishandle package eviction relay state."
  },
  "discussion": {
   "author_status": "last statement processed 2026-09-28",
   "open_concerns": [],
   "resolved_concerns": []
  },
  "reviewability": {
   "state": "Ready",
   "label": "Ready",
   "reason": "Nothing known that would invalidate a review now."
  },
  "agreement": {
   "state": "Crickets",
   "summary": "Crickets: no substantive comment either way",
   "reason": "Initial record. No participants or comments other than the author. / Initial record: PR opened by instagibbs, no reviewers or comments from others yet.",
   "evidence": [],
   "objections": [],
   "support": [],
   "participants": [],
   "derivation": "no substantive comment either way",
   "model_state": null,
   "corrections": [],
   "notes": "Initial record. No participants or comments other than the author. / Initial record: PR opened by instagibbs, no reviewers or comments from others yet."
  },
  "dependencies": {
   "depends_on": [],
   "enables": []
  },
  "categories": [
   {
    "name": "mempool",
    "member": true,
    "evidence": "Modifies `MemPoolAccept::AcceptPackage()` in `src/validation.cpp` to adjust package acceptance, eviction handling, and reject reasons.",
    "band": "P2",
    "reason_tag": "bug fix",
    "score": 0.65,
    "factors": {
     "bug_severity": 2,
     "leverage": 1,
     "performance": 0,
     "security_stability": 1,
     "user_value": 1
    },
    "rationale": "Package transactions evicted immediately upon acceptance due to `LimitMempoolSize()` return `TX_MEMPOOL_POLICY` instead of `TX_RECONSIDERABLE`, causing peer reject filters to reject subsequent higher-fee bumps until the next block. As the author notes, this bug was discovered by Loupe and Red Team, and fixing it restores proper reconsiderable status and package retry logic for 1p1c and multi-transaction packages under mempool pressure."
   },
   {
    "name": "p2p",
    "member": false,
    "evidence": "Does not alter P2P message handling or relay protocols; the functional test `test/functional/p2p_opportunistic_1p1c.py` only tests mempool acceptance behavior over P2P.",
    "band": "Unranked",
    "reason_tag": "bug fix",
    "score": 0.0,
    "factors": {
     "bug_severity": 2,
     "leverage": 1,
     "performance": 0,
     "security_stability": 1,
     "user_value": 1
    },
    "rationale": ""
   },
   {
    "name": "validation",
    "member": false,
    "evidence": "Touches `src/validation.cpp` purely within `MemPoolAccept`, which is mempool policy rather than consensus validation.",
    "band": "Unranked",
    "reason_tag": "bug fix",
    "score": 0.0,
    "factors": {
     "bug_severity": 2,
     "leverage": 1,
     "performance": 0,
     "security_stability": 1,
     "user_value": 1
    },
    "rationale": ""
   }
  ],
  "confidence": "high",
  "uncertainties": [],
  "needs": []
 },
 "cost_usd": 0.0,
 "source": {
  "record": "2026-09-29T01:25:21+00:00",
  "code": "2026-09-25T01:29:59+00:00",
  "judgments": 3
 }
}