Bitcoin Core adds a mining debug category for block-template logs
Source report: 2026-09-29 · Editorial analysis published: 2026-10-01
A merged change moves the recurring CreateNewBlock weight line behind -debug=mining; it is on master and was backported to the 32.x branch, not yet a final release.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
A frequently repeated log line is no longer unconditional
Bitcoin Core maintainers merged pull request 36336 on September 29, 2026. It moves the CreateNewBlock block-weight message behind a new mining debug category. The line was previously written unconditionally whenever the node built a block template and could fill debug.log on systems that request templates frequently. After the change, operators who want that message enable it with -debug=mining, while installations that do not need the detail can avoid the repeated entry.
Pool and template operators should review logging settings
The release note specifically recommends that getblocktemplate users and Mining IPC users enable the mining category if they rely on these messages. Pools, solo-mining gateways and testing systems often create block templates far more frequently than an ordinary wallet node. A configuration that previously collected the line automatically may lose it after upgrading to a version containing the patch. Operators should audit log-based alerts, parsers and troubleshooting procedures before deployment.
The message reports block-template weight
CreateNewBlock constructs candidate blocks from the current chain tip and mempool subject to policy and consensus constraints. The affected message reports the weight of the candidate block. It can help developers inspect template behaviour, but it is not proof that a block was mined, submitted or accepted by the network. Moving the line into a category changes observability only; it does not change transaction selection, proof-of-work, block validity or mining rewards.
The new category follows Bitcoin Core’s debug controls
Bitcoin Core supports category-specific debug logging so operators can select the subsystems needed for diagnosis. With this patch, -debug=mining enables the block-template message, while a normal configuration can remain quieter. The exact command-line or bitcoin.conf syntax should be tested in staging, especially where service managers or container images generate arguments automatically. Enabling more logs also requires appropriate rotation and disk-retention limits on long-running pool infrastructure.
The patch is merged but not a new final release
The change was merged into the master branch after review and 27 automated checks. A maintainer also reported that the functional change was backported to the 32.x branch on September 30. A merged or backported patch is not the same as a final Bitcoin Core release package. Operators should wait for an official tagged release unless they already have a controlled process for building and validating development branches.
Existing parsers may need an explicit test
A review comment noted no noteworthy external projects found by searching for parsers of the exact CreateNewBlock weight line, but absence from a public search does not cover private pool tooling. Teams should search their own monitoring rules, log shippers and dashboards for the phrase before upgrading. A safe test generates repeated getblocktemplate requests with and without -debug=mining, confirms the expected message behaviour and checks that unrelated error logging remains visible.
Quieter logs reduce storage and signal noise
For a high-frequency template service, an unconditional line can create unnecessary disk writes and make important warnings harder to find. Category gating lets an operator choose between detailed mining diagnostics and a smaller general log. The benefit is operational rather than a hashrate or efficiency gain: it does not make the ASIC faster or reduce its electrical load. It can, however, improve log retention and simplify incident review on nodes supporting a mining pool.
Do not disable diagnostic data without a replacement
If a pool uses template-weight trends to detect unusual mempool conditions or block-assembly regressions, it should retain the mining category or collect equivalent metrics from a tested interface. Logs should also be rotated, timestamped and shipped to storage sized for the expected request rate. The right setting depends on the system’s purpose: a lightweight node may prefer minimal output, while a production pool may value complete template diagnostics during upgrades.
The next checkpoint is the official release
The verified facts are narrow: the pull request was merged, the message moved behind a mining category, the release note warns getblocktemplate and Mining IPC users, and the code was backported to 32.x. The final version number and release date are not established by this pull request. Operators should read the official release notes and signed binaries when the next release appears, then validate their exact logging configuration before production rollout.
Source: Bitcoin Core ↗
Mining calculator ↗
