WIP bitcoin_core_sv2 leverages getTransactionsByWtxid#625
Draft
plebhash wants to merge 17 commits into
Draft
Conversation
…idation context Restrict DeclareMiningJob stale-chain-tip classification to actual prev_hash drift and simplify related context state. - classify stale-tip strictly by prev_hash drift (v30x + v31x) - remove redundant min_ntime from ValidationContext - make jd-server drift checks prev_hash-only - prune now-unused BIP34 mempool plumbing/logging - remove unused timestamp from JdResponse::Success - keep timestamp handling local to handler checkBlock assembly - rename remaining timestamp references to ntime for clarity
…mempool_mirror_prev_hash Replace the expensive createNewBlock call (which assembles a full block template with mempool transactions) with a lightweight getTip query. Only the prev_hash is needed for stale-tip detection, so updating just the mirror's prev_hash via getTip is sufficient when the tip changed. Rename force_update_mempool_mirror to force_update_mempool_mirror_prev_hash to make the narrowed scope explicit.
…in-tip When a declared job is already stale at arrival (coinbase built from an old tip), checkBlock returns bad-cb-height but prev_hash may not have drifted during validation. Treat this rejection as stale-chain-tip so that JDC's non-fatal stale path is exercised instead of triggering a fallback.
BIP34 mismatch is no longer detectable on `BitcoinCoreSv2JDP`, which now solely relies on `prev_hash` to detect chain tip drifts that is fine, because if BIP34 drifted, `prev_hash` will be inevitably different that's why we're changing the shape of `assert_jdp_stale_chain_tip_scenario`
Cover the path where a declared job uses a coinbase built from a previous tip that is no longer the current tip at validation time. In this scenario checkBlock rejects with bad-cb-height while no in-handler prev_hash drift occurs, so the handler must map the rejection to stale-chain-tip.
Bitcoin Core submitBlock requires a fully assembled block, so JDS must retain non-coinbase transaction bodies from DeclareMiningJob validation. As a prerequisite for upcoming PushSolution handling with v32 IPC support, JdResponse::Success now carries txdata and no longer returns redundant txid_list. JDS derives txids directly from txdata when validating merkle-root/merkle-path consistency for SetCustomMiningJob, without storing an extra txid cache in DeclaredCustomJob. This addresses an earlier design blindspot and does not change v30/v31 validation behavior.
Reconstruct a full block at JDS when receiving PushSolution and submit it to Bitcoin Core via submitBlock. Follow the clarified Job Declaration semantics from sv2-spec. Reference: stratum-mining/sv2-spec#188 Reference: stratum-mining/sv2-spec#189 Design choice (KISS): JDS keeps only the latest declared custom job per downstream connection and only attempts PushSolution propagation against that entry. It does not attempt propagation for previously declared jobs.
Move MempoolMirror from v32x_v31x_v30x into a new v31x_v30x shared module tree, reflecting that it is only used by v30.x / v31.x runtimes. Update import paths across v30.x, v31.x, and v32.x to point at the new module locations.
plebhash
changed the title
bitcoin_core_sv2 leverages getTransactionsByWtxidbitcoin_core_sv2 leverages getTransactionsByWtxid
plebhash
changed the title
bitcoin_core_sv2 leverages getTransactionsByWtxidbitcoin_core_sv2 leverages getTransactionsByWtxid
plebhash
commented
Jul 19, 2026
Comment on lines
+353
to
+356
| let request = format!( | ||
| "{{\"jsonrpc\":\"2.0\",\"id\":\"v32-jdp-chain-tip\",\"method\":\"getblockheader\",\"params\":[\"{}\",false]}}", | ||
| tip_hash | ||
| ); |
Member
Author
There was a problem hiding this comment.
note to self:
updating ChainTipState with nbits from getblockheader causes issues whenever there's a difficulty adjustment
we should also call getmininginfo and use next.bits instead
Replace shared-v31 DeclareMiningJob handling for v32.x with a version-specific implementation that fetches declared transactions from Bitcoin Core via getTransactionsByWitnessID on every call. v32.x no longer maintains a local mempool mirror for transaction data. Instead it uses a lightweight ChainTipState that tracks prev_hash, nbits, and ntime (no tx cache). A dedicated v32.x background monitor refreshes this state via waitNext. Missing transactions are detected by empty responses from Core's witness-id lookup, with ProvideMissingTransactionsSuccess payloads supplementing the per-request map on retry.
Move v31.x JDP declare handler and background monitor from shared v32x_v31x sources into v31x-local modules. The only cross-version JDP artifact remaining between v31.x and v32.x is the shared error definition included via #[path]. Remove the now-unused v32x_v31x/job_declaration_protocol/handlers.rs and drop the v32x_v31x namespace marker module.
plebhash
force-pushed
the
2026-07-09-get-transactions-by-wtxid
branch
from
July 19, 2026 17:54
8c79db8 to
64fa59b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
close #268
builds on top of:
bitcoin_core_sv2JDPValidationContext#617handle_push_solutiononjd_server_sv2+bitcoin_core_sv2#593NOT READY FOR REVIEW