Criticizing a security design is not a personal attack. If bad tradeoffs cannot be discussed without attacking the person pointing at them, that is not a security strategy. It is how bad assumptions survive.
DIY devices are useful, educational, and can have a legitimate place in multisig. But when people use them to protect life-changing savings, being honest about the technical tradeoffs matters more than avoiding an uncomfortable debate.
A Raspberry Pi can be a great node, coordinator, or learning tool. It is a terrible default for the one key protecting your long-term Bitcoin savings.
An ESP32 can be a great controller. A Raspberry Pi can run half your house. Neither becomes a hardware security module because you remove Wi-Fi, load wallet software, and put it in a nice case.
The difference is not that commodity hardware is always compromised and a hardware wallet is magically unhackable. The difference is architectural:
Disconnecting a computer reduces exposure. A purpose-built hardware wallet changes where the secret lives, what code may run, and which screen gets trusted.
That difference matters most when the device is stolen, its boot media is replaced, its software supply chain fails, or the laptop preparing a transaction is already hostile.
Offline is a condition, not a security architecture
Pulling a network cable is useful. Removing Wi-Fi and Bluetooth hardware is better than turning them off in a menu. QR and MicroSD can avoid a live USB session. Keep those advantages.
But ask what did not change.
The processor still executes general-purpose code. The operating environment still parses files, images, QR frames, fonts, wallet descriptors, and transactions. The seed still enters ordinary memory while signatures are created. The same device still tells you what it believes it is signing. Its boot path, removable storage, debug interfaces, dependencies, and update keys still exist.
“Air-gapped” describes how data moves. It does not answer who authenticated the software, what protects the key from that software, or why the display should be believed.
The BeatCoin research demonstrated the category problem with air-gapped computers. Starting from malware already present through installation or removable media, researchers moved a 256-bit Bitcoin private key across the gap using electromagnetic, acoustic, optical, thermal, and other covert channels.
That does not prove your Pi is transmitting secrets through its LED. It proves the air gap was not the trust boundary people imagined. Once malicious code owned the machine holding the key, the machine had many ways to betray it.
Another demonstration makes the display itself part of the threat model. Hash at BitBangingBytes showed Van Eck phreaking working against a video display. The related Deep-TEMPEST research reconstructed HDMI screen content from unintended electromagnetic emissions using widely available software-defined radio, GNU Radio, and deep-learning cleanup.
That was not a Bitcoin-key extraction or a SeedSigner attack, and SeedSigner's ordinary Pi Zero display does not use HDMI. It is another reminder that a general-purpose computer is a whole physical system: processor, display path, cables, power, memory, and room. "Offline" does not make those side channels disappear.
A Raspberry Pi is a Linux computer, not a key vault
The Raspberry Pi Zero 1.3 is a clever choice for a DIY signer because it has no Wi-Fi or Bluetooth hardware. SeedSigner further narrows it with Bitcoin-only software, QR exchange, a custom Linux image, signed downloads, reproducible builds, and its own transaction-review screen. Those are real improvements over a random laptop.
SeedSigner also describes itself honestly as stateless. The seed is not stored between sessions. You reconstruct it from words or SeedQR when you need to sign, and power the device off afterward.
But stateless does not mean the signing session is secretless.
The seed must be reconstructed and held in ordinary RAM. The running kernel and privileged code can read or manipulate it. Powering off removes the runtime copy only after the most sensitive moment has already happened.
The recommended Pi Zero boots from a replaceable MicroSD. SeedSigner tells users to verify the release image, write it to the card, wait roughly 45 seconds for startup, and even remove the card after the software loads. Good practice. Still, the Pi Zero does not bind every boot to that verified image.
There is another uncomfortable dependency under that open-source image. The original Pi Zero uses Broadcom's BCM2835. Raspberry Pi's official firmware repository distributes the bootloader and GPU firmware as precompiled binaries, and its documentation calls the start*.elf files binary firmware blobs that take over the boot process. The accompanying Broadcom license permits redistribution and use in binary form without modification and limits it to Raspberry Pi or authorized derivative devices.
Raspberry Pi has moved important display and camera paths into open Linux components, which is real progress. But the early boot boundary still includes opaque vendor code. Broadcom is a terrible fit for a device whose security story leans on being able to inspect every important layer. You can audit the SeedSigner application and verify its image; you still cannot audit the complete firmware chain from published source. Closed firmware is not proof of a backdoor. It is a critical layer you must trust instead of verify.
An evil maid can replace the card before startup. Malicious code boots first. Removing the card afterward does not make that code honest. When the owner later loads a seed, it can capture the secret, alter the transaction review, or encode data into signatures or outgoing QR frames.
This has been demonstrated. In 2023, Emzy swapped a SeedSigner's MicroSD for a modified card that logged the seed after the owner loaded it. The attacker could return later, collect the card, and recover the words. It was a public demonstration, not proof this is happening broadly in the wild. It shows how little has to look different after replaceable boot media becomes the operating system.
Dark Skippy removes even the need to return for the card. Its authors showed that a signer running malicious firmware can encode a 12-word master seed into two transaction signatures. Once the transaction is broadcast, the attacker extracts the secret from the public signatures. The exfiltration leaves through the exact QR, MicroSD, or USB path that was supposed to carry the legitimate signed transaction.
No radio is required. Statelessness does not help. The attack happens while the seed is loaded and can finish in one signing session.
The Dark Skippy disclosure is careful about the boundary: this is a general malicious-signer attack, not a vulnerability unique to SeedSigner or any named wallet. It requires corrupted firmware and, as of the authors' August 2024 FAQ, had not been observed in the wild. Their demonstration used SeedSigner hardware, but purpose-built signers are not automatically immune. Firmware authentication, tamper detection, reproducible builds, and protocol-level anti-exfil defenses all matter.
Raspberry Pi does document a customer-key secure-boot system for Pi 4-class and newer hardware. That system uses signed boot images, EEPROM configuration, and irreversible OTP settings. The recommended Pi Zero 1.3 does not gain that chain because a later Pi has it. A later Pi provisioned correctly would improve boot integrity, but it would still be a Linux computer whose privileged runtime sees the seed.
SeedSigner's own design discussion identified the Pi's slow startup and the enhanced attack surface of a general-purpose operating system as drawbacks. That does not make the project useless. It makes the tradeoff explicit.
A DIY stateless signer can be valuable as one cosigner in a diverse multisig. That is different from making it the sole vault for an amount that changes your life.
Stateless signing moves the vault into the room
A seed stored for recovery can stay sealed in a safe, hidden location, or different geography for years. A stateless signer makes that recovery secret part of the spending workflow. To sign, you retrieve the words or SeedQR, carry them to the device, expose them, load them, and put them away correctly.
Every spend becomes a small recovery ceremony.
A SeedQR is not encryption. It is another representation of the seed. SeedSigner's own custody guide warns that a SeedQR should never be scanned by a computer webcam or phone camera because it is secret information that can access the funds. The same guide accepts that direct seed access increases disclosure opportunity and says to avoid both unwanted people and areas under visual surveillance.
That changes which room is safe enough for signing.
Home security cameras, baby monitors, laptop webcams, phones on a desk, smart glasses, video calls, and workplace cameras may all create recordings. A camera does not need to understand Bitcoin while it records the image. Cloud upload, account compromise, repair access, retained footage, or later human review can turn one accidental frame into a permanent copy of the seed backup.
Not every camera will have the angle or resolution to recover it. The problem is that you generally cannot prove what was readable after the recording exists.
Plain words have the same problem. They can be read over a shoulder, caught in a reflection, photographed from a distance, or noticed by somebody who now knows both that you own Bitcoin and where recovery material is kept. Retrieving the backup also creates a physical trail between its storage location and the signing area. Shared homes, offices, hotels, travel, and meetups make this worse.
A purpose-built signer changes the routine. You bring the device to the transaction and leave the seed backup sealed. The backup comes out for recovery, not every spend. That does not remove theft or coercion risk around the device, but it sharply reduces how often the root secret is exposed to people and cameras.
A BIP39 passphrase can limit what a captured base seed unlocks when it is strong and kept separately. It also creates another critical secret that can be forgotten, mistyped, exposed, or lost. In multisig, one captured seed may compromise one cosigner rather than the whole vault. Those are useful containment layers, not reasons to normalize displaying recovery material.
An ESP32 is smaller, not a secure element
The ESP32 looks simpler because it is a microcontroller rather than a Linux computer. Simpler is good. It is still a general-purpose wireless SoC designed for embedded and IoT products, not a tamper-resistant vault designed around one Bitcoin master secret.
Be precise here: ESP32 does have security features. Espressif documents Secure Boot, flash encryption, eFuses, JTAG controls, and restrictions on ROM download mode. A competent product team can provision these well, disable interfaces, minimize firmware, and build a much tighter appliance than a hobby board running defaults.
Those controls do not turn the main MCU into an independent secure element.
In 2024, researchers at USENIX WOOT published a physical attack against the hardened ESP32-V3. A single electromagnetic fault let them bypass Secure Boot and Flash Encryption, jump into ROM download mode, and access unencrypted flash. The flaw was in hardware and required a new revision, not an app update.
Ledger Donjon demonstrated the consequence on a commercial ESP32 wallet. In about two hours, the lab extracted the firmware-encryption key from a Jade's ESP32-V3 and decrypted firmware containing private and public keys used for its oracle communication. That research did not directly recover the user's seed; Jade's blind oracle was another layer. It did establish an evil-maid path and show why encrypted off-chip flash plus one commodity MCU is not the same physical boundary as a dedicated key vault.
Do not overstate it. The published V3 result does not prove that every later ESP32-S3 or future Espressif part is broken. Untested is not broken. It is also not evidence of resistance.
The relevant question is not whether a chip has an encryption checkbox. It is whether the complete device remains safe when one check, one processor, one boot key, or one memory boundary fails.
Seven ordinary failure stories
Translate the architecture into custody mistakes.
The swapped-card failure. You verify a MicroSD image once and use the signer for two years. Someone replaces the card before one signing session. The machine boots normally enough, waits for the seed, and produces a valid signature. “Stateless” clears the evidence after the malicious environment already handled the key.
The official-build failure. The download server, maintainer key, build dependency, or release process is compromised. The hash matches the malicious file because the attacker published both. Reproducible builds let independent people detect this, but only if somebody actually reproduces and compares the release before users load seeds into it.
The honest-screen failure. A QR or PSBT parser bug changes an output, hides a fee, or mislabels change. A separate signer screen is valuable, including on a DIY signer. But when replaceable boot media controls both the parser and that screen, a malicious image can make the pixels agree with the attacker's bytes.
The honest-transaction exfiltration failure. Malicious firmware displays the correct destination and signs exactly what you requested. It chooses signing nonces that encode pieces of the seed. The transaction looks normal, but broadcasting it publishes the attacker's covert channel. The air gap carried the seed inside a valid signature.
The convenience-drift failure. A DIY device starts as one key in 2-of-3 multisig. Reconstructing seeds, waiting for boot, and moving QR frames becomes annoying. The user simplifies it into a single-signature wallet. One compromised session is no longer one failed cosigner; it is the whole vault.
The camera-in-the-room failure. You load a SeedQR in what feels like a private room. A cloud-connected camera, open laptop, or phone records one readable frame. Wiping the signer afterward changes nothing. The seed copy now exists somewhere you do not control, and in single signature the attacker does not need the device or its PIN.
The copy-paste hardware failure. Three cheap signers use the same board, image, wallet code, release key, and setup guide. The owner sees three devices and assumes three independent security boundaries. One poisoned build or shared entropy bug can compromise all three. Multisig counts keys, not engineering diversity.
None of these stories requires the Raspberry Pi Foundation, Espressif, or an open-source project to be malicious. Security architecture exists for the day one ordinary component fails.
What purpose-built hardware actually changes
A good Bitcoin hardware wallet separates jobs that a general-purpose signer tends to collapse.
It protects a persistent master secret across power cycles. The seed does not need to be scanned or typed into ordinary system RAM every time. Security-hardened components can enforce PIN attempts and make physical extraction a separate problem from compromising the main application processor.
It authenticates a narrow boot path. Signed firmware matters more when the device gives the owner an observable warning and refuses to treat arbitrary removable media as its operating system.
It treats the coordinator as hostile. The laptop or phone can track balances, select coins, build a PSBT, and broadcast. It does not hold the savings key. The signer derives the destination, amount, change, and fee from the actual transaction and shows them on another screen. Good DIY signers can do this too; purpose-built hardware adds stronger boot and key-protection boundaries behind that screen.
It reduces the jobs the device performs. Bitcoin-only firmware does not need package managers, shell services, a browser, general image tools, cloud accounts, or dozens of chain parsers. Less code is not no risk. It is less code that must be correct around the key.
It is designed around captured-device attacks. Secure elements, multi-chip secret protection, PIN controls, tamper evidence, debug lockdown, and a constrained update process are not decorations. They force an attacker to cross different boundaries instead of winning once against the only CPU.
COLDCARD is one concrete example. Current Q and Mk5 devices use secure elements from two different vendors alongside the main processor. One chip is not intended to hold everything needed to reconstruct the protected master secret. Firmware is public and reproducible. At boot, Secure-Element-controlled Genuine/Caution indicators expose a changed flash state. PIN-prefix anti-phishing words help the owner detect a substituted device.
During signing, COLDCARD reads the PSBT and independently displays the destination, amount, change, and fee. The coordinator is allowed to be compromised. It can lie on its own screen. It should not be able to make the COLDCARD screen repeat that lie without changing the transaction the user sees.
That last control still needs a human. If you do not read the hardware screen, you have turned a purpose-built signer into an expensive approval button.
Hardware wallets also fail
“Use purpose-built hardware” does not mean “buy anything sold as a hardware wallet.”
Some products put Android or a commodity MCU in a case, leave keys reachable from the main processor, trust a remote service without a recovery plan, accept weak firmware paths, or show too little transaction data to verify. Reject them. A label is not an architecture.
The hardware-wallet label is not a panacea either. In 2020, Kraken Security Labs extracted the encrypted seed from the Trezor One and Model T after about 15 minutes of physical access, then brute-forced a four-digit PIN in under two minutes. The original setup used several hundred dollars of equipment; Kraken estimated a mass-produced glitcher could cost about $75. That is 15 minutes of access and an estimated $75 tool, not $15 in parts. A strong BIP39 passphrase kept off-device mitigates this specific extraction attack. Trezor ended direct e-shop sales of both models in January 2026, but says remaining stock may still be available through official resellers for a limited time. This does not establish the same flaw in the newer Trezor Safe models.
Secure elements fail too. In 2023, researchers used double laser fault injection against the DS28C36 found in COLDCARD Mk4 and extracted protected memory pages. They did not recover the full COLDCARD seed because it still depended on other independent components. That is the point of defense in depth: one broken layer should not automatically become the wallet.
COLDCARD can still be defeated by hostile firmware accepted through a compromised trust path, an owner who ignores a red Caution state, a photographed backup, a malicious recovery process, or blind approval of the wrong transaction. No chip fixes bad recovery hygiene. No air gap makes every parser safe. No open repository proves that everybody checked the binary.
These limits are reasons to choose stronger boundaries and operate them correctly, not reasons to move the sole savings key onto a board designed to be cheap, flexible, and easy to reprogram.
Multisig needs real failure diversity
A Raspberry Pi or ESP32 signer can make more sense as one key in a well-designed 2-of-3 vault than as the only key.
The threshold can survive one malicious boot, one extracted MCU, or one damaged device only when the other keys do not share the same board, firmware, maintainer, seed-generation process, and location. Three copies of one DIY build preserve one failure three times.
Use independently designed hardware signers. Store them separately. Back up the descriptor and cosigner information. Verify wallet policy and fingerprints on-device. Rehearse recovery before funding heavily.
A watch-only wallet can live on the Raspberry Pi or laptop. A node belongs there. Transaction construction belongs there. Those are excellent jobs for general-purpose computers because compromise can harm privacy, availability, or the proposed transaction without automatically revealing the signing key.
That is a meaningful separation of powers.
The practical rule
Use Raspberry Pi and ESP32 devices to learn, experiment, coordinate, run nodes, and add inexpensive diversity where the vault can survive one bad signer.
Do not confuse inexpensive, open, offline, or stateless with physically protected.
Use a well-designed, purpose-built hardware wallet for long-term savings. Generate the seed on it. Keep the backup off every computer. Verify receive addresses and every spend on its own screen.
For life-changing amounts, use 2-of-3 Bitcoin multisig with signers in different locations, then test the full recovery path.
Review the custody basics at BitcoinSecurity.org, and choose the COLDCARD Q or Mk5 workflow you can verify and recover correctly.
Offline helps. Purpose-built boundaries are what make offline signing worth trusting.
If I got anything wrong, please let me know. Happy to update the article.