{
 "number": 36566,
 "input_hash": "b4e68c7592f6587d",
 "model": "ledger",
 "prompt_hash": null,
 "created": "2026-10-22T01:17:16+00:00",
 "result": {
  "summary": "Adds synchronous mempool acceptance waiting to BroadcastTransaction for private broadcasts, exposed via an optional timeout argument (defaulting to 10 minutes) on sendrawtransaction. It introduces a synchronous TransactionAddedToMempoolSync callback to CValidationInterface that fires immediately upon mempool insertion instead of routing through the background validation queue. Setting timeout to 0 allows callers to bypass waiting and preserve the previous non-blocking behavior.",
  "problem": "Private transaction broadcast skips local mempool insertion, returning immediately once queued for external broadcast. External software and third-party wallets calling sendrawtransaction expect a successful return to guarantee the transaction is already in the mempool. Furthermore, future wallet integration cannot wait on the asynchronous validation interface queue while holding cs_wallet without risking deadlocks or timeouts from blocked queue processing.",
  "card": "Private transaction broadcasts bypass local mempool insertion and return immediately upon queueing, breaking downstream software and wallets that expect sendrawtransaction to guarantee mempool presence. This pull request adds a synchronous TransactionAddedToMempoolSync callback to CValidationInterface and makes BroadcastTransaction block until the transaction is accepted into the mempool or times out, defaulting to 10 minutes. By bypassing the asynchronous validation queue, the synchronous notification allows callers holding the wallet mutex to wait without risk of deadlocks from blocked background events. Setting the new timeout RPC parameter to zero preserves immediate return. This synchronous wait is a stated prerequisite for supporting private broadcast in the Bitcoin Core wallet.",
  "evidence": [
   "PR description: \"Calling BroadcastTransaction with the NO_MEMPOOL_PRIVATE_BROADCAST method skips inserting the transaction into the mempool and returns immediately. This causes problems with software that expects the transaction to be in the mempool after the function returns. For example many third-party wallets or services call sendrawtransaction and expect the transaction to be in the mempool after it returns a successful response.\"",
   "PR description: \"Synchronously waiting for mempool acceptance is also a prerequisite for adding private broadcast support to the wallet. The TransactionAddedToMempoolSync method is added specifically for future wallet broadcasting, so a broadcast caller holding cs_wallet will not timeout waiting on another background event that is also trying to acquire cs_wallet.\""
  ],
  "scope_notes": "Adds a synchronous callback to CValidationInterface alongside the asynchronous queue, and introduces a timeout loop with periodic shutdown checks in BroadcastTransaction.",
  "changed_since_previous": "",
  "thread": {
   "last_event_at": "2026-10-21T17:22:09Z",
   "events": 1,
   "head_sha": "bccae015158c741ac16257ffccdc605fe1f49168",
   "schema_floor": 2,
   "schema": 2
  },
  "waiting_on": [
   {
    "at": "2026-10-21",
    "id": "c:6322161954",
    "on": "author",
    "url": "https://github.com/bitcoin/bitcoin/pull/36566#issuecomment-6322161954",
    "what": "address instagibbs's question regarding affected software and objection regarding wallet UX and double-spend risks"
   },
   {
    "at": "2026-10-21",
    "id": "c:6322161954",
    "on": "author",
    "url": "https://github.com/bitcoin/bitcoin/pull/36566#issuecomment-6322161954",
    "what": "response to instagibbs' question, suggestion for end-to-end integration, and UX safety concerns"
   }
  ],
  "risk": {
   "level": "medium",
   "touches": [
    "validation",
    "rpc_api"
   ],
   "why": "A synchronization or lock-order bug in the synchronous validation interface notification could hang RPC worker threads or disrupt transaction submission."
  },
  "discussion": {
   "author_status": "last statement processed 2026-10-21",
   "open_concerns": [
    "instagibbs: Can we gather a list of third-party software and services that expect transactions to be in the mempool after sendrawtransaction returns?",
    "instagibbs: Waiting synchronously for mempool acceptance can cause wallet operations to hang for up to 10 minutes, leading users to cancel and retry, which risks paying twice and losing funds.",
    "instagibbs: Synchronously waiting for mempool acceptance risks users accidentally paying twice if they abort a hanging broadcast and retry"
   ],
   "resolved_concerns": []
  },
  "reviewability": {
   "state": "Paused",
   "label": "Waiting on author",
   "reason": "Open objections from instagibbs with no author reply for 11 days; review would repeat what has been asked."
  },
  "agreement": {
   "state": "Blocked",
   "summary": "Blocked: objection that needs a change, nobody has replied (instagibbs)",
   "reason": "Initial record. instagibbs raised a question about which software requires synchronous mempool acceptance and objected that synchronous waiting can cause wallet hangs leading to double payments. / Initial review by instagibbs questioning the motivation for third-party software and raising safety concerns regarding wallet integration UX.",
   "evidence": [
    "instagibbs (question, usefulness, must be answered, open): Can we gather a list of third-party software and services that expect transactions to be in the mempool after sendrawtransaction returns?",
    "instagibbs (objection, safety, must be changed, open): Waiting synchronously for mempool acceptance can cause wallet operations to hang for up to 10 minutes, leading users to cancel and retry, which risks paying twice and losing funds.",
    "instagibbs (objection, safety, must be answered, open): Synchronously waiting for mempool acceptance risks users accidentally paying twice if they abort a hanging broadcast and retry"
   ],
   "objections": [
    {
     "reviewer": "instagibbs",
     "association": "MEMBER",
     "type": "question",
     "kind": "usefulness",
     "harm": "",
     "request": "",
     "question": "Can we gather a list of third-party software and services that expect transactions to be in the mempool after sendrawtransaction returns?",
     "text": "Can we gather a list of third-party software and services that expect transactions to be in the mempool after sendrawtransaction returns?",
     "clears_with": "answer",
     "blocking": false,
     "status": "open",
     "status_note": "",
     "cleared": false,
     "author_replied": false,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [],
     "evidence": "2026-10-21: 'Can we gather a list of these?'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36566#issuecomment-6322161954",
     "id": "c:6322161954",
     "at": "2026-10-21",
     "status_at": null,
     "status_by": null,
     "resolution_evidence": "",
     "pin": null,
     "from_schema": 2
    },
    {
     "reviewer": "instagibbs",
     "association": "MEMBER",
     "type": "objection",
     "kind": "safety",
     "harm": "Waiting synchronously for mempool acceptance can cause wallet operations to hang for up to 10 minutes, leading users to cancel and retry, which risks paying twice and losing funds.",
     "request": "",
     "question": "",
     "text": "Waiting synchronously for mempool acceptance can cause wallet operations to hang for up to 10 minutes, leading users to cancel and retry, which risks paying twice and losing funds.",
     "clears_with": "change",
     "blocking": true,
     "status": "open",
     "status_note": "",
     "cleared": false,
     "author_replied": false,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [],
     "evidence": "2026-10-21: 'Naively done, it could end up with some dangerous behavior for users, such as: ... broadens the scope of possible loss through unclear UX.'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36566#issuecomment-6322161954",
     "id": "c:6322161954#2",
     "at": "2026-10-21",
     "status_at": null,
     "status_by": null,
     "resolution_evidence": "",
     "pin": null,
     "from_schema": 2
    },
    {
     "reviewer": "instagibbs",
     "association": "MEMBER",
     "type": "objection",
     "kind": "safety",
     "harm": "Synchronously waiting for mempool acceptance risks users accidentally paying twice if they abort a hanging broadcast and retry",
     "request": "",
     "question": "",
     "text": "Synchronously waiting for mempool acceptance risks users accidentally paying twice if they abort a hanging broadcast and retry",
     "clears_with": "answer",
     "blocking": false,
     "status": "open",
     "status_note": "",
     "cleared": false,
     "author_replied": false,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [],
     "evidence": "2026-10-21: 'I just think this broadens the scope of possible loss through unclear UX.'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36566#issuecomment-6322161954",
     "id": "c:6322161954#3",
     "at": "2026-10-21",
     "status_at": null,
     "status_by": null,
     "resolution_evidence": "",
     "pin": null,
     "from_schema": 2
    }
   ],
   "support": [],
   "participants": [
    {
     "login": "instagibbs",
     "stance": "objection",
     "note": "asks which software needs this and objects that synchronous waiting could cause wallet hangs and duplicate payments",
     "association": "MEMBER",
     "comments": 1,
     "first": "2026-10-21",
     "last": "2026-10-21"
    }
   ],
   "derivation": "objection that needs a change, nobody has replied (instagibbs)",
   "model_state": null,
   "corrections": [],
   "notes": "Initial record. instagibbs raised a question about which software requires synchronous mempool acceptance and objected that synchronous waiting can cause wallet hangs leading to double payments. / Initial review by instagibbs questioning the motivation for third-party software and raising safety concerns regarding wallet integration UX."
  },
  "dependencies": {
   "depends_on": [],
   "enables": [
    "Private broadcast support in the wallet"
   ]
  },
  "categories": [
   {
    "name": "docs",
    "member": false,
    "evidence": "Only touches release notes alongside the code change.",
    "band": "Unranked",
    "reason_tag": "cleanup",
    "score": 0.0,
    "factors": {
     "bug_severity": 1,
     "leverage": 2,
     "performance": 0,
     "security_stability": 1,
     "user_value": 2
    },
    "rationale": "Updating release notes as part of a code change does not make the PR a documentation PR."
   },
   {
    "name": "mempool",
    "member": false,
    "evidence": "Does not change mempool policy, data structures, limits, or acceptance rules; it merely monitors when a broadcast transaction enters the mempool.",
    "band": "Unranked",
    "reason_tag": "bug fix",
    "score": 0.0,
    "factors": {
     "bug_severity": 1,
     "leverage": 2,
     "performance": 0,
     "security_stability": 1,
     "user_value": 2
    },
    "rationale": "Mempool data structures and policy rules are not touched by this change."
   },
   {
    "name": "p2p",
    "member": true,
    "evidence": "Carries the Private Broadcast label and alters the node's private transaction broadcast synchronization behavior.",
    "band": "P2",
    "reason_tag": "unblocks #N",
    "score": 0.65,
    "factors": {
     "bug_severity": 1,
     "leverage": 2,
     "performance": 0,
     "security_stability": 1,
     "user_value": 2
    },
    "rationale": "Provides the synchronization needed for external clients and unblocks private broadcast integration in the wallet. The PR description notes that waiting synchronously for mempool acceptance resolves issues where software expects transactions in the mempool post-broadcast, and is a prerequisite for adding private broadcast support to the wallet."
   },
   {
    "name": "rpc",
    "member": true,
    "evidence": "Touches src/rpc/mempool.cpp and src/rpc/client.cpp, adding an optional timeout parameter to sendrawtransaction.",
    "band": "P3",
    "reason_tag": "user request",
    "score": 0.4,
    "factors": {
     "bug_severity": 1,
     "leverage": 2,
     "performance": 0,
     "security_stability": 1,
     "user_value": 2
    },
    "rationale": "Fixes caller assumptions around sendrawtransaction by allowing callers to wait for mempool inclusion. The PR description notes that third-party wallets and services call sendrawtransaction and expect the transaction to be in the mempool after a successful response."
   },
   {
    "name": "tests",
    "member": false,
    "evidence": "The test modifications are functional tests specifically verifying private broadcast behavior.",
    "band": "Unranked",
    "reason_tag": "test coverage",
    "score": 0.0,
    "factors": {
     "bug_severity": 1,
     "leverage": 2,
     "performance": 0,
     "security_stability": 1,
     "user_value": 2
    },
    "rationale": "Tests validating a specific subsystem belong to that area rather than test infrastructure."
   },
   {
    "name": "utils",
    "member": false,
    "evidence": "Only touches src/common/messages.cpp for 4 lines of string translation.",
    "band": "Unranked",
    "reason_tag": "cleanup",
    "score": 0.0,
    "factors": {
     "bug_severity": 1,
     "leverage": 2,
     "performance": 0,
     "security_stability": 1,
     "user_value": 2
    },
    "rationale": "Minor message strings update incidental to the broadcast feature does not constitute a utility change."
   },
   {
    "name": "validation",
    "member": false,
    "evidence": "Touches src/validationinterface.h to add a callback without altering validation logic or chainstate invariants.",
    "band": "Unranked",
    "reason_tag": "cleanup",
    "score": 0.0,
    "factors": {
     "bug_severity": 1,
     "leverage": 2,
     "performance": 0,
     "security_stability": 1,
     "user_value": 2
    },
    "rationale": "Adding an event hook to CValidationInterface to bypass the async queue does not substantively alter transaction validation rules, chainstate, or consensus processing."
   }
  ],
  "confidence": "high",
  "uncertainties": [],
  "needs": []
 },
 "cost_usd": 0.0,
 "source": {
  "record": "2026-10-22T01:17:16+00:00",
  "code": "2026-10-20T01:18:56+00:00",
  "judgments": 7
 }
}