#35286 rpc: add testsubmitpackage for 1p1c test submissions

ReviewabilityReviewsAgreementSize
#35286 instagibbs rpc: add testsubmitpackage for 1p1c test submissionsReady0Strong287 + 716 tests
  • Allow wallets to test 1-parent-1-child package acceptance and RBF without modifying the mempool
  • Enable pre-flight checks for CPFP fee bumping where aggregate feerates or sibling eviction are required
  • Ready to review
  • Concept approval citing the usefulness of dry-running 1p1c package acceptance for wallets (ismaelsadeeq)
  • Concept approval without stated reasons (w0xlt)
  • Suggests verifying downstream user demand before committing to maintain the new RPC (dergoegge)
  • Suggests splitting out the internal validation dry-run if RPC demand is not established (andrewtoth)
  • 287 lines added or modified outside tests
  • 716 lines added or modified in tests
  • 74 lines removed in total
  • 7 files, 2 commits
Mempool and policy#7 of 14
P3 · new feature
  • P3 because it enables dry-run package validation for wallet tooling without altering core mempool policy
  • Modifies validation internals for aggregate feerates and RBF evaluation without affecting relay or DoS rules
Ranking notes
RPC / REST / ZMQ#7 of 55
P2 · user request
  • P2 because it introduces the testsubmitpackage RPC to resolve an established gap for wallet developers
  • Fulfills a frequent feature request for pre-flight testing of CPFP packages without mutating mempool state
Ranking notes
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.

Goal

Adds the testsubmitpackage RPC method to dry-run validation of a single transaction or a 1-parent-1-child (1p1c) package without mutating the mempool. Updates mempool validation internals to support package feerate aggregation and RBF replacement detection during dry-run validation. Shared JSON serialization logic between submitpackage and testsubmitpackage is unified into a common helper.

Problem: Wallets constructing CPFP fee-bumping packages or evaluating package RBF have no way to pre-flight test package acceptance without actually modifying the mempool. The testmempoolaccept RPC does not calculate aggregate package feerates or sibling eviction across unconfirmed transactions, while submitpackage immediately inserts valid transactions into the mempool.

Evidence of importance:

  • PR description: 'Intended as a wallet pre-flight check for CPFP fee-bumping packages. Enables rbf and sibling eviction evaluation, just like submitpackage.'
  • PR description: 'This is a partial addressing of https://github.com/bitcoin/bitcoin/issues/32160, hopefully addressing most of the missing functionality people are requesting.'

Scope: The PR intentionally limits multi-transaction testing to strict 1p1c bundles where the parent cannot enter the mempool on its own, avoiding the need for complex state unrolling of accepted subpackages.

Risk of a mistake: medium (mempool_policy, rpc_api, validation). Modifies mempool acceptance logic in validation.cpp, where logic errors or violated assertions during dry-run package evaluation could cause node crashes or return misleading fee and replacement results to wallets.

Changed since the previous assessment: Added a commit ('validation: match submission in package test-accept') that aligns test acceptance with submitpackage by disallowing sibling eviction in the multi-transaction acceptance path and waiting to report transaction success until the entire package passes script checks.

Reviewability

Ready

Nothing known that would invalidate a review now.

Waiting on (from the thread read):

  • author: response to review feedback and suggestions from ismaelsadeeq, dergoegge, and andrewtoth 2026-10-21

Agreement

Strong

substantive support, no open objection (ismaelsadeeq)

Thread notes: Added andrewtoth's suggestion to split out the internal dry-run of ProcessNewPackage if there is no demand for the RPC.

Objections, suggestions, and questions:

