How to Verify a Bitcoin Download Using Checksums and Signatures

14 October 2026

Downloading Bitcoin software from the wrong source - or from a compromised mirror - can mean handing your wallet to an attacker. A checksum confirms the file you received is byte-for-byte identical to what the developer published, and a cryptographic signature proves that the developer, not an impostor, published it. You should do both checks before running any Bitcoin software, and the process takes about ten minutes the first time.

Why Bother with Both Checks and Signatures?

A checksum alone is not enough. If an attacker can replace the download, they can also replace the checksum next to it on the same website. A signature, however, is created with a private key that only the developer possesses. You verify it with the developer's public key, which you obtain out-of-band - ideally from a key server or a secondary channel. Used together, the signature authenticates the file, and the checksum confirms nothing was corrupted or swapped during transfer.

What you need before you start

• The Bitcoin Core download page (bitcoincore.org) or your project's official site
• A terminal or command-line interface
• A copy of the developer's public key (for signatures)
• A tool like gpg (GNU Privacy Guard) for signature verification
• A tool like sha256sum (macOS/Linux) or certutil -hashfile (Windows) for checksums

Step 1: Download the Software and the Checksum File

Do not download from a random link in an email or a forum post. Go directly to the official Bitcoin Core website. On the download page you will see the installer or tarball, plus a file named something like SHA256SUMS and another like SHA256SUMS.asc. Download all three into the same folder.

The SHA256SUMS file contains a list of checksums for every official release binary. The .asc file is the detached signature for that checksum file.

Step 2: Verify the Checksum File's Signature

This is the step most people skip, and it is the one that catches a swapped checksum file. You need the developer's public key. For Bitcoin Core, the release signing key is published on the project's website, but you should verify its fingerprint against a second source - often a forum or a key server.

In your terminal, import the key:

gpg --import /path/to/bitcoin-release-key.asc

Then verify the signature on the checksum file:

gpg --verify SHA256SUMS.asc

You should see a line like Good signature from "Wladimir J. van der Laan <...>". If you see BAD signature, stop. Do not use the downloaded file. The signature being good means the checksum file, and therefore the checksums inside it, came from the project maintainers.

A note on trust: the first time you import a key, gpg will warn that the key is not trusted because you have not signed it. That is expected. The warning is not about the key's validity; it is about whether you have personally certified it. Check the fingerprint against a second channel before proceeding.

Step 3: Check the Checksum of the Downloaded File

Now compare the file you downloaded against the list in the verified SHA256SUMS file. On Linux or macOS, run:

sha256sum --check SHA256SUMS

This reads the file, hashes it, and compares it to the listed value. You will see an OK next to the matching filename. On Windows, you can use:

certutil -hashfile bitcoin-28.0-x86_64-setup.exe SHA256

Then open the SHA256SUMS file in a text editor and manually compare the strings. A visual match is fine for a one-off, but if you do this regularly, learn to script the comparison.

If you see FAILED or a mismatch, delete the download immediately. It is either corrupted or tampered with.

Step 4: (Optional but Recommended) Verify the File's Signature Directly

Some projects sign the binary itself, not just the checksum file. For Bitcoin Core, the detached signature on the SHA256SUMS file is the canonical one. But for other software, you may have a .sig file next to the installer. The command is:

gpg --verify file.tar.gz.sig file.tar.gz

The first argument is the signature, the second is the file. A good signature here means the file itself was signed, not just a list containing its hash.

What "good signature" does not mean

A good signature tells you the file came from the private key holder. It does not tell you that the software is bug-free or that it will not steal your coins if the developer is malicious or compromised. It also does not protect you if you import the wrong public key. An attacker who can redirect you to a fake website can also give you a fake "official" key. That is why you check the fingerprint out-of-band.

The other limitation: you are trusting the developer's machine. If that machine was hacked, the signed file could be malicious. This is a real but rare risk, and it is why large projects use multiple independent builders and reproducible builds. You are not expected to audit the code, but you can check that the binary matches what others built from the same source.

A practical suggestion for beginners

Do this on a clean machine the first time, or at least in a fresh folder. Write down the commands so you are not copying from a random blog post. And if anything feels off - a download that finishes too fast, a website that looks slightly different, a checksum that does not match - stop and find another source.

What happens if you skip this?

You might download a working program that happens to be a trojan. The installer looks normal, runs normally, and asks for your password. Later, it sends your seed phrase to an address you do not control. Checksums and signatures are the only practical way to catch this before it happens.

The process takes longer the first time because you are learning. The second time, it is a habit. Ten minutes of verification is cheap compared to the cost of an empty wallet.

Back to bitcoin