Bitcoin Core advances the 32.x branch to release candidate 3
Source report: 2026-10-01 · Editorial analysis published: 2026-10-02
The rc3 version bump and regenerated documentation were merged on October 1 after 29 commits since rc2; operators should wait for signed official binaries and treat the candidate as test software.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
The 32.x branch now identifies as rc3
Bitcoin Core maintainers merged pull request 36400 on October 1, advancing the 32.x branch to version 32.0rc3. The pull request itself contains three commits: the version bump, regenerated manual pages and a regenerated example bitcoin.conf. It changed nine files and was merged as commit 2633a1de. This is a release-preparation milestone in source control, not an announcement that the final Bitcoin Core 32.0 release is available.
A release candidate is built for testing
Bitcoin Core’s life-cycle documentation explains that release candidates use rc suffixes such as rc1, rc2 and rc3. They give developers, node operators and downstream packagers a near-final build to test before a stable major release. A higher rc number does not by itself mean production approval. It means another candidate was prepared after changes or fixes, and testing may still reveal reasons for an rc4 or additional work.
The branch is 29 commits ahead of the rc2 tag
GitHub’s comparison of v32.0rc2 with the 32.x branch showed 29 commits at the time of verification. Those include code, tests, documentation, build adjustments and the rc3 version-generation commits. Counting commits is not a severity measure: a small operational fix can matter more than several documentation updates. Operators should read the final release notes and examine the specific subsystems they use rather than infer risk from the number alone.
The candidate carries several operational adjustments
Changes between rc2 and the current branch include fee-estimator fallbacks, clearing mined-block statistics when mempool state cannot be loaded, draining fee callbacks before shutdown state is saved, wording that marks private broadcast experimental and a mining debug category for a recurring block-template log. Each change has its own scope. The branch bump does not imply a consensus rule change, faster hashing or a change in proof-of-work.
The mining log change was backported separately
One included commit moves the CreateNewBlock weight message behind the mining debug category. ASIC.tools covered that patch separately because frequent block-template requests can generate repetitive logs. In rc3 context it is simply one backported operational change among many. Pool administrators who require that line will need the relevant debug setting in a release that contains it; they should not assume every installed node has already changed behavior.
Official rc3 binaries were not yet listed when checked
At the editorial check on October 2, the official Bitcoin Core download index still exposed the signed 32.0rc2 candidate directory dated September 22, while an rc3 directory was not yet available. Source-control preparation normally precedes reproducible builds, signatures and publication. This timing distinction prevents a merged version bump from being misreported as downloadable signed software. Availability can change later, so operators should check the official index and signatures at download time.
Pools should test the paths they actually use
Mining pools, solo gateways and template servers should stage candidates against getblocktemplate, fee estimation, mempool persistence, shutdown and restart, RPC authentication, monitoring and alerting. Test nodes should not share production wallet secrets. Operators should preserve comparable logs and metrics, verify candidate behavior under realistic template request rates and confirm that downstream Stratum or job-distribution software handles responses exactly as expected.
Verification matters more than a download link
When binaries appear, operators should use the official Bitcoin Core distribution location, verify SHA256SUMS and signatures, and compare the signer policy used by their organization. A release candidate should be installed in an isolated test environment first. Building from GitHub source requires pinning the exact commit and following the reproducible-build process. A link copied from a forum or mirror does not establish that the package corresponds to the reviewed branch.
What is confirmed and what remains pending
Confirmed facts are the merged rc3 branch bump, its three preparation commits, and 29 commits between the rc2 tag and the checked 32.x head. The official final 32.0 release was still pending, and signed rc3 binaries were not yet visible at the checked time. The next evidence is official candidate artifacts, reproducible-build attestations, tester reports and the stable tag. Production upgrades should follow those artifacts, not the branch name alone.
Source: Bitcoin Core ↗
Mining calculator ↗
