How to Verify a Bitcoin Core Download (SHA256 and GPG)

The integrity and security of Bitcoin node software stands as a cornerstone of the network’s trustless architecture. As the primary reference implementation of the Bitcoin protocol, Bitcoin Core’s distribution and verification process deserves careful examination, particularly as new versions are released and multiple distribution channels emerge.

The decentralized nature of Bitcoin development means that multiple legitimate sources exist for obtaining Bitcoin Core software. This multiplicity serves as both a strength and a potential source of confusion for users. While having various distribution points helps ensure censorship resistance and availability, it also creates a responsibility for users to verify the authenticity of their software sources.

Core to Bitcoin’s security model is the concept of reproducible builds and cryptographic verification. Each Bitcoin Core release is signed by multiple trusted developers, creating a web of trust that users can rely upon to verify the authenticity of their software. This process involves checking PGP signatures and comparing SHA256 hashes of downloaded binaries against publicly posted checksums.

The evolution of Bitcoin Core follows a deliberate and careful development process, with major version releases occurring only after extensive testing and peer review. This methodical approach helps maintain the network’s stability while introducing necessary improvements and security updates. Releases are numbered MAJOR.MINOR: Bitcoin Core aims for a new major version about every six months and ships maintenance releases, such as 31.2, that fix bugs. The project says this numbering does not follow semantic versioning.

Understanding official distribution channels becomes increasingly important as the Bitcoin ecosystem expands. Get the files from bitcoincore.org, the project’s own download site. bitcoin.org also offers Bitcoin Core, but it lags behind: in November 2026 it still offered 31.0, while bitcoincore.org had 32.1. Whatever the source, verify the files before you run them. This verification process exemplifies Bitcoin’s fundamental principle of ‘don’t trust, verify.’

The relationship between node software and wallet security deserves particular attention. While compromised node software could potentially impact transaction relay and network connectivity, proper security practices like hardware wallet usage provide critical protection for private keys. This layered security approach demonstrates the importance of understanding various attack vectors and appropriate mitigation strategies.

The broader implications of node software security extend beyond individual users to the entire network’s resilience. Each properly verified and correctly operating node strengthens Bitcoin’s decentralized architecture. This highlights why education about proper software verification procedures remains crucial for maintaining network security.

Looking forward, the Bitcoin Core development process continues to evolve, incorporating new security measures and distribution mechanisms. The emergence of reproducible builds, deterministic release processes, and improved verification tools demonstrates the community’s commitment to maintaining the highest security standards while preserving accessibility for users at various technical levels.

The fundamental lesson remains clear: in the cryptocurrency space, security consciousness and verification procedures should become second nature. Whether dealing with node software, wallet solutions, or any other critical component, users must develop and maintain robust security practices that align with Bitcoin’s trustless principles.

Step-by-Step Guide

Verifying Bitcoin Core software before installation protects your node from tampered binaries and supply-chain attacks. The following steps walk through the complete verification process from download to confirmed installation. Our lesson How to Verify Bitcoin Software Before You Install It explains what each check proves and applies the same method to Sparrow, node images and hardware wallet firmware.

How the four steps fit together. Step 1: from bitcoincore.org you download three files: the file for your system, SHA256SUMS, a list with one fingerprint per file, and SHA256SUMS.asc, the builders' signatures on that list. Step 2: from GitHub, a separate server, you import the builders' public keys (repository bitcoin-core/guix.sigs). Step 3, gpg --verify: the keys check the signatures, so you know the builders signed this list. Step 4, sha256sum or shasum --check: the line for your file on the list checks your copy. Both must pass: the signatures vouch for the list, and the list vouches for your file. — **The keys vouch for the list, and the list vouches for your file.** The keys come from GitHub and the files from bitcoincore.org, two separate servers. Steps 3 and 4 both have to pass before you install.

