Bitcoin Core adds bestblockhash to getmininginfo to avoid template races
Source report: 2026-09-14 · Editorial analysis published: 2026-09-19
Merged change lets mining software obtain the tip hash and next-target data from one consistent RPC snapshot.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
The merged change
Bitcoin Core pull request #36081 was merged into master on 14 September 2026. It adds a bestblockhash field to the getmininginfo RPC result. Mining software can already read next-height, nBits and target data from the response’s next object; with the new field it can also identify the exact chain tip from which those values were derived. The patch is merged development code, not proof that every deployed node already exposes the field.
The race between two RPC calls
Before the change, software needing both the best tip hash and next-block target commonly called getmininginfo and then getbestblockhash or getblockchaininfo. The chain tip can change between calls. The pair may then combine a hash from one tip with target data computed for another. The author highlighted same-height reorganizations near a retarget boundary, where competing tips may imply different next nBits. Rare does not mean harmless when a value feeds block-template construction.
Why one snapshot is safer
Returning all related fields under one internal chain-state lock gives the caller a coherent snapshot. The hash becomes a version marker: downstream software can associate the next-target fields with a particular tip and detect staleness when a newer tip appears. This does not remove reorganizations or replace getblocktemplate. It removes one avoidable inconsistency at the RPC boundary and gives pool software a simpler way to validate the state it consumed.
Deployment is not immediate
A merge into master enters the development line. Operators must check which released version eventually includes the commit and whether their distribution has backported it. Clients should feature-detect bestblockhash rather than assume it exists, especially across mixed node fleets. A safe rollout keeps the old two-call fallback with a consistency check, tests parsing against recorded responses, and updates monitoring before relying on the field for production decisions.
Tests for pool developers
Test normal tip advancement, a same-height reorg, a retarget boundary and a node restart. Confirm that cached templates are invalidated when bestblockhash changes even if height does not. Reject malformed or missing hashes without crashing and log both node version and field availability. If several Bitcoin Core nodes back a pool, ensure failover does not mix snapshots from different nodes. Metrics should count stale responses and fallback usage so compatibility problems are visible before rejected work increases.
Practical significance
The patch is small but follows a useful systems rule: data that must be interpreted together should be returned with a common version context. Pool operators gain no hashrate merely by adopting it, yet they can reduce a narrow class of template-state races and make diagnostics clearer. Track the eventual release notes, stage client support, and preserve existing safety checks. The GitHub pull request is the authoritative record for merge status, reviewed code and commit history.
Source: Bitcoin Core ↗
Mining calculator ↗
