The Disturbing Hacker News Thread That Shook Bitcoiners
You thought your air-gapped hardware wallet was fortress-grade secure. No Wi-Fi. No Bluetooth. No USB connection to the internet. Just you, your device, and the Bitcoin blockchain.
Then in July 2022, a Hacker News user named JonathanBeuys dropped a bombshell. His thread titled “Tell HN: It looks like even air gapped Bitcoin hardware wallets can phone home” received 69 upvotes and 52 comments—and sparked a debate that quietly rattled the self-custody community.
The question at the heart of it? Whether Bitcoin can truly be used in a trustless way. Can you control your Bitcoin yourself without trusting any privileged party to not take it from you?
Here’s the uncomfortable truth that thread revealed.
The Hidden Danger in Every Signature You Make
The cryptographic basis for this concern starts with a technical detail most users never think about: ECDSA signatures are non-deterministic.
For any given transaction and private key, there exist astronomically many mathematically valid signatures. Your wallet could generate signature A, or signature B, or signature C—all valid, all acceptable by the Bitcoin network, but subtly different.
A malicious signer could exploit this non-determinism. By deliberately choosing nonce values, a compromised wallet could encode hidden data within those signature variations. This is a form of kleptographic attack, also known as a covert channel.
Here’s where it gets truly unsettling.
How Your Wallet Could “Phone Home” Without a Network Connection
Because Bitcoin signatures are published to the public blockchain, an attacker who knows the encoding scheme could monitor the blockchain and recover hidden information—without any direct network connection to your signing device. No radio signals. No sneaky Wi-Fi packets. Just the blockchain itself.
The theoretical leakage rate depends on the specific covert channel design. One illustrative example discussed on Hacker News suggested that if roughly 10 bits could be leaked per signature, and 96 bits of entropy remained to be recovered, then approximately 10 transactions might theoretically leak enough information.
That’s the theory. Not a demonstrated real-world attack against major wallets, but a chilling possibility nonetheless.
RFC 6979: The Partial Solution
There’s hope on the technical front.
RFC 6979 specifies a deterministic nonce derivation method for ECDSA. The nonce is generated by hashing the secret key together with the message to be signed. When implemented correctly, this produces the same signature for the same inputs on the same implementation.
Here’s the catch: RFC 6979 does not guarantee identical signatures across different wallet implementations. Different wallets may use additional randomness, different normalization, or other implementation-specific variations. Therefore, cross-wallet signature parity cannot be assumed simply from RFC 6979 compliance.
So even if your wallet claims to follow this standard, you cannot easily verify it by comparing with another device.
Taproot and BIP 340 Schnorr Signatures
Since the November 2021 activation of Taproot (BIP 341), Bitcoin also supports BIP 340 Schnorr signatures. This adds another layer to the conversation.
BIP 340 specifies a synthetic nonce derivation: the nonce is computed via a hash of the private key, the public key, and the message, combined with auxiliary randomness. The BIP 340 Schnorr signing specification also includes a step where the signature is verified before being returned, which helps prevent publishing invalid signatures that could leak information.
But here’s the reality check that keeps security researchers up at night.
The Implementation Trust Problem
Even with deterministic or synthetic nonce schemes, you must still trust that the wallet software correctly implements the specification. A malicious implementation could bypass or fake the deterministic derivation. The code might claim to use RFC 6979 while secretly doing something entirely different.
Your air gap doesn’t help if the device itself is the threat.
Anti-Klepto and Anti-Exfiltration Protocols: Your Best Defense
Anti-klepto and anti-exfiltration protocols have been developed to address this class of risk. These protocols work by having your host computer provide random entropy that is cryptographically mixed into the nonce generation process.
With an anti-exfil protocol, the wallet commits to using the host-provided challenge before generating the signature. This commitment reduces the wallet’s freedom to choose nonce values arbitrarily, making it much harder to embed covert channels.
Specific hardware wallets that implement these protections include:
– Blockstream Jade (Anti-Klepto protocol)
– Coldcard MK4 (Anti-Exfil protocol)
– Trezor Model T / Safe 3, 5, 7 (host entropy commitment schemes)
If you’re using a single hardware wallet, verify that your device supports and has enabled anti-exfil or anti-klepto protections if available.
Multisig: Distribute Your Trust
There’s a practical alternative that doesn’t require trusting any single device.
Multisignature (multisig) lets you distribute trust across multiple keys or devices. In an m-of-n multisig setup, a transaction requires signatures from m out of n possible keys.
A 2-of-3 multisig configuration using three independent hardware wallets from different manufacturers eliminates the single point of failure. Even if one wallet is malicious or compromised, it cannot unilaterally spend your funds. No single signature authorization is sufficient to spend. A covert channel in one device becomes harmless because the other two devices would need to cooperate.
Other Lines of Defense
Beyond protocol-level protections and multisig, several additional measures can harden your setup:
Reproducible builds allow you to compile wallet firmware from source and verify that the resulting binary matches the officially distributed one. This verifies that the distributed software corresponds to the published source code. However, very few users actually perform this verification, and reproducible builds do not protect against malicious source code or compromised hardware.
Generating seed phrases using physical dice removes dependency on the wallet’s random number generator. The seed entropy is created before the wallet ever sees it, eliminating one potential attack vector at the generation phase.
Tamper-evident packaging helps detect supply chain interception but does not protect against firmware-level attacks that are invisible upon physical inspection.
Cross-verifying signatures across multiple wallets is theoretically possible but is not a practical workflow for most users. Comparing raw signatures requires technical expertise and is not supported by standard wallet interfaces.
What You Should Actually Do
The most practical defenses for a typical user are straightforward. Use a hardware wallet that implements an anti-exfil protocol, or set up a multisig configuration across multiple independent hardware wallets.
If you’re relying on a single device, understand what you’re trusting. Read the specs. Check if your wallet supports anti-klepto protections. Consider whether your threat model justifies the complexity of a multisig setup.
Your air gap is valuable, but it is not a magic shield against every threat.
The Bottom Line
JonathanBeuys’s Hacker News thread from July 2022 exposed a fundamental tension in Bitcoin self-custody. The chain that connects your private keys to the public blockchain—the signature itself—can theoretically be manipulated to betray you.
The cryptography exists to prevent this. RFC 6979, BIP 340 Schnorr, anti-exfil protocols—they all provide tools to close these covert channels. But tools work only when correctly wielded.
Verify your protections. Consider multisig if your stack warrants it. And remember that trust minimization is a journey, not a destination. Your hardware wallet might be air-gapped from the internet, but make sure it’s not keeping secrets from you.