How to Verify Bitcoin Software Before You Install It

Before you install Bitcoin software, check two things: that the file’s checksum matches the list the developers published, and that the list carries a valid signature from a key you have confirmed belongs to them. The checksum proves your copy is intact. The signature proves who published it. Wallet and node software decides which addresses you see, what you sign and where your recovery words go, so a swapped installer can empty a wallet without breaking any cryptography. The check takes about ten minutes the first time and two minutes on every update after that.

You’ll verify Bitcoin Core and Sparrow Wallet on macOS, Windows and Linux, check StartOS and umbrelOS node images, and learn to read every result. The commands follow each project’s own instructions, and we ran each project’s check on the releases current in November 2026: Bitcoin Core 32.1, Sparrow 2.5.6, StartOS 0.4.1.2 and umbrelOS 2.0.1.

Why Verification Matters: Supply-Chain Attacks

A supply-chain attack targets the route software takes from its developers to you: the website, the download server, a search ad, an email, an “update” pop-up. The developers’ code can be sound and your computer clean, and you still end up running the attacker’s version. Bitcoin’s history has an example of each route:

• The download. In August 2016 bitcoin.org warned that the binaries (the ready-to-run files) of the coming Bitcoin Core release would “likely be targeted by state sponsored attackers”, and that a careless download “could cause you to lose all your coins”. Its advice: check signatures from several developers, with keys taken from more than one source.
• Update messages. In December 2018 attackers ran servers of the kind Electrum wallets connect to, and used them to show users an “update” message linking to malware dressed up as a new Electrum.
• Genuine senders. In September 2026 attackers broke into the email service behind Trezor’s newsletter and sent a fake security alert from Trezor’s own newsletter account, pushing an app that asked for the wallet backup (our advisory).

The Scams That Empty Self-Custody Wallets tells the newsletter story in full, and the Electrum lesson the 2018 one. Verification holds in all three cases: an attacker can copy a website or a message, and can even borrow a real sender, but can’t make a valid signature without the developers’ private key.

Checksums and Signatures: Two Different Questions

A checksum here is a SHA-256 hash of the file: a 64-character fingerprint calculated from every byte (What Is Blockchain Technology? shows how hashes behave). Change one byte and the fingerprint changes completely. This is the line for the Bitcoin Core 32.1 download for Apple-silicon Macs:

6fb94e4d2254bf45f0f58a6679c10f16206c5e885be8541fd974d395fe49d46c  bitcoin-32.1-arm64-apple-darwin.zip

Projects publish a list of these lines, one per file, usually called SHA256SUMS or a manifest. If your file’s fingerprint matches its line, your copy is identical to the file the list describes, which catches a damaged or incomplete download. The list can’t tell you who wrote it. If it sits on the same server as the file, whoever can swap one can swap the other.

A digital signature answers that second question. The developer signs the list with their private key, and anyone holding the matching public key can check it. It’s the same idea that protects bitcoin transactions (see Keys, Addresses and Signatures in Plain Language), with a different signing system: software releases use OpenPGP, and the free program that checks them is GPG (GNU Privacy Guard). Change one character of a signed list and the signature fails. One signature on the list covers every file in the release, so the full check has two parts, and both must pass.

	Checksum	Signature
Answers	Is my copy identical to the file on the list?	Did the developers publish this list?
Made with	A hash anyone can compute	The developers’ private key
Catches	A damaged, incomplete or altered file	A swapped list, and the swapped files it would cover for
You trust	Whoever published the list	The public key you imported

The Key Is the Anchor

A signature is only as good as the public key you check it with. Every key has a fingerprint, a long identifier calculated from the key itself (40 characters for every key in this lesson); Sparrow’s is D4D0 D320 2FC0 6849 A257 B38D E946 1833 4C67 4B40. Two habits make a key trustworthy:

1. Get the key from somewhere other than the download, and compare its fingerprint in at least two independent places.
2. Keep it. GPG stores imported keys in your keyring, so every later update is checked against the same key. To slip you a fake key, an attacker would have needed to reach you on the day you first fetched it, and to change every source you compared it with.

Get the Tools Ready

System	Checksum tool	GPG
macOS	shasum, built in	GPG Suite from gpgtools.org (the link Bitcoin Core and Sparrow give), or brew install gnupg if you use Homebrew
Windows	certutil and PowerShell’s Get-FileHash, built in	Gpg4win from gpg4win.org (version 5.1.1, September 2026)
Linux	sha256sum, built in	gpg, usually already installed

