Bitcoin Core releases turn a changing source repository into identifiable source and binary artifacts. The process reduces ambiguity: users can name a version, reviewers can inspect a fixed tree, builders can reproduce outputs, and maintainers can issue targeted updates for supported release lines.
It does not eliminate trust or risk. A signed Git tag attests that a particular key signed a tag object pointing to a source commit. A checksum commits to file bytes through a digest. A signature over a checksum file attests that a key signed that checksum statement. Reproducible builds can show that multiple builders obtained matching output from specified source and build inputs. None of those alone proves the source is correct, the build environment is harmless, a signer is trustworthy, or a user’s machine is secure.
This guide was reviewed July 24, 2026 against the live lifecycle and download documentation, the v31.1 release process, and Bitcoin Core 31.1 commit 9be056a8a72b624dae9623b2f7bded92c2a21c91.
Development on the integration branch
Bitcoin Core development takes place through proposed patches, review, testing, and merges on the main integration branch. The README warns that this branch is not guaranteed to be completely stable.
A merged change is therefore not automatically a release. It may be revised before branch-off, excluded from a backport, disabled by configuration, or remain dormant pending a separate activation condition.
Release work creates a fixed boundary around selected commits. Reviewers should compare the release branch and tag rather than treating the current default branch as the software users downloaded.
Proposed schedules and freezes
Major-release planning is commonly tracked in a public issue with target dates for branch-off and release candidates. Schedules can include a feature freeze, translation milestones, or other coordination points.
These are proposed project-management dates. They can move as bugs, review capacity, translations, build issues, or test results change. A schedule issue is not a protocol commitment.
Feature freeze limits the kinds of new changes accepted while stabilization is underway. Translation freeze gives translators a stable text set. Neither means testing stops; release-candidate work is specifically for finding and correcting release blockers.
Release branches
Before a major release, the project creates a release branch. The integration branch can continue toward future development while the release branch receives selected stabilization, documentation, translation, and fix commits.
A maintenance release is normally made from the relevant supported release line. Backports should be narrower than importing the entire current development branch. The older the supported line, the higher the threshold for accepting changes because every backport introduces review and regression risk.
The lifecycle page reviewed July 24, 2026 says the latest three major versions are maintained. It lists 31.x, 30.x, and 29.x in the maintenance window and 28.x as end of life after the 31.0 release.
Release candidates
A release candidate, marked rc1, rc2, and so on, is a build proposed for wider testing before final release. A later candidate can include fixes discovered while testing an earlier candidate.
Release candidates should not be described as final merely because binaries exist. Their purpose is to test the near-final source, packaging, migration, wallet behavior, platform support, interfaces, and operational edge cases.
Testing includes automated suites, continuous integration, manual quality assurance, platform-specific checks, upgrade scenarios, and review of release notes. The amount and type of evidence varies by change.
Tagging and release notes
The release process uses tooling to perform consistency checks and create a signed Git tag for a release candidate or final release. The tag fixes the source tree at a named version.
A signed tag provides evidence that the holder of a particular key signed that Git object. A verifier still needs an independently obtained expectation for the key and must inspect what the tag points to. The signature does not prove that every line was reviewed or that the source has no vulnerability.
Release notes describe user-visible changes, compatibility, upgrade steps, known issues, and credits. They are an important map, not a substitute for source and tests. A missing note can hide a meaningful change; an imprecise note can overstate compatibility. Critical operators may need to inspect the diff and linked pull requests.
Major and maintenance releases
Bitcoin Core uses major versions such as 31.0 and maintenance versions such as 31.1. The lifecycle page says the project aims for a major release about every six to seven months and provides maintenance releases for bug and security fixes.
The word “major” is a project version category, not a claim that consensus changed. A major release can contain no consensus activation. The lifecycle document also explains that consensus-rule proposals are handled differently from ordinary semantic versioning and may be shipped in maintenance releases to produce smaller reviewable changesets.
Installing software that contains code for a consensus proposal does not necessarily activate it. Activation can depend on deployment parameters, network signaling, heights, times, or other separately specified conditions. A release note and deployment state must both be checked.
Supported branches and end of life
The maintenance window tells users which release lines generally receive fixes. End of life means a branch does not generally receive security fixes; it does not make the software stop running at a particular block.
Operators should compare their exact version with advisories and supported branches. “I run version 30” is incomplete because a later 30.x maintenance release may contain fixes absent from 30.0.
Upgrade urgency is risk-specific. A remotely exploitable validation defect differs from a wallet migration issue or an interface bug that affects only a disabled option. The advisory, release notes, configuration, and operating environment should determine the response.
Guix and reproducible builds
Bitcoin Core’s release process uses Guix-based tooling for reproducible builds. Builders check out the tagged source, use specified inputs, build outputs, and publish signed attestations of the checksums they obtained.
A reproducible build means independent builders using the specified process can produce byte-identical outputs for the covered artifact. Matching output reduces the risk that a distributor quietly substituted different code after source review.
It does not prove the source is secure or correct. Multiple builders can reproducibly build the same bug. They can also share a compromised dependency definition or overlooked toolchain weakness. Reproducibility supplies provenance evidence, not a formal proof of safety.
Checksums and multiple signatures
The official download page provides a SHA256SUMS file and a SHA256SUMS.asc collection of signatures.
A locally calculated checksum matching SHA256SUMS shows that the downloaded bytes match a listed digest. It does not identify who created the digest.
A valid signature on the checksum file shows that a particular key attested to those digests. Trust then depends on whether the verifier expected and trusts that key. Multiple independent signatures let a user compare attestations instead of relying on one key.
The release process describes combining attestations after multiple builders obtain matching results. This distributes evidence, but users still need to verify fingerprints through channels they consider independent.
Code signing is different
Windows and macOS platforms can use operating-system code signatures. Bitcoin Core’s release process handles detached platform signatures and combines them with reproducibly built unsigned artifacts.
Platform code signing can help an operating system identify the publisher key and detect changes to a signed package. It is not the same as a Git tag signature, a PGP signature over checksums, or a Guix build attestation.
A code-signed binary can still contain a bug. A valid signature can be created by a compromised key. A platform trust store can make a decision the user has not independently reviewed. Each signature should be described by what object was signed and which trust path is used.
Official distribution locations
The Bitcoin Core download page and versioned directory on bitcoincore.org are the project’s stated binary distribution locations. GitHub is used for source, tags, issues, and release metadata, but project release pages direct binary users to the official deterministic, signed downloads.
A file attached to a GitHub release is not automatically preferred or verified. Users should follow the current official verification instructions, not download a similarly named binary from an issue, fork, search result, or third-party mirror.
A torrent can distribute the same bytes, but the transport source does not replace checksum and signature verification.
Security fixes and disclosure timing
Security vulnerabilities can require coordinated fixes and delayed disclosure. The security policy defines private reporting paths, while public advisories identify affected versions, severity context, and fixed releases after disclosure.
Delay can reduce the time attackers have to exploit a flaw before users can upgrade. It also means public issue history is not always complete at release time.
A release containing a security fix may initially use limited language. Later disclosure can provide more detail. Researchers should date the evidence and avoid concluding that absence of a public issue means no security work occurred.
Upgrade and downgrade considerations
Release notes provide version-specific upgrade instructions and compatibility warnings. A typical upgrade requires shutting the old process down cleanly before starting the new binary.
Databases, chainstate formats, indexes, and wallets may be migrated. A successful upgrade does not guarantee that an immediate downgrade is safe. Older software may not understand newer data, and a rollback can require reindexing, restoring a backup, or recreating an index.
Wallet migration deserves additional caution because key and descriptor data may be changed. Operators should read the release notes for both directions, back up using documented procedures, and test operational runbooks before a high-value deployment.
Pruning and optional indexes can affect recovery time. Rebuilding from retained local data may not be possible if the needed block files were pruned.
A release is not consensus activation
A software release and a Bitcoin consensus activation are different events.
A release publishes code. Activation determines when a rule is enforced on a network. A release may contain no consensus changes. It may contain inactive code for a proposal. Multiple maintained branches may receive the same consensus-related patch. Alternative implementations may deploy compatible rules through different code.
Node operators are not automatically updated by the project. They choose whether and when to install. Miners and businesses make their own decisions. A maintainer cannot create network consensus by tagging a release.
For every claim that a release “changes Bitcoin,” identify the exact rule, deployment method, activation state, implementation versions, and observed network behavior.
A release-evidence ladder
Evaluate artifacts from narrowest to broadest:
- Release schedule: intended timing; not final code.
- Release branch: stabilization target; can still change.
- Release candidate: testable near-final artifact; not final.
- Signed tag: key attestation to a source reference.
- Release notes: human-readable change map.
- Reproducible-build attestations: evidence of matching outputs from specified source and inputs.
- Checksums: identity of downloaded bytes.
- Checksum signatures: signer attestations to those identities.
- Platform code signatures: operating-system publisher and integrity evidence.
- Independent testing and review: behavioral evidence for selected risks.
- Deployment observation: evidence of what users and the network actually run.
No single rung proves the whole system safe. Together they make the release more inspectable.