Download the Bitcoin Core release files
Navigate to bitcoincore.org/en/download/ and download three files: the binary package for your operating system, the SHA256SUMS file, and the SHA256SUMS.asc file containing developer signatures. Save all three files to the same directory on your machine.
Import the Bitcoin Core developer signing keys
Obtain the PGP public keys of the Bitcoin Core release signers. They live on GitHub, in the builder-keys folder of the bitcoin-core/guix.sigs repository. Bitcoin Core’s download page gives two commands: git clone https://github.com/bitcoin-core/guix.sigs, then gpg --import guix.sigs/builder-keys/*. Without git, the lesson linked above shows how to download the repository as a ZIP file and import the same keys. This provides you with the public keys needed to verify the release signatures.
Verify the PGP signatures on the checksum file
Run gpg --verify SHA256SUMS.asc SHA256SUMS in your terminal. You should see multiple “Good signature” lines from known Bitcoin Core developers. If you see “BAD signature” for any entry, stop immediately: delete the files, download them again from bitcoincore.org and repeat the check. At least several valid signatures from recognized developers should be present. Each one is followed by a Primary key fingerprint line. To be sure a key belongs to the builder it names, compare that fingerprint with one you got another way, for example from the builder’s own website or from the key you imported when you verified an earlier release.
Verify the SHA256 checksum of the binary
On Linux, run sha256sum --ignore-missing --check SHA256SUMS; on macOS, shasum -a 256 --ignore-missing --check SHA256SUMS. Both commands, as given on bitcoincore.org’s download page, should print OK for the file you downloaded. This confirms the downloaded binary matches the hash published by the developers. On Windows, run certutil -hashfile bitcoin-<version>-win64-setup.exe SHA256 (for example bitcoin-32.1-win64-setup.exe, the current release since 28 October 2026) and compare the output with the matching line in SHA256SUMS.
Compare the checksum against multiple independent sources
Cross-reference the SHA256 hash with the builders’ own results. In the guix.sigs repository from step 2, open the folder for your version (for example 32.1): each builder who finished the release build has published an all.SHA256SUMS file there, and its line for your file should match yours. Bitcoin Core’s releases page on GitHub carries no files or checksums; it points back to bitcoincore.org. If the hash matches across these independent builds, you have strong assurance that the binary has not been tampered with during distribution.
Install and confirm the running version
Proceed with installation. After launching Bitcoin Core, open the console (Window > Console) and type getnetworkinfo. Verify the reported version number matches the release you downloaded. Check the subversion field to confirm you are running the expected Bitcoin Core version string.
Set up a recurring verification schedule
Create a reminder to repeat this verification process with every new Bitcoin Core release. Bitcoin Core aims for a major release about every six months, with maintenance releases in between, and maintains only the latest three major versions. Follow the announcements feed on bitcoincore.org (bitcoincore.org/en/announcements.xml) or watch the GitHub repository releases page to receive notifications when new versions become available.

The lines to look for when you verify Bitcoin Core 32.1. Step 3, gpg --verify SHA256SUMS.asc SHA256SUMS, prints eight lines that start Good signature from, one for each builder who signed the release: Ava Chow, Ben Carman, Michael Ford, Oliver Gugger, Matthew Zipkin, sedited (Sebastian Kung), Sjors Provoost and Will Clark (shown here without their email addresses). Under each one gpg adds a WARNING that the key isn't certified. Everyone sees it until they certify the keys themselves: it means gpg can't tell you who owns the key, so compare the Primary key fingerprint it prints with the one you expected for that builder. Step 4, sha256sum --ignore-missing --check SHA256SUMS, prints one line naming your file and ending in OK, for example bitcoin-32.1-x86_64-linux-gnu.tar.gz: OK. A BAD signature, or FAILED for your file, means stop: delete the files, download them again from bitcoincore.org and check again. — **A pass is several good signatures, then OK for your file.** This is what Bitcoin Core 32.1 prints, as of November 2026. On macOS the second command is shasum -a 256 with the same options; on Windows, certutil prints the fingerprint for you to compare with your file’s line in SHA256SUMS.

Common Mistakes to Avoid

Skipping PGP Signature Verification

Many users download Bitcoin Core and verify only the SHA256 hash without checking the PGP signatures on the checksum file. This defeats the purpose of verification because an attacker who compromises the download server can replace both the binary and the SHA256SUMS file simultaneously. The PGP signatures provide the actual cryptographic link to the developers’ identities. Always verify signatures first, then check the hash.

Someone takes over the download server and swaps two files: the installer, and SHA256SUMS with a line that matches their installer. If you check only the checksum, their file matches their list, the command prints OK and you install their version. If you check the signatures as well, the builders' signatures don't match their list, gpg prints BAD signature and you stop before installing. Whoever controls the server can make the list match their file; only the builders' private keys make a good signature, so always check them. — **A checksum can’t tell you who wrote the list.** Someone who swaps the installer can swap SHA256SUMS too, and the checksum still says OK. If they replace SHA256SUMS.asc as well, gpg finds no key it knows: there is still no good signature from a builder.

Trusting a Single Download Source

Relying on a single website or mirror to download Bitcoin Core introduces a single point of failure. If that source is compromised, you have no independent reference point. Download from the official site but cross-check the hash against several builders’ own lists in the guix.sigs repository, which lives on GitHub, a different server from bitcoincore.org. This multi-source approach aligns with Bitcoin’s trust model.

Using Outdated Signing Keys

The set of developers who sign Bitcoin Core releases changes over time. Using an old keyring means you might miss valid signatures from new signers or continue trusting keys that have been revoked. Refresh your local keyring before each verification by pulling the latest keys from the guix.sigs repository. Check for key revocation certificates as part of your verification routine.

