--- title: "The trust asymptote · Bitsaga Insights" description: "'Don't trust, verify' names a direction, not a destination. Forty-two things the purest cypherpunk setup still trusts, from the chip fab to your own tired eyes, and why verification wins anyway." url: "https://bitsaga.be/insights/the-trust-asymptote" language: "en" --- > 'Don't trust, verify' names a direction, not a destination. Forty-two things the purest cypherpunk setup still trusts, from the chip fab to your own tired eyes, and why verification wins anyway. [Insights](https://bitsaga.be/insights) · Opinion # The trust asymptote By [Rob Segers](https://bitsaga.be/about) · August 20, 2026 ![An orange curve of remaining trust falling steeply with verification effort, approaching but never touching the dashed zero-trust line](https://bitsaga.be/images/insights/the-trust-asymptote.svg) > **TL;DR.** "Don't trust, verify" is the best slogan Bitcoin has, and the most misread. Read as a destination, it promises something that does not exist: zero trust. Nobody has it. Nobody has ever had it. Below is a list of forty-two things the purest cypherpunk setup on earth still trusts, from the chip fab to your own tired eyes at midnight. The point is not despair. The point is that verification is a slope, not a summit, and once you see that, the question "which setup is trustless?" dissolves into the only question that was ever real: which setup leaves the least to trust, and how much of that can you actually check? ## A direction, not a destination Every Bitcoiner knows the slogan. Fewer notice that it describes an asymptote: a curve that approaches a line forever and touches it never. You can verify more, and more, and more, and every hour of it genuinely reduces what you must take on faith. But the curve never reaches zero. Somewhere under your last verification there is always one more layer, and at that layer, you trust. This is not a defeatist observation. It is the load-bearing fact of the whole debate about how to hold bitcoin, because both extremes misuse the slogan. The custodial crowd says "you trust something anyway, so relax and trust us", which ignores that the curve has a slope and their end of it is a cliff. And the purist crowd says "this device requires trust, therefore it is disqualified", which is a standard that disqualifies everything, including the purist's own setup, including Bitcoin itself. ## Szabo never promised zero The intellectual root of the slogan is Nick Szabo's 2001 essay [Trusted Third Parties Are Security Holes](https://nakamotoinstitute.org/library/trusted-third-parties/), and it is worth rereading what it actually claims: a trusted third party is the most expensive and most dangerous component of a protocol, and good design *minimizes* it. Minimizes. Not eliminates. Szabo was an engineer describing a cost to be driven down, not a priest describing a sin to be abolished. Bitcoin itself is the proof. The most trust-minimized money ever built still asks you to trust that a majority of hashpower follows its incentives, that the code of your node does what it says, and that the mathematics under secp256k1 and SHA-256 holds. That is a spectacularly short list compared to a central bank. It is not zero. Anyone who wields "trustless" as a binary pass-fail test has just failed Bitcoin with it. ## Thompson closed the escape route "Fine," says the purist, "then I verify the code myself." Ken Thompson took that door off its hinges in 1984, in the shortest great paper in computer science: [Reflections on Trusting Trust](https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf). He built a compiler that inserts a backdoor into the login program, and inserts the backdoor-inserter into every future compiler compiled with it. Source code of both: perfectly clean. His conclusion, verbatim: "You can't trust code that you did not totally create yourself." Reading source proves nothing final. Below the source sits the compiler, below the compiler the compiler that compiled it, then the assembler, the microcode, the die, the fab. The regress does not bottom out. Not for a hardware wallet, not for a laptop, not for an offline HTML file, not for anything. Verification is real and precious, and it floats on trust all the way down. ## The purest setup that exists So let us build the strongest setup that actually exists, the one the dark wizards of this space describe. You roll dice and debias the throws by hand, von Neumann's 1951 trick, then compute the checksum yourself with [Codex32's paper volvelles](https://secretcodex32.com/), so no computer ever witnesses your entropy being born. You sign on a stateless device with no radio silicon on the board, assembled from parts bought anonymously with cash, running firmware you rebuilt through [Guix's full-source bootstrap](https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/): a chain of trust that starts at a 357-byte binary a human can audit by hand. Your quorum is split across vendors and borders with a timelocked decay path for your heirs, and between sessions it rests under [random-mosaic tamper seals](https://dys2p.com/en/2021-12-tamper-evident-protection.html). Your node speaks only Tor. No vendor knows you exist. This is the least-trust setup available to a human in 2026, and almost nobody, including me, lives at this altitude. Here is what that setup still trusts. ## Forty-two things you still trust ### The silicon - The Broadcom chip on the Pi, whose boot ROM is closed, unauditable, and runs before any code you chose. - The GPU firmware blob that wakes that chip: on a Raspberry Pi the GPU boots *before* the CPU, running code nobody outside Broadcom has read. - The fab that etched the die, and every mask revision it ever applied, in a facility you will never enter. - The lithography machines that made the fab possible, and the software inside them. - The SD card's controller: a small closed computer sitting between you and every byte you store. - The camera module's firmware, which sees every QR you show it. - The display driver chip, which you trust to render the address it was given and not one it prefers. - Your RAM, holding the seed in plaintext during signing, hopefully immune to disturbance errors. - The voltage regulators and oscillators, trusted not to leak your key through power draw or radio emissions; side-channel labs demonstrate exactly that, on real devices, every single year. ### The mathematics - That SHA-256 hides no structure its designers at the NSA did not disclose. - That secp256k1's constants are as innocent as they look. It was chosen partly because people distrusted the NIST curves: the trust moved, it did not vanish. - That the discrete logarithm problem is actually hard, which nobody has ever proven. - That no basement anywhere holds a quantum computer ten years ahead of the public schedule. - RIPEMD-160, designed in Leuven in 1996, holding up forever inside every Bitcoin address. - That PBKDF2 at 2048 iterations, the number BIP39 froze in 2013, still means something against modern hardware. - That the BIP39 wordlist and checksum design contain no subtle footgun. ### The objects on your table - That your dice are fair. Casino dice are milled flat to fractions of a millimeter precisely because ordinary dice are not. - That your deck was actually shuffled: mathematicians showed fewer than seven riffle shuffles provably retains order. - That no phone, webcam or window overlooked your table while you rolled. - That your room does not broadcast: electromagnetic and acoustic leakage (TEMPEST) has been demonstrated for decades. - That the backup plate vendor's fire rating is real and the alloy will not corrode before your heirs need it. ### The build you verified - The Python interpreter your signer's firmware runs on. - The C compiler that built that interpreter: Thompson's literal, named target. - The cross-compilation toolchain, the linker, and every build script in the chain. - Git's content hashes, and the assumption nobody has collided them. - That GitHub or Codeberg served you the same bytes it serves everyone else, and not a personalized copy. - The TLS certificate authorities vouching for that connection: a literal list of trusted third parties shipped inside your browser. - DNS, when it tells you that github.com is GitHub. - The maintainers' signing keys, and the entropy *those* keys were generated with, on machines you know nothing about. - That "reproducible" means what you hope: you reproduced the build, not the intent of the code you built. ### The act of verifying itself - The `sha256sum` binary you verify everything with. Did you verify it? With what? - Your terminal, rendering what it was told: escape sequences and lookalike characters exist. - Your keyboard's firmware, one more small computer with opinions. - Your eyes and your tired brain, comparing 64 hexadecimal characters at midnight and reporting that they checked every one of them. Research on humans comparing hashes is not kind. ### The network, on the day it counts - Your node's peers, relaying your transaction honestly. - The miners, including your transaction, leaving it buried, and staying honest for no deeper reason than that the incentives say they should. ### Yourself - Your memory of the passphrase, ten years from now. - Your discipline at 3 a.m., tired, phished, or scared. - Your future self, who will one day be tempted to type the seed somewhere convenient, just once. - Your heirs, executing instructions they have never rehearsed, while grieving. - Your own body, under a wrench. - And your judgment of everything on this page, which quietly decided which of these were safe to ignore. That is forty-two, and no, it is not the answer to life, the universe and self-custody; the list is not even complete, it merely stopped. Every "verify" on it rests on a deeper "trust". The purest setup in Bitcoin runs on a mountain of unexamined faith, and so does yours, and so does mine, and so does the laptop of the person who just told you hardware is a scam. ## So why verify at all? Because the slope is the whole game. Look at the list again and notice what is *not* on it: a wallet vendor's closed firmware. An exchange's solvency. A browser extension's update channel. A cloud backup. An app store. Every verified layer removed one of those, and the ones removed are not hypothetical: they are precisely the layers that have actually drained people, in the billions, year after year. [The loss data](https://www.chainalysis.com/blog/crypto-hacking-stolen-funds-2026/) is unambiguous about where the money dies, and it is not at the bottom of this list. It dies at the top, in the layers verification could have removed and did not, because nobody bothered. And the remaining surfaces are not equal. The stack under a stateless signer is a few dozen megabytes of reproducible code on a board you can hold; the stack under a laptop is tens of millions of lines from twenty companies, self-updating weekly, including a second hidden processor you are contractually forbidden to inspect. Both carry trust. One of them a motivated human can walk around with a flashlight. That difference, six orders of magnitude of it, is what the slogan was always pointing at. Hal Finney understood this before almost anyone. His 2004 RPOW, Bitcoin's direct ancestor, ran on a tamper-resistant coprocessor that could [cryptographically attest to the code it was running](https://nakamotoinstitute.org/finney/rpow/secmodel.html), under the explicit assumption that even its own operator was hostile. He did not claim zero trust. He shrank the trusted surface to one auditable box and handed the world the tools to check it. That is the move. It has always been the move. ## The strongest move is deletion There is one move even better than verifying a layer: deleting it. When you roll your seed with dice on your own table, you have not audited the vendor's random number generator. You have removed it. There is nothing left to verify, because you were the randomness, and you were in the room when it happened. The layer's trust did not shrink to something small. It stopped existing. 2026 delivered the proof at nine-figure scale. A build flag in Coldcard's open source firmware silently swapped the hardware random number generator for a weak software one, and the bug sat there, in public, for five years. Roughly a hundred million dollars left wallets whose owners had done everything else right. But the users who had deleted that layer, who rolled their own dice and fed the result in themselves, were immune, [by the vendor's own analysis](https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/). They did not out-verify the bug. They had removed the code path it lived in, so [the most expensive RNG failure in Bitcoin's history](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware) simply did not apply to them. One honest footnote, because this essay does not deal in absolutes: deletion is never quite total. The device that turns your 99 rolls into 24 words is still a layer, and a lying one could ignore your dice and derive a seed it already knows. Which is why the careful version of doing-it-yourself checks the derivation on a second, independent device: two implementations, two authors, one answer. When both agree, deceiving you requires a conspiracy between strangers. The asymptote again, and you can feel the curve bend: you did not reach zero, you made the remaining trust small, explicit, and cross-checked. ## The last honest pixel Verified layers pay for themselves in the strangest places. In September 2025 the biggest supply-chain attack in npm's history poisoned packages with around two billion weekly downloads; the payload's job was to swap wallet addresses in the browser. Total reported theft: a few hundred dollars, largely because wallets that force you to confirm the address on a device's own screen made the payload useless. Five months earlier, Bybit lost $1.5 billion the opposite way: its signers held hardware in their hands and approved what a poisoned web interface showed them instead of what their devices could have shown them. Same lesson from both directions. The screen on the signer is the last pixel that malware on your computer cannot paint. Two billion downloads of malicious code against one small verified display, and the display won by six orders of magnitude. It only protects the people who look at it. ## Shrink, check, split If the list above is the diagnosis, the treatment fits in three verbs. ![Three-step diagram: a large tangled computing stack shrinks into one small signing device, its build is checked against a matching hash, and the remaining trust is split across a two-of-three quorum of devices](https://bitsaga.be/images/insights/shrink-check-split.svg) - **Shrink.** Move signing off the eighty-million-line stack and onto the smallest surface that can do the job: a dedicated, open, stateless device with no radio and no storage. You cannot see over a mountain. Make the thing a hill. - **Check.** Of what remains, verify everything that has a handle: bring your own entropy and cross-check the derivation on a second device, rebuild the reproducible firmware and compare hashes, confirm every address on the device's own screen. Every check converts a trusted layer into a known one. - **Split.** What you can neither shrink nor check, divide. A quorum across different vendors means no single fab, firmware, or author can betray you alone; aviation has flown on exactly this dissimilar redundancy for decades. What survives shrinking and checking should never be a single point of failure. None of this reaches zero. All of it moves you down the curve, and the distance traveled is measured in the only unit that matters: the attacks that no longer apply to you. ## The honest version of the slogan "Don't trust, verify" does not mean zero trust; zero trust is not on the menu, for anyone, ever. It means: **shrink what you must trust until verification can get its arms around it, verify what you can, and know, precisely and honestly, which is which.** Anyone who tells you their setup is trustless has simply stopped counting too early. And anyone selling you "trustless" is asking you to trust them. --- Written because the word "trustless" does a lot of work in Bitcoin arguments, and most of it is unearned. Every claim above is checkable, which, as the list explains, is not the same as requiring no trust. If you find an error, [tell me](https://bitsaga.be/contact).