Bitcoin Core fixes pruning startup race for newly enabled indexes
Source report: 2026-09-18 · Editorial analysis published: 2026-09-20
Merged PR #36150 prevents a node from pruning blocks before a newly enabled index can synchronize. The change is in master and should not be confused with an installed release.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
The exact failure that was fixed
Bitcoin Core pull request #36150 was merged into the master branch on 11 September 2026 and highlighted by Bitcoin Optech on 18 September. The trigger was specific: start with an unpruned node, enable a new index and a pruning target at the same restart, then let startup pruning run before the empty index has established a lock on the blocks it needs. The node could remove block data first and then fail when the index tried to synchronize. The patch initializes the prune lock at the genesis height when the index has no best block, preserving the required history while initial indexing begins.
Which indexes are relevant
Optech identifies compact block filter indexing and UTXO-set statistics indexing as examples. A compact block filter index supports clients and services that query filters rather than downloading every transaction. A coinstats index accelerates selected UTXO statistics queries. These are node features, not ASIC hashrate controls, and enabling them does not increase mining speed. The operational link is infrastructure: pools, solo miners, monitoring systems and payout services often depend on reliable Bitcoin nodes. If the node cannot complete startup or an index is unavailable, downstream software may lose a data source even while the ASIC fleet itself remains powered.
Why the old behavior was expensive
Once blocks needed by the new index had been pruned, simply changing a setting could not recreate them from local storage. The pull-request discussion notes that the practical recovery could require a full reindex, which means reacquiring or rereading substantial chain data and waiting for index construction. On a remote mining site, that consumes bandwidth, disk I/O and maintenance time and may extend service degradation. The bug did not corrupt ASIC firmware or alter Bitcoin consensus. It was a startup ordering problem inside node index and pruning coordination, but operationally it could turn a routine configuration change into a long recovery window.
Merged code is not an installed release
The GitHub page confirms that the change is merged into Bitcoin Core's master branch and associated with the 32.0 milestone. That does not prove that a production node already contains it, and operators should not download an arbitrary master build to obtain one fix. Check the version actually running, the release notes for the package being considered and the maintainer's signed distribution channel. If a released build without the patch must be reconfigured today, avoid enabling a fresh index and pruning in the same restart. Sequence the work so the index finishes while the required blocks remain available, or follow a tested procedure from the package maintainer.
Plan the change before touching storage
Inventory datadir size, free space, current pruning state, enabled indexes, chain tip, index progress and backup coverage. Estimate how long a reindex would take on the site's hardware and network, then decide whether the maintenance window can tolerate that worst case. Confirm that dependent pool or monitoring services have another healthy node before taking one offline. Copy configuration and service-unit files, but do not treat a copied blockchain directory as a guaranteed portable backup while the node is running. Use documented shutdown and snapshot procedures, and retain logs showing the exact arguments used on the first restart.
Post-restart verification
After restart, confirm that the node follows the expected chain tip, peer count is reasonable and each requested index reports progress rather than an immediate failure. Watch disk usage and I/O, because an initial index can create sustained load. Query the exact RPCs used by mining or payout software from a staging client. Validate block-template or pool workflows separately; index synchronization alone does not prove that every dependent service works. Keep the previous node available until the new path has passed a defined observation period. If progress stalls, preserve logs and stop changing multiple variables at once so the cause remains diagnosable.
Scope and security boundary
PR #36150 is a reliability fix for a configuration transition. The public discussion does not describe remote code execution, stolen funds, invalid blocks or a network consensus split. Operators should not label it a critical security vulnerability without evidence. It is still important because node availability is part of mining resilience, and a poorly planned storage transition can disable services at the worst time. Classify the incident accurately, prioritize according to whether your nodes use both pruning and new indexes, and keep broader node-hardening work—authentication, network segmentation, signed binaries and least privilege—on its own schedule.
What operators should do now
First, determine whether any node is about to enable pruning and a previously absent index together. If not, the narrow trigger may not apply to the planned change. Second, check the installed release and package documentation rather than assuming master code is present. Third, test the exact transition on a noncritical node with enough disk space and a measured recovery plan. Finally, track the release that first ships the merged fix and verify its signed checksum before deployment. The main lesson is procedural: storage-saving changes and new data services compete for the same historical blocks, so sequencing and rollback evidence belong in the change ticket.
Evidence for the change ticket
Attach the upstream PR, the package release note that includes it, signed binary checksum, pre-change index status, configuration diff, disk forecast and recovery estimate. After the test, add node logs, index completion time and results of the RPCs used by production services. Record whether a full reindex was avoided rather than assuming success from process uptime. This evidence allows another operator to repeat the procedure, lets reviewers distinguish upstream code from packaged software and provides a clean basis for rollback if later performance or storage behavior differs from the canary.
Source: Bitcoin Core / Bitcoin Optech ↗
Mining calculator ↗