Bitcoin Core versions as of November 2026. 29.x, from April 2025, reached end of life on 27 October 2026: end-of-life versions don't generally get security fixes, so it's time to upgrade. 30.x (October 2025, latest 30.4), 31.x (April 2026, latest 31.2) and 32.x (October 2026, latest 32.1) are maintained: the latest three major versions get bug and security fixes. A new major version arrives about every six months. The one to run is the newest major version, at its latest release, 32.1. Every version you install gets the same four steps as this guide: download the files from bitcoincore.org, refresh your keys by importing them from guix.sigs again, check the signatures with gpg --verify, and check your file with sha256sum --check. — **A new major version about every six months, and every version you install gets the same check.** Bitcoin Core maintains its latest three major versions and recommends the newest one’s latest maintenance release. Refresh the builders’ keys each time: the people who sign change over time.

Running Unverified Software on a Machine with Wallet Data

Installing an unverified Bitcoin Core binary on a system that holds wallet files or private keys exposes those keys to potential theft. A compromised binary could exfiltrate wallet.dat or seed phrases silently. If you must skip verification for any reason, run the software on an isolated machine with no access to wallet data, and move to a verified installation before handling any funds.

Ignoring Reproducible Build Verification

Bitcoin Core supports reproducible (deterministic) builds through the Guix build system. This allows anyone to rebuild the release binaries from source and confirm they produce identical output. While this requires more technical skill, it provides the strongest possible verification. Dismissing this option when you have the capability to use it leaves a valuable security tool unused.

Bitcoin Core 32.1 as of November 2026. The bitcoin-core/guix.sigs repository on GitHub has a folder 32.1 with one folder per builder: 15 in all. 13 builders finished the last stage, and each one's all.SHA256SUMS file is identical to the SHA256SUMS you download from bitcoincore.org. 2 hadn't finished the last stage yet, and their results so far match too. 8 of the 13 signed the SHA256SUMS.asc you download. 15 people built 32.1 from the same source code with Guix, each on their own machine, and all their lists agree, so a tampered build would stand out. — **Many independent builds, one identical result.** This is the cross-check from step 5: open the folder for your version in guix.sigs, and each finished builder’s all.SHA256SUMS has the same line for your file as the SHA256SUMS you downloaded. Building the release yourself with Guix adds your own result to the comparison.

Frequently Asked Questions

What happens if I run a Bitcoin Core version that fails verification?

A binary that fails PGP or checksum verification may have been modified by a third party. Potential risks include altered consensus rules that could cause your node to follow a different chain, backdoors that leak private keys or wallet data, and modified transaction relay logic that could hold back or delay your transactions. Relay code can’t change where a transaction you have already signed pays, because the signature covers its outputs; a tampered wallet can swap the address before you sign, which is why you check it on your hardware wallet’s screen. Delete the binary immediately, report the issue to the Bitcoin Core security team, and re-download from a trusted source.

How many developer signatures should I expect on a Bitcoin Core release?

Recent Bitcoin Core releases have carried between eight and sixteen signatures from developers who took part in the Guix-based reproducible build process; 32.1, the current release in November 2026, has eight. The exact number varies per release. There is no fixed minimum, but seeing fewer than three valid signatures warrants additional investigation. Check the guix.sigs repository to see which builders participated in a given release.

Can I verify Bitcoin Core if I downloaded it months ago?

Yes. As long as you still have the original binary file, you can verify it at any time: download the SHA256SUMS and SHA256SUMS.asc files for that version from bitcoincore.org/bin, import the signing keys and follow the standard verification procedure. The checksums and signatures do not expire. A few withdrawn releases are no longer on bitcoincore.org: the files for 30.0 and 30.1 were removed in January 2026 after a wallet migration bug was found. For those, open the version’s folder in the guix.sigs repository, where each builder’s signed all.SHA256SUMS still lists the release’s files.

Is it safe to verify Bitcoin Core on Windows?

Windows supports the same verification process, though the tools differ slightly. Use Gpg4win for PGP verification and the built-in certutil command for SHA256 hashing. The verification itself is equally secure on any operating system. The primary risk on Windows is that the verification tools themselves could be compromised, so obtain Gpg4win from its official source and verify its installer as well.

Do I need to verify Bitcoin Core if I compile from source?

Compiling from source provides some additional assurance since you can inspect the code, but you should still verify the source code’s authenticity. Check that the Git commit you are building from is signed by a Bitcoin Core maintainer using git log --show-signature. Additionally, compare the Git commit hash against the tagged release on the official repository to ensure you are building the intended version.

Related Resources

Part of our free Bitcoin course: This topic is covered in How to Verify Bitcoin Software Before You Install It, from the Advanced Bitcoin Security & Privacy course.

Filed under: Bitcoin Security