Run every command in a terminal, the window where you type commands: Terminal on macOS (press Command + Space and type Terminal), PowerShell on Windows (press the Windows key and type PowerShell), or your usual terminal on Linux. Then switch to your downloads folder: cd ~/Downloads on macOS and Linux, cd $HOME\Downloads in PowerShell. If PowerShell doesn’t recognise gpg, open a new window, or type & "C:\Program Files\GnuPG\bin\gpg.exe" in its place. Gpg4win has installed GnuPG in that folder since version 5 (January 2026); Bitcoin Core’s page still shows the older Program Files (x86) folder.

Bitcoin Core, Step by Step

No single person signs a Bitcoin Core release. Several contributors each build it from the source code and sign the same list of checksums, and you decide whose keys you trust.

1. Download three files into one folder from bitcoincore.org/en/download, typing the address yourself: the file for your system, SHA256SUMS (“SHA256 binary hashes” on the page) and SHA256SUMS.asc (“SHA256 hash signatures”).
2. Import the builders’ keys. They live somewhere else: the builder-keys folder of the bitcoin-core/guix.sigs repository on GitHub, 41 keys in November 2026. On that repository’s page choose Code → Download ZIP, which saves guix.sigs-main.zip, then run:
   • macOS and Linux: unzip guix.sigs-main.zip, then gpg --import guix.sigs-main/builder-keys/*.gpg
   • Windows: tar -xf guix.sigs-main.zip, then Get-ChildItem guix.sigs-main\builder-keys\*.gpg | ForEach-Object { gpg --import $_.FullName }
   With git installed, Bitcoin Core’s own instruction does the same: git clone https://github.com/bitcoin-core/guix.sigs, then gpg --import guix.sigs/builder-keys/*.
3. Check the signatures on the list, on any system: gpg --verify SHA256SUMS.asc SHA256SUMS
4. Check your file against the list:
   • macOS: shasum -a 256 --ignore-missing --check SHA256SUMS
   • Linux: sha256sum --ignore-missing --check SHA256SUMS
   • Windows: Select-String -Path SHA256SUMS -Pattern (Get-FileHash bitcoin-32.1-win64-setup.exe).Hash

On macOS and Linux, --ignore-missing skips the files on the list you didn’t download, so look for one line that names your file and ends in OK, such as bitcoin-32.1-arm64-apple-darwin.zip: OK. On Windows, PowerShell prints the line of SHA256SUMS that holds your file’s fingerprint, ending in your file’s name; if it prints nothing at all, your file doesn’t match the list. (Bitcoin Core’s page uses certutil -hashfile bitcoin-32.1-win64-setup.exe SHA256, which prints the code for you to compare by eye.)

Reading the Signature Check

Here is one of the signature blocks we got for 32.1 (times appear in your own time zone):

gpg: Signature made Tue Oct 27 14:58:55 2026 CET
gpg:                using RSA key CFB16E21C950F67FA95E558F2EEB9F5CC09526C1
gpg:                issuer "fanquake@gmail.com"
gpg: Good signature from "Michael Ford (bitcoin-otc) <fanquake@gmail.com>" [unknown]
gpg: WARNING: The key's User ID is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
      E777299FC265DD04793070EB944D35F9AC3DB76A
      CFB16E21C950F67FA95E558F2EEB9F5CC09526C1

• “Good signature from” is the result that counts. Eight contributors signed the 32.1 list: Ava Chow, Ben Carman, Michael Ford, Oliver Gugger, Matthew Zipkin, Sebastian Kung, Sjors Provoost and Will Clark. Bitcoin Core asks for “a sufficient amount of keys you trust”: look for several.
• The WARNING is normal. Depending on the key it reads “This key is not certified…” or “The key’s User ID is not certified…”; either way it means you haven’t vouched for the key inside GPG. Comparing the fingerprint takes its place.
• The fingerprint lines show the main key, then the subkey that signed (a second key its owner attached to the main one for signing); when the main key signs directly, there is a single line. Depending on your GPG version they appear as one unbroken string, as here, or after the words “Primary key fingerprint” in groups of four. Bitcoin Core’s download page prints Michael Ford’s, E777 299F C265 DD04 7930 70EB 944D 35F9 AC3D B76A. It matches the first line, and that page sits on a different server from GitHub, where the key came from. For the other signers, their number does the same job: a forger would have to fake several independent keys at once.

Reproducible Builds: Why Many Signatures Mean Something

Bitcoin Core uses reproducible builds: anyone who compiles the published source code with the project’s build system, called Guix, gets files identical, byte for byte, to the ones on the website. Builders publish signed checksums of what they built in guix.sigs. By 6 November 2026, 15 contributors had built 32.1 on their own machines with identical results, and the 13 who had finished the final stage, which attaches the code signatures that macOS and Windows check before running a program, had published lists matching the official SHA256SUMS exactly. Each good signature you see is one of those independent results.

Sparrow Wallet, Step by Step

One developer, Craig Raw, signs Sparrow. The download page is on sparrowwallet.com, the installers on GitHub and the key on Keybase, a public directory of people’s keys: three different places.

1. Download from sparrowwallet.com/download: the installer for your system and the two files at the bottom of the table, sparrow-2.5.6-manifest.txt and sparrow-2.5.6-manifest.txt.asc.
2. Import the key: save the file at https://keybase.io/craigraw/pgp_keys.asc to your downloads folder, then run gpg --import pgp_keys.asc. Sparrow’s page gives a one-line version, which works in the macOS and Linux terminals: curl https://keybase.io/craigraw/pgp_keys.asc | gpg --import
3. Check the signature: gpg --verify sparrow-2.5.6-manifest.txt.asc sparrow-2.5.6-manifest.txt. You want Good signature from "Craig Raw <craig@sparrowwallet.com>" and the fingerprint D4D0D3202FC06849A257B38DE94618334C674B40, which Sparrow’s download page also prints.
4. Check your file:
   • macOS: shasum --check sparrow-2.5.6-manifest.txt --ignore-missing
   • Linux: sha256sum --check sparrow-2.5.6-manifest.txt --ignore-missing
   • Windows: Select-String -Path sparrow-2.5.6-manifest.txt -Pattern (Get-FileHash Sparrow-2.5.6.msi).Hash

Many keys carry an expiry date (Craig Raw’s currently runs to 18 September 2027). If GPG reports an expired key, import it again from the same source and repeat the check; for Bitcoin Core’s keys, the download page gives gpg --keyserver hkps://keys.openpgp.org --refresh-keys.

Once one copy of Sparrow is verified, updates get easier. Put the new installer, manifest and signature in one folder and drag any of them onto Sparrow (1.8.3 or later), or open Tools → Verify Download: it shows who signed, whether the hash matched, and “Ready to install”. Sparrow ships with the signing keys of several projects, including two of Bitcoin Core’s builders and the makers of Trezor, BitBox, Coldcard and Passport, so the same tool checks Bitcoin Core releases and firmware files.

Node Images: StartOS and Umbrel

A node’s operating system comes as a disk image, an exact copy of a whole disk that you write to a card or USB drive. It will run your node and any Lightning funds on it, so check it first.

StartOS: Checksum and Signature

Start9 hosts its images on one server, prints their checksums in the release notes on GitHub, and signs every image with a key kept on a maintainer’s own computer, away from its servers, so the signature still holds if its GitHub account or web hosting were taken over. Its install guide gives both checks:

1. Checksum. On the release page, under “OS Images Checksums”, find the “SHA-256” block (not the “BLAKE-3” block below it) and copy the whole line for the file you downloaded; for a Raspberry Pi, that’s the line ending in .img.gz. On macOS run echo "PASTE THE WHOLE LINE HERE" | shasum -a 256 -c; on Linux, the same with sha256sum -c. On Windows run (Get-FileHash "$HOME\Downloads\FILENAME").Hash -eq "LONG CODE". You want OK, or True on Windows.
2. Key, from outside the download: fetch it from keys.openpgp.org, a public key server, with gpg --keyserver hkps://keys.openpgp.org --recv-keys 5456DBFF1B9DF905041FA7765259ADFC2D63C217. Start9 also publishes it at start9.com/start9.gpg; in November 2026 both copies had the same fingerprint.
3. Signature. From the same release, download signatures.tar.gz and unpack it next to your image (tar -xzf signatures.tar.gz works on all three systems). Then run gpg --verify FILENAME.start9.asc FILENAME. You want Good signature from "Start9 <security@start9.com>" with the fingerprint 5456 DBFF 1B9D F905 041F A776 5259 ADFC 2D63 C217.

The bundle also holds a copy of the key, start9.key.asc. Start9’s guide tells you to use the one you fetched yourself, because a key that arrives with the signature it’s checking proves nothing. We ran both checks on the Raspberry Pi image of StartOS 0.4.1.2 (released 5 November 2026), and both passed.

Umbrel: Checksum and Timestamp

Umbrel publishes a SHA256SUMS list next to its images, and Setting Up Your Bitcoin Node Step by Step walks through checking it. The list isn’t signed (umbrelOS 2.0.1, November 2026), so the check proves your copy is intact, and you are trusting Umbrel’s download server for the rest.

Umbrel adds a timestamp proof, SHA256SUMS.ots. OpenTimestamps ties the list’s fingerprint, through a chain of hashes, to a Bitcoin block: “a timestamp proves that some data existed prior to some point in time”, not who wrote it. For umbrelOS 2.0.1 the proof points to block 974,104, mined at 08:24 UTC on 1 November 2026, about an hour before the release notes went up. A list swapped in later could only carry a later date. To check it, open opentimestamps.org, drop SHA256SUMS.ots into the “Stamp & Verify” box, then SHA256SUMS when it asks for the stamped file: it should report a Bitcoin attestation dated on the release day.

Hardware Wallet Firmware

Firmware, the software inside a hardware wallet, is checked by the device itself. On a Trezor, for example, the bootloader, the small program that starts the device before the firmware runs, checks the firmware’s signature and warns you before running firmware that isn’t official. Your part: install firmware only through the maker’s own app or from a file you have verified, treat that warning as a stop sign, and follow our security advisories for your model (more in Hardware Wallets Explained).

Reading the Results

You see	It means	What to do
Good signature from "…" and the fingerprint you confirmed	That key signed the list	Go on to the checksum
WARNING: … not certified with a trusted signature!	Normal: you haven’t vouched for the key inside GPG	Compare the fingerprint with a second source
BAD signature from "…"	The list changed after it was signed	Delete everything and download again from the official site; if it fails again, stop and ask the project
Can't check signature: No public key	You haven’t imported that signer’s key	Import it and run the check again; this is no verdict on the file. With Bitcoin Core, a few of these lines are fine as long as several keys you trust show “Good signature”
your-file: OK, a matching line on Windows, or True	Your file matches the list	Install it, once the signature check has passed
FAILED and computed checksum did NOT match, False, or nothing at all from the Windows Select-String check	Your file differs from the list	Delete it, download it again and check again; if it fails again, stop and ask the project
No line naming your file and no FAILED line, often with no file was verified, or a red error on Windows	The command never looked at your file	Check the folder and the exact name (a browser may save a second copy as file (1).zip), then run it again

Watch the last row: with --ignore-missing, a misplaced or renamed file is skipped without any FAILED. Only a line that names your file and ends in OK counts as a pass.

What Verification Can’t Tell You

• Whether the code is safe. In November 2018 BitPay confirmed that a third-party package used by its Copay wallet had been altered to load code that “could be used to capture users’ private keys”, and that the code had shipped in Copay versions 5.0.2 to 5.1.0. It was inside the official releases, so checking who published them showed nothing wrong, and reproducible builds only prove a binary matches its source. Your protection there is widely reviewed software and prompt action on security advisories.
• Whether your computer is clean. Malware already on the machine can fake what a check prints. Verify on a computer you keep clean, and sign on a hardware wallet, whose screen the computer can’t change.
• Whether your hardware is genuine. In October 2026 Ledger confirmed a hidden implant in a device sold by a reseller (our advisory); the “Fake and Tampered Hardware” part of the scams lesson covers buying safely.

Make it routine: check every new version before you install it, with the keys already in your keyring. It’s the “Verify it yourself” step of the sovereignty plan, and our guide to verifying a Bitcoin Core download keeps those commands on one page.

Check Your Understanding

1. A friend downloads Bitcoin Core, runs the checksum command against the SHA256SUMS file from the same website, sees “OK” and calls it verified. What is missing, and why does it matter?

Answer

The signature check on the list. “OK” only shows the file matches SHA256SUMS, and anyone able to swap the installer on that server could swap SHA256SUMS too. Running gpg --verify SHA256SUMS.asc SHA256SUMS, with the builders’ keys taken from guix.sigs on GitHub, shows the list is the one Bitcoin Core’s builders signed.

2. Checking Sparrow, GPG prints “Good signature from Craig Raw” followed by “WARNING: This key is not certified with a trusted signature!” Should you stop?

Answer

No. The warning appears every time you haven’t vouched for a key inside GPG. Compare the fingerprint in the output, D4D0 D320 2FC0 6849 A257 B38D E946 1833 4C67 4B40, with the one on Sparrow’s download page. If they match, the signature is Craig Raw’s, and you go on to the checksum.

3. StartOS’s signatures.tar.gz includes a copy of Start9’s key. Why does Start9 tell you to fetch the key from keys.openpgp.org instead?

Answer

Because anyone who could replace the image and its signatures could also replace that copy with a key of their own, and GPG would then report a “Good signature” from the attacker’s key. A key fetched from a separate place, with a fingerprint you have confirmed, is what ties the signature to Start9.