Verifying a Bitcoin Core download means confirming two properties before you run the software: integrity (the file was not altered during download) and authenticity (the checksum list was signed by Bitcoin Core release maintainers). You check integrity by computing the SHA-256 hash of the downloaded binary and matching it against the official SHA256SUMS file. You check authenticity by verifying the PGP signature on that SHA256SUMS file against trusted developer keys. Both checks are required because an attacker who controls a mirror or intercepts your connection could serve a malicious binary with a matching checksum. Only the cryptographic signature proves the checksum list originated from someone holding a recognized private key. This guide covers why both checks matter, what files you need, step-by-step verification on Windows, macOS, and Linux, how to evaluate signing keys, what to do when verification fails, and optional hardening through reproducible builds. Commands reference Bitcoin Core 30.2, the latest stable release as of April 2026 (source: Bitcoin Core).
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary technical sources include the Bitcoin Core official download and verification instructions at bitcoincore.org, the verify-binaries script documentation in the bitcoin/bitcoin GitHub repository (contrib/verify-binaries/README.md), the guix.sigs repository listing release signing keys at github.com/bitcoin-core/guix.sigs, and GnuPG documentation at gnupg.org. Version data current as of April 2026.
Why do you need both a hash check and a signature check?
A hash check proves the bits on your disk match a published checksum. A signature check proves the person who published that checksum controls a recognized private key. Without the signature, an attacker who compromises a download mirror or performs a man-in-the-middle attack can replace both the binary and the checksum file, and a hash-only verification would still pass. The standard workflow verifies the signature first, then the hash. Reversing that order wastes effort because a valid hash against an unsigned or forged checksum file proves nothing about authenticity.
What the hash proves and what it does not
The SHA-256 hash function takes an input of any size and produces a fixed 64-character hexadecimal output. If even a single bit changes in the input, the output changes unpredictably. When the hash you compute locally matches the corresponding line in SHA256SUMS, you know the file on your disk is byte-for-byte identical to the file the developers published. The hash does not tell you who created the checksum file. It does not tell you whether the binary is free of bugs. It confirms the identity of the file, not origin or safety.
What the signature proves and what it does not
A PGP signature over SHA256SUMS proves that someone holding a specific private key signed that exact file and that the file has not been modified since signing. If you have independently verified the corresponding public key fingerprint against official sources, you can attribute the signature to a Bitcoin Core release maintainer. The signature does not prove the developers' machines were clean when they built the binary. It does not prove the code is free of vulnerabilities. It proves the origin and integrity of the checksum list itself.
Why order matters
Verify the signature on SHA256SUMS first. If the signature is invalid, every hash comparison against that file is meaningless. Only after confirming "Good signature" from a trusted key should you compute the hash of your downloaded binary. This order prevents a false sense of security from a hash match against a forged checksum file.
What files do you need before starting?
You need exactly three files in the same directory, all downloaded from the same release version at the official domain.
The three required files are the platform binary (for example bitcoin-30.2-x86_64-linux-gnu.tar.gz on Linux, bitcoin-30.2-arm64-apple-darwin.dmg on macOS, or bitcoin-30.2-win64-setup.exe on Windows), the SHA256SUMS plain text file listing official checksums for every release binary, and the SHA256SUMS.asc file containing the detached PGP signatures over SHA256SUMS.
Download all three from the official release directory at https://bitcoincore.org/bin/bitcoin-core-30.2/. Verify the URL shows bitcoincore.org (not a .com variant or lookalike domain) and that your browser shows a valid HTTPS certificate. Bookmark the official site to avoid clicking promoted search results that may lead to phishing pages.
Common mistakes at this stage include downloading from GitHub releases or third-party mirrors that may lag behind or omit the signature file, renaming files after download (verification commands expect exact original filenames), mixing files from different release versions, and downloading over plain HTTP where a network attacker can substitute files silently.
How do you verify the signature on SHA256SUMS?
This step confirms the checksum file was signed by Bitcoin Core release maintainers. You need GnuPG (version 2.2 or later recommended) installed and the relevant signing keys imported into your keyring.
Import signing keys
Bitcoin Core releases are signed by multiple developers. Their public keys are collected in the guix.sigs repository at https://github.com/bitcoin-core/guix.sigs under the builder-keys directory. Clone the repository and import the keys:
git clone https://github.com/bitcoin-core/guix.sigs.git
cd guix.sigs/builder-keys
On Linux or macOS: for key in *.gpg; do gpg --import "$key"; done
On Windows PowerShell: Get-ChildItem *.gpg | ForEach-Object { gpg --import $_.FullName }
You do not need to import every key. Choose several developers whose identities you can verify through independent channels, then import those.
Run the verification command
Navigate to the directory containing your three downloaded files and run:
gpg --verify SHA256SUMS.asc SHA256SUMS
A valid result looks like this:
gpg: Signature made [date] using RSA key ID [KEYID]
gpg: Good signature from "Developer Name <email>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: E777 299F C265 DD04 7930 70EB 944D 35F9 AC3D B76A
The critical elements: "Good signature" means the cryptographic math checks out. The fingerprint must match what you have verified from official sources. The "not certified" warning is normal and expected because you have not established a local GPG web-of-trust path to the key. It does not indicate a problem. You handle trust by manually verifying the fingerprint, not by relying on GPG's trust database.
Pass or fail decision
If you see "Good signature" and the fingerprint matches your independently verified records, proceed to the hash check. If you see "BAD signature," stop immediately. Do not install anything. Re-download SHA256SUMS.asc from the official site and try again. If the bad signature persists, delete all files and start over on a different network connection. If you see "no public key," you have not imported the signing key. Import it from guix.sigs and retry.
How do you verify the hash of your downloaded binary?
After confirming a valid signature, compute the SHA-256 hash of your downloaded binary and compare it character-by-character against the corresponding line in SHA256SUMS.
Find the expected hash
Open SHA256SUMS in a text editor. Each line contains a 64-character hex string followed by the filename. Locate the line matching your platform binary. For example:
a1b2c3d4... bitcoin-30.2-x86_64-linux-gnu.tar.gz
Compute the hash
The command varies by operating system:
Linux: sha256sum bitcoin-30.2-x86_64-linux-gnu.tar.gz
macOS: shasum -a 256 bitcoin-30.2-arm64-apple-darwin.dmg
Windows PowerShell: certutil -hashfile bitcoin-30.2-win64-setup.exe SHA256
Compare the output
Place the computed hash and the expected hash side by side. All 64 characters must match exactly. Do not rely on visual scanning alone for strings that look similar. Use your terminal's search function or paste both strings into adjacent lines in a text editor and compare character by character.
A faster method on Linux and macOS passes the check directly:
Linux: sha256sum --check SHA256SUMS --ignore-missing
macOS: shasum -a 256 --check SHA256SUMS --ignore-missing
Expected output: bitcoin-30.2-x86_64-linux-gnu.tar.gz: OK
The --ignore-missing flag skips files listed in SHA256SUMS that are not present in your directory. If the output shows anything other than "OK," the file does not match. Do not install it.
OS-specific walkthrough: Windows
Install GnuPG by downloading Gpg4win from https://gpg4win.org/ and running the installer. Restart PowerShell after installation. If PowerShell does not recognize gpg, use the full path: "C:\Program Files (x86)\GnuPG\bin\gpg.exe".
Import keys, verify the signature, and compute the hash using the commands in the sections above. The Windows-specific hash command is certutil -hashfile bitcoin-30.2-win64-setup.exe SHA256. Compare the output against the matching line in SHA256SUMS.
One Windows-specific issue: SHA256SUMS uses Unix-style line endings (LF). This rarely causes problems for manual comparison but can affect automated scripts. If you use a script to compare hashes, ensure it handles LF line endings correctly.
OS-specific walkthrough: macOS
Install GnuPG with Homebrew (brew install gnupg) or download GPG Suite from https://gpgtools.org/. Note that macOS Gatekeeper performs its own code-signing check against Apple's certificates. That check is separate from and does not replace Bitcoin Core's release verification. You must still verify the PGP signature and SHA-256 hash yourself.
Use shasum -a 256 for hash computation. The --check flag with --ignore-missing provides automated comparison against SHA256SUMS.
OS-specific walkthrough: Linux
GnuPG is available through your distribution's package manager: sudo apt install gnupg on Debian and Ubuntu, sudo dnf install gnupg2 on Fedora, or sudo pacman -S gnupg on Arch. Use sha256sum for hash computation. The --check and --ignore-missing flags work the same way as the macOS equivalent.
The filename in your directory must exactly match the filename in SHA256SUMS. If you renamed the file after downloading, the check will fail even if the file contents are identical.
How do you verify signing keys safely?
The signature is only meaningful if you verified you have the correct public key. An attacker who compromises your download could provide their own key and matching signature.
The fingerprint verification rule
Never trust a key solely because it appeared on a keyserver or came bundled with a download. Keyservers host any key that anyone uploads, and short key IDs can have collisions. Always verify the full 40-character fingerprint, not just the 8-character short ID.
Get the fingerprint from your local keyring with gpg --fingerprint [KEY_ID], then compare against at least two independent sources: the official Bitcoin Core download page, the guix.sigs repository on GitHub, and announcements on the bitcoin-dev mailing list or well-known community documentation.
Running a Bitcoin node yourself gives you direct access to the network for verifying software integrity claims. Operators who have gone through this verification process firsthand know the "not certified" GPG warning is the single most common point of confusion for newcomers. The warning text sounds alarming, but it reflects GPG's trust model, not a problem with the signature. Once you verify the fingerprint manually against two independent sources, the warning is resolved at the knowledge level even if GPG continues to display it.
Automated verification script
Bitcoin Core includes a Python script at contrib/verify-binaries/verify.py in the source repository that automates both signature and hash verification. It downloads SHA256SUMS and SHA256SUMS.asc, validates signatures against a plurality of known keys, then checks binary hashes. Usage: ./contrib/verify-binaries/verify.py pub 30.2. This script is convenient but still requires you to have imported and verified the keys you trust.
What should you do when verification fails?
Most failures have straightforward causes. Work through them methodically before concluding something adversarial happened.
Hash mismatch causes ranked by likelihood
Incomplete download (most common): the download was interrupted or resumed incorrectly. Re-download the binary from scratch. Wrong file or wrong line in SHA256SUMS: you selected the hash for a different platform or version. Double-check the filename. File corruption during transfer: rare over HTTPS but possible. Re-download. Antivirus modification: some antivirus software modifies executables on disk. Check your antivirus quarantine log. Disk error: storage medium corruption can silently alter file contents.
When to abort entirely
Delete all three files and start over on a different network connection if you see "BAD signature" that persists after re-downloading SHA256SUMS.asc, if a hash mismatch survives two complete re-downloads of the binary, or if you have any reason to suspect your network is being tampered with (public WiFi, captive portal, VPN provider you do not trust). Starting over means downloading all three files fresh, not just the one that failed.
Optional hardening: reproducible builds
Reproducible builds allow anyone to compile Bitcoin Core from source and produce byte-for-byte identical binaries to the official release. Multiple independent builders publish their attestations in the guix.sigs repository. If several builders produce the same hash, you have strong evidence the released binary matches the public source code with no hidden modifications inserted during compilation.
Bitcoin Core has achieved reproducible builds since version 0.21, with each release verified by multiple independent builders. For detailed instructions on reproducing a build yourself, see https://bitcoincore.org/en/contribute/reproducible-builds/.
This step is worth the effort when you are securing substantial holdings on a node, when you want cryptographic proof that the binary matches source code, or when you do not fully trust any single build environment. For most users, verifying the signature and hash is sufficient protection against the common attack vectors of download tampering, mirror compromise, and network interception.
Pre-installation checklist
Complete these steps in order before running Bitcoin Core:
Download three files from bitcoincore.org/bin/bitcoin-core-30.2/: the platform binary, SHA256SUMS, and SHA256SUMS.asc.
Import signing keys from guix.sigs/builder-keys.
Run gpg --verify SHA256SUMS.asc SHA256SUMS and confirm "Good signature" with a fingerprint matching your independently verified records.
Compute the hash of your binary (sha256sum, shasum -a 256, or certutil -hashfile depending on your operating system).
Compare the computed hash against the matching line in SHA256SUMS. All 64 characters must be identical.
Only then install and run Bitcoin Core.
If any step fails, do not proceed. Re-download and retry, or start over on a different network.
Frequently asked questions
What does it mean to verify a Bitcoin Core download in plain terms?
It means proving two things about the file on your disk before you run it. First, you confirm the file is identical to what the developers published by comparing its SHA-256 hash against the official checksum list. Second, you confirm that the checksum list was actually signed by recognized Bitcoin Core release maintainers by checking a PGP signature against their verified public keys. Together these two checks catch tampered downloads, corrupted transfers, and files served from compromised mirrors. Verification takes a few minutes and requires GnuPG software plus three files downloaded from the official site.
Can I skip the signature check and just verify the hash?
No. A hash check alone confirms the file matches some published checksum, but it does not confirm who published that checksum. An attacker who can replace the binary on a download mirror or during a network interception can also replace the SHA256SUMS file with one listing the hash of their malicious binary. Your hash check would pass against the forged checksum. The signature is the only part of the process that ties the checksum list to a specific private key held by a Bitcoin Core release maintainer.
What does the "not certified with a trusted signature" GPG warning mean?
This warning appears because you have not established a local GPG web-of-trust path to the signing key. It is expected behavior during Bitcoin Core verification and does not mean the signature is invalid. The warning disappears if you sign the developer's key with your own GPG key, but that step is unnecessary. What matters is that the fingerprint printed by GPG matches the fingerprint you verified from at least two independent official sources. The cryptographic verification is separate from GPG's trust-database bookkeeping.
How do I verify on Windows without Linux tools?
Install Gpg4win from gpg4win.org for signature verification. Use the built-in PowerShell command certutil -hashfile [filename] SHA256 for hash verification. The full Windows walkthrough appears in the OS-specific section above. No Linux tools are required.
My hash does not match. What are the most likely causes?
The most common cause is an incomplete or interrupted download. Re-download the binary entirely rather than resuming a partial transfer. The second most common cause is checking the wrong line in SHA256SUMS, typically because you selected the hash for a different platform or architecture. File modification by antivirus software is less common but does happen. Check your antivirus quarantine log if the mismatch persists after a clean re-download.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary technical sources include the Bitcoin Core official download and verification instructions at bitcoincore.org, the verify-binaries script documentation in the bitcoin/bitcoin GitHub repository (contrib/verify-binaries/README.md), the guix.sigs repository listing release signing keys at github.com/bitcoin-core/guix.sigs, and GnuPG documentation at gnupg.org. Version data current as of April 2026.
This article is for informational purposes only and does not constitute financial advice. Cryptocurrency trading involves substantial risk of loss. Past performance does not guarantee future results. Always conduct your own research and consider your financial situation before trading. BloFin does not guarantee the accuracy of third-party data referenced herein.