Home → Sovereign Path → Stage 3 → Proofs, Not Promises

Proofs, Not Promises

Verify Bitcoin software, signatures, and code — Don't trust, verify

What You'll Learn:

Why Verification Matters

In traditional finance, you trust banks, auditors, and regulators. In Bitcoin, you are the auditor. Anyone can slip malicious code into wallets, exchanges, or tools to steal your funds.

Real Attack Vectors:
The Golden Rule: If you can't verify it, you're trusting it. And in Bitcoin, trust is a vulnerability.

Verification Layer 1: GPG Signatures

GPG (GNU Privacy Guard) signatures prove that software was released by the legitimate developer, not an imposter.

How GPG Signatures Work

  1. Developer creates software and signs it with their private GPG key
  2. Signature file (.asc or .sig) is published alongside the software
  3. You download both the software and signature
  4. You verify using the developer's public key
  5. GPG confirms the signature matches → software is authentic

Step-by-Step: Verify Bitcoin Core

1 Install GPG

# macOS brew install gnupg # Ubuntu/Debian sudo apt install gnupg # Windows Download Gpg4win from gpg4win.org

2 Import Developer Public Keys

# Download Bitcoin Core release signing keys curl https://bitcoincore.org/keys/laanwj-releases.asc | gpg --import # Verify fingerprint matches official docs gpg --fingerprint "01EA 5486 DE18 A882 D4C2 6845 90C8 019E 36C2 E964"

⚠️ Critical: Verify the fingerprint on multiple sources (official website, GitHub, social media) to avoid man-in-the-middle attacks.

3 Download Bitcoin Core + Signature

# Download the software wget https://bitcoincore.org/bin/bitcoin-core-25.0/bitcoin-25.0-x86_64-linux-gnu.tar.gz # Download the signature file wget https://bitcoincore.org/bin/bitcoin-core-25.0/SHA256SUMS.asc

4 Verify the Signature

# Verify signature on checksums file gpg --verify SHA256SUMS.asc # Should show: # "Good signature from 'Wladimir J. van der Laan ...'" # WARNING: "This key is not certified with a trusted signature!" # ↑ This is normal - you haven't manually trusted the key yet

5 Verify File Integrity (Checksum)

# Check SHA256 hash matches sha256sum --check SHA256SUMS.asc --ignore-missing # Should output: # bitcoin-25.0-x86_64-linux-gnu.tar.gz: OK
✅ If both checks pass: You have authentic Bitcoin Core software signed by the developer. You can install it safely.

📝 Verification Layer 2: SHA256 Checksums

Checksums detect file tampering. Even a single bit changed in a file produces a completely different hash.

Real Example: Verifying Sparrow Wallet

# Download Sparrow Wallet wget https://github.com/sparrowwallet/sparrow/releases/download/1.7.8/sparrow-1.7.8-x86_64.AppImage # Download checksum file wget https://github.com/sparrowwallet/sparrow/releases/download/1.7.8/sparrow-1.7.8-manifest.txt # Verify checksum sha256sum sparrow-1.7.8-x86_64.AppImage # Compare output to manifest.txt - should EXACTLY match

Why this matters: If a hacker compromises the download server and swaps the file with a backdoored version, the checksum won't match—and you'll know immediately.

🤔 What if the checksum is also compromised?

This is why you combine GPG + checksums:

  1. GPG signature proves the checksum file is authentic
  2. Checksum proves the software file matches the signed checksum
  3. Together, they create a chain of trust

An attacker would need to compromise both the developer's GPG key AND the download server—much harder.

👀 Verification Layer 3: Code Review

Even if signatures check out, you can (and should) review the code. You don't need to be a developer to do basic verification.

Non-Coder Verification Tactics

🔎 Check GitHub Activity

  • How many contributors? (More = harder to collude)
  • How many stars/forks? (Popularity = more scrutiny)
  • Recent commits? (Active maintenance = security patches)
  • Issue tracker? (Users reporting bugs openly = transparency)

🧑‍💻 Read the Code (Yes, Really!)

Even if you don't understand every line, look for:

  • ❌ Obfuscated code (unusual variable names, compressed code)
  • ❌ External API calls (where is data being sent?)
  • ❌ Hardcoded addresses (is someone sneaking in their own Bitcoin address?)
  • ✅ Comments and documentation (legitimate projects explain their code)

🗣️ Check Community Feedback

  • Search "[wallet name] + scam" on Reddit, Twitter, Bitcoin Talk
  • Look for security audits (reputable wallets publish them)
  • Check if it's recommended by known Bitcoin educators
  • Be wary of projects with only positive reviews (astroturfing)

For Coders: Deep Verification

# Clone the repository git clone https://github.com/bitcoin/bitcoin.git cd bitcoin # Check out the release tag git checkout v25.0 # Review key files cat src/wallet/*.cpp # Wallet logic cat src/net.cpp # Network communication cat src/rpc/*.cpp # RPC interface # Build from source (ultimate verification) ./autogen.sh ./configure make make check # Run test suite
Why build from source? Pre-compiled binaries could be trojaned. Building from audited source code gives you the highest confidence.

Real-World Checklist

Before Installing ANY Bitcoin Software:

⚠️ Red Flags to Avoid

🚩 NEVER Use Software That:

🔗 Trusted Resources

Key Takeaways

  1. Don't trust, verify: Always verify software signatures and checksums before installation
  2. Multiple sources: Cross-check fingerprints and hashes from different channels
  3. Open source preferred: Closed-source wallets = blind trust
  4. Test first: Use small amounts before trusting new software
  5. Community matters: Active development and transparent discussion = safer
  6. When in doubt, skip: Missing verification tools? Don't use it.
← Back to Stage 3