Repository navigation
mempool: hand template selections the pool's own tx bodies - #949
Conversation
select_block_template deep-copied every selected tx, up to 4 MB per call, though the pool already keeps each body as an Arc<Transaction>. It now returns those Arcs, so GBT and the SV2 template builder cost a pointer per tx, and a template that outlives the tx's eviction or replacement still holds the body. generate copies only for the block it mines. No behavior change; the SV2 TP's fee push will keep many same-tip templates and needs the bodies shared. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
The selection change is sound. ActiveMempool::select_block_template hands out the pool's own Arc<Transaction> under the same lock as the graph walk, get_tx was already that map, and the callers that need an owned body (generate, solution assembly) still clone. Holding a template past eviction or replacement is the named RAM trade, and it is what a template has to do so RequestTransactionData and SubmitSolution survive a replacement.
Required checks are green. This is the right base for the fee-push stack.
Non-blocking: MempoolHub::select_block_template is the cross-crate surface and its rustdoc still only talks about fee and sigop metadata. A sentence there that the Arc keeps the body alive after eviction would match the note already on ActiveMempool.
Plan D lands on top of sv2/plan-c-fee-push (reardencode reardencode#949, reardencode#951), which supplies the Arc<Transaction> template bodies and the 64-slot same-tip retention that validated jobs now rely on instead of a pin. Readers coming from sv2-spec discussion reardencode#239 also get the pointer to the Core-IPC implementation of the same messages (sv2-tp reardencode#137). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Plan D lands on top of sv2/plan-c-fee-push (reardencode reardencode#949, reardencode#951), which supplies the Arc<Transaction> template bodies and the 64-slot same-tip retention that validated jobs now rely on instead of a pin. Readers coming from sv2-spec discussion reardencode#239 also get the pointer to the Core-IPC implementation of the same messages (sv2-tp reardencode#137). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Plan D no longer stacks on sv2/plan-c-fee-push (merged as reardencode#949 and reardencode#951) and its D1 step is upstream: reardencode#959 moved the proposal check onto ChainHub, reardencode#963, reardencode#967, reardencode#968, and reardencode#969 made it complete, one decode per parent, bounded, and right about spent coins after a reorg. Name those as the prerequisites and why: the check is the job-validation hot path. Drop the two risks they closed (no script execution, reardencode#967; the per-input parent decode, reardencode#968), name both ends of the tip-change straddle the D11 journey now accepts, fix the "no scripts" CPU-trade lines, and remove the getblocktemplate bad-cb-amount changelog entry that reardencode#959 already carries. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Plan D lands on top of sv2/plan-c-fee-push (reardencode reardencode#949, reardencode#951), which supplies the Arc<Transaction> template bodies and the 64-slot same-tip retention that validated jobs now rely on instead of a pin. Readers coming from sv2-spec discussion reardencode#239 also get the pointer to the Core-IPC implementation of the same messages (sv2-tp reardencode#137). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Plan D no longer stacks on sv2/plan-c-fee-push (merged as reardencode#949 and reardencode#951) and its D1 step is upstream: reardencode#959 moved the proposal check onto ChainHub, reardencode#963, reardencode#967, reardencode#968, and reardencode#969 made it complete, one decode per parent, bounded, and right about spent coins after a reorg. Name those as the prerequisites and why: the check is the job-validation hot path. Drop the two risks they closed (no script execution, reardencode#967; the per-input parent decode, reardencode#968), name both ends of the tip-change straddle the D11 journey now accepts, fix the "no scripts" CPU-trade lines, and remove the getblocktemplate bad-cb-amount changelog entry that reardencode#959 already carries. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
MempoolHub::select_block_templatedeep-copied every selected transaction on each call (up to ~4 MB), though the pool already keeps each body as anArc<Transaction>. It now returns those Arcs, sogetblocktemplateand the SV2 Template Provider pay a pointer per transaction, and a template that outlives a transaction's eviction or replacement still holds its body.generatecopies only for the block it mines.No behavior change: same selection, same bytes, same JSON. Prerequisite for the SV2 TP fee-delta push (next PR), which keeps every template on the current tip per session and needs the bodies shared to keep that cheap.
Changes
ActiveMempool::select_block_template/MempoolHub::select_block_templatereturnVec<(Arc<Transaction>, Selected)>; the RAM trade (a held body outlives eviction) is named in the rustdoc.generate(rbitcoin-rpc), the SV2 template builder (Template.txs: Vec<Arc<Transaction>>), one journey assertion, two hub test asserts.docs/sv2-template-provider.mdPlan A) andchangelog.d/shared-template-txs.md.Local verification
-D warnings, deny, ast-grep,ci-os-smoke.shgreen.cargo test --workspacein Linux Docker (rust:1.95): 2726 passed, 0 failed.🤖 Generated with Claude Code