ReviewerTypeHarm, request, or questionStatusMust beAuthor repliedQuote
ismaelsadeeq (member)suggestion, maintenancededuplicate shared code, args collection, help text, and logic between testsubmitpackage and submitpackage in rpc/mempool.cppopenansweredno2026-05-29: 'there are still opportunities to dedup things in `rpc/mempool.cpp` shared code of `testsubmitpackage` and `submitpackage`'
ismaelsadeeq (member)question, approachwhy allow_sibling_eviction is tied to test_acceptopenansweredno2026-05-29: 'why is `allow_sibling_eviction` tied to `test_accept`?'
ismaelsadeeq (member)suggestion, maintenancededuplicate the loop copying staged removals into replaced transactions across both test_accept sites with a helperopenansweredno2026-05-29: 'The loop that copies staged removals into replaced transactions is duplicated at both `test_accept` sites. A helper like `CollectStagedRemovals() `would dedup things'
ismaelsadeeq (member)suggestion, maintenancemake changeset access guarding consistent across both test_accept sitesopenansweredno2026-05-29: 'The two sites guard the changeset access inconsistently'
ismaelsadeeq (member)suggestion, maintenancesplit the individual-evaluation dry-run path out of ProcessNewPackage into its own functionopenansweredno2026-05-29: 'I think this is a good time to split the individual-evaluation dry-run path out of ProcessNewPackage into its own function.'
ismaelsadeeq (member)suggestion, maintenancefold test_no_mempool_mutation_on_success into test_basic_1p1c_cpfpopenansweredno2026-05-29: 'Can we fold `test_no_mempool_mutation_on_success` into `test_basic_1p1c_cpfp`'
ismaelsadeeq (member)suggestion, maintenanceconsider using unit tests or an evict RPC instead of generating blocks or restarting nodes to evict mempool transactions in testsopenansweredno2026-05-29: 'It seems like a hack to always generate a block when we want to remove a transaction or restart the node'
ajtowns (member)question, scopewhether it is possible to test transactions with nSequence relative locktimes spending out-of-mempool transactionsanswered · author pointed to issue 32142answeredyes2026-06-16: 'Would it be possible to somehow test txs with nSequence relative locktimes spending currently out-of-mempool txs?'
Status from: 2026-06-17: instagibbs: '@ajtowns https://github.com/bitcoin/bitcoin/issues/32142 I think?'
dergoegge (member)suggestion, usefulnesshave users who want this RPC state so explicitly to help decide whether to maintain itopenansweredno2026-07-01: 'it'd be helpful for users that want this to say so explicitly here, to help us decide if we should maintain this.'
andrewtoth (member)suggestion, scopesplit out just the internal dry-run of ProcessNewPackage into its own change if there is not yet indication of buy-in for the RPCopenansweredno2026-10-21: 'If there is not yet indication of buy-in for the RPC, could we instead split out just the internal dry-run of `ProcessNewPackage` into its own change?'

Support:

  • ismaelsadeeq (member) (Concept ACK, 2026-05-29): users normally test run submissions to see whether they will get through; so having `testsubmitpackage` rpc to test run 1p1c package is very useful.
  • w0xlt (contributor) (Concept ACK, 2026-06-24): (no reason given) [not substantive]

Participants:

  • ismaelsadeeq (member, support, 9 statements 2026-05-29 to 2026-06-16): Concept ACK citing value of pre-flight testing; suggested code deduplication and refactoring
  • ajtowns (member, question, 1 statements 2026-06-16 to 2026-06-16): asked whether testing out-of-mempool relative locktimes could be supported
  • w0xlt (contributor, support, 1 statements 2026-06-24 to 2026-06-24): Concept ACK without elaboration
  • dergoegge (member, neutral, 1 statements 2026-07-01 to 2026-07-01): suggested confirming downstream demand before maintaining the RPC, and asked for an update
  • andrewtoth (member, neutral, 1 statements 2026-10-21 to 2026-10-21): noted relevance for private broadcast, questioned RPC demand, and suggested splitting out the internal dry-run

Files

716 lines under test/bench/ci.

  • test/functional/rpc_testsubmitpackage.py +714/-0
  • src/rpc/mempool.cpp +220/-52
  • src/validation.cpp +59/-21
  • src/validation.h +5/-1
  • src/rpc/client.cpp +3/-0
  • src/test/fuzz/rpc.cpp +1/-0
  • test/functional/test_runner.py +1/-0

Card

The short text the ranking pass compares across PRs.

Adds the testsubmitpackage RPC command to test-validate a single transaction or a 1-parent-1-child package without mutating mempool state. Wallets constructing CPFP fee-bumps or testing replacement rules currently cannot dry-run package validation with aggregate package feerates and sibling eviction without actually submitting transactions to the mempool. To avoid complex state unrolling, it restricts packages to strict two-transaction child-with-parent topologies where the parent does not pass mempool acceptance on its own. The author notes this partially addresses issue #32160 by providing the package pre-flight testing functionality users requested.

Data

dossier JSON · extract JSON · model ledger, generated 2026-10-23T01:15, confidence high, input hash 91c16e96103d800b
thread read through 2026-10-21 (16 statements), head 98cdef3526
labels: RPC/REST/ZMQ · draft

Categories

Mempool and policy

P3 · new feature

Enables dry-run validation of 1p1c package acceptance and RBF evaluation without mutating mempool state. While worthwhile for package validation logic and wallet tooling, it does not alter core mempool policy, DoS limits, or relay rules.

Membership: Modifies mempool acceptance and package validation internals in src/validation.cpp to support package feerate aggregation and RBF replacement detection during dry-run validation.

Factors: security/stability 0, bug 0, performance 0, user value 2, leverage 1

RPC / REST / ZMQ

P2 · user request

Adds the requested testsubmitpackage RPC method to address an established gap where wallets could not pre-flight test CPFP packages or package RBF without mutating the mempool. The PR directly addresses user demand tracked in #32160, providing a significant missing capability for wallet developers.

Membership: Labeled RPC/REST/ZMQ and implements the new testsubmitpackage JSON-RPC method in src/rpc/mempool.cpp.

Factors: security/stability 0, bug 0, performance 0, user value 2, leverage 1