Never Bet Your Bitcoin on Surviving a Single 0-Day

Everybody wants my take on Thursday's Binance hack, so here it is.

On October 29, North Korea's TraderTraitor group drained roughly $6.36 billion from Binance's hot wallets across ten chains in about twenty minutes, the largest single theft in history. Binance's statement included the line everyone expected: "We have found no evidence of any wallet private key leak."

Leslie Lamport once defined a distributed system as one where the failure of a computer you didn't even know existed can render your own computer unusable. At Binance, a single DevOps laptop you didn't know existed emptied $6.36 billion whose private keys "never leaked."

According to Binance's initial investigation, that compromised laptop let the attackers step into an internal service container and submit unauthorized withdrawal requests, and the signing pipeline signed them. In distributed-systems terms, Binance built its hot-wallet pipeline for crash faults, keeping withdrawal microservices up and trusting any authenticated internal container, when one popped laptop turns that container into a lying Byzantine general. Any AI handed a diagram of that architecture, or anyone forced to write the spending policy as an explicit smart contract instead of internal microservice glue, would have spotted the hole on day one.

Safety, Liveness, and Where the $6.36 Billion Went

In Lamport's framing, distributed systems trade off safety, meaning bad things never happen (unauthorized coins don't move), against liveness, meaning good things eventually do (your withdrawal goes through). Years later, security researchers had to add a third category they called hyperproperties, which in plain English is privacy: you cannot tell whether a system leaks secrets by checking a single execution trace for safety and liveness, because leakage lives in what an observer can infer across runs by watching your traffic or timing your hardware.

Early post-mortems from TRM Labs, Elliptic, Chainalysis, and LlamaRisk show where the $6.36 billion went:

On the stablecoin and DeFi side, once Binance's internal safety failed, issuers and protocols could only stop the bleeding by killing liveness for innocent users. Knowing Tether and Circle were minutes away from blacklisting their wallets, the attackers used Aave V3 as a freeze-hedge: supply $60 million of stolen USDT into a shared lending pool (where blacklisting the pool contract would lock everyone else alongside the thief), borrow 19,762 unfreezable WETH (~$44.6 million) at an instant ~25% haircut, unwrap to native ETH, and abandon the tainted collateral. Forty minutes later, Aave contributors and LlamaRisk had to freeze 175 reserves on Aave V3 across sixteen networks and 117 reserves on Aave V4 across four networks just to close that loop. Modeling a permissionless pool alongside a blacklistable token in Lean would have surfaced that interaction before deployment instead of during an emergency response. Elsewhere on DEXs and cross-chain routers like THORChain and Relay, where they bridged out over half the 970k SOL from their Solana wallet and commingled swaps with September's Bitget hack, the thieves ate 12% to 26% slippage to get out of freezable IOUs and into native ETH and BTC.

On Ethereum, proof-of-stake turns a custodian failure into a protocol safety problem. Even setting aside the ETH North Korea already took from Upbit (342k ETH), Ronin (173.6k ETH), and Bybit (401k ETH), which pushed their cumulative ETH haul past roughly 1.4% of total supply, the 420,000+ ETH from Thursday's raid alone is roughly two and a half times the Ethereum Foundation's ~170,000 ETH treasury. On a proof-of-stake chain, every hot-wallet disaster hands a hostile nuclear state a bigger chunk of the asset that governs consensus.

On Bitcoin, protocol safety and liveness both held without an admin pause button, so privacy became the whole story. Nobody can freeze those 18,270.2 BTC on a conference call, and stealing them buys Pyongyang zero hashpower and zero say over Bitcoin's rules. Bitcoin isn't private by default, though. Eleven hot-wallet withdrawals swept 513 Binance UTXOs into a single hub and peeled them inside the mempool of Block 973,732 (plus one straggler sweep six blocks later) into nineteen bc1q staging wallets, seventeen exact 1,000 BTC outputs and two remainders, for under $9 in downstream miner fees. Round-number peels in the same block hide nothing, and not a single satoshi has moved from those nineteen wallets since. Surviving Bitcoin mixers only clear a few million dollars a day, so dumping $1.47 billion into a shallow pool just mixes your dirty coins with your own dirty coins while everyone tracks the cluster live on Arkham and spams OP_RETURN messages at the UTXOs.

Multicore, Side Channels, and Treating the Host as Byzantine

I haven't believed computers work safely the way people say they do since multicore arrived while I worked at Intel. My security friends there didn't believe it either. We watched Linux add support for SMP and Hyper-Threading, and the premise never made sense to me: rival processes taking turns or running side by side over the same physical registers, execution units, and caches while the operating system draws a line in software and calls it isolation. Operating-system memory permissions check single-run safety, not what leaks across shared silicon timing. Over a decade later, when Spectre and Meltdown finally hit the news, none of us who watched that hardware ship were surprised.

At Intel I was in a completely different department, working on isolated I/O approaches where the network card itself protected the network from worms spreading. Our starting assumption was that the host CPU and operating system would become Byzantine. You don't ask an infected host whether its outbound packets are legitimate. You put enforcement on separate silicon at the wire, watch narrow control-plane signals, and combine them across a distributed system to cut off a runaway machine before it floods everyone else. Combined with my love of distributed systems, that work turned into one of my favorite patents.

Inverting Lamport: Liveness at Any Cost

Around the same time, studying distributed systems in grad school, we barely talked about safety versus liveness. Even with mobile nodes and constant churn, almost everyone optimized for liveness at any cost: keep packets moving, route around dead links, never stall. We didn't touch Byzantine faults or Bitcoin-style consensus because even crash-fault Paxos was beyond most working developers until Raft came along in 2014, five years after Satoshi shipped Bitcoin.

Lamport's actual lesson in Paxos, and the reason he spent decades building TLA+ and reminding people that "coding is to programming what typing is to writing," was the reverse. When networks partition, clocks drift, or nodes go rogue, safety must hold unconditionally. You only ever sacrifice liveness during a fault, never safety.

Exchanges inverted that rule. A modern hot-wallet pipeline is built like a high-throughput web service: Linux containers talking to Linux containers, automated withdrawal queues, instant settlement across ten chains. Liveness runs wide open while safety gets reduced to trusting an internal RPC inside the same fleet an engineer's laptop can reach. Give a Byzantine intruder twenty minutes inside that loop and liveness moves over $300 million a minute out the door before Tether, L2 security councils, or DeFi guardians can react.

On Ethereum, the attackers drained even faster by bypassing Binance's legacy EOA withdrawal crud, and Binance's own emergency shutoff helped them. Instead of drip-feeding tokens one transfer at a time through Binance 14's sequential-nonce queue, the thieves had the compromised signing pipeline pre-sign fifty consecutive EIP-7702 authorizations to catch the moving nonce and convert Binance 14 directly into an on-chain batch sweeper contract. Once that delegation landed on-chain, the attackers didn't need Binance's servers anymore. When defenders panicked and unplugged their backend containers and legacy withdrawal queue, they cleared out the competing nonce traffic while leaving the on-chain sweeper live for hours, automatically vacuuming fresh incoming deposits while Binance scrambled to bring enough of its signing stack back up just to broadcast a revocation.

The Movie Scene Is Real Now

Nobody serious thinks anything plugged into the internet over the last ten years is safe, at least not if "safe" includes our own NSA targeting you.

Most companies get away with ignoring this because Fort Meade isn't robbing corporate treasuries. North Korea is. They sit only a rung or two below top-tier Western capabilities, and unlike the NSA, their day job is turning zero-days and laptop compromises directly into bearer money.

Remember those 90s hacker movies where an animated AI slices through Firewall 1... Firewall 2... Firewall 3... in seconds while people in a server room stare helplessly at blinking monitors? Security engineers used to laugh at those scenes, and they shouldn't anymore. When all of your "layers" are general-purpose machines plugged into the same network (a laptop, a VPN, a container host, an internal RPC to a signing service), an AI-assisted offensive team cuts straight through them at machine speed before a human finishes reading the first alert.

Binance was widely treated as the best in the international industry, with the deepest pockets, the biggest security bench, and the SAFU halo. It turns out they couldn't even be trusted with level-one security, where one engineer's laptop reaching a container empties six billion dollars. That reputation is dust now. If the top exchange on earth can't even clear that bar, the idea that centralized custodians can compete against nation-states on the open internet is a joke. Not your keys, not your coins.

How We Think About This in Winnow

On Bitcoin, there is no issuer blacklist to save a sloppy custodian after the fact. Safety has to hold before a valid signature ever hits the wire.

The fatal mistake in Bitcoin, whether you run an exchange or hold your own coins, is building a setup where a single 0-day takes the money. Put everything behind one container pipeline, one phone, one desktop OS, or one hardware-wallet vendor, and you are betting your balance that nobody has an exploit for that stack.

That is why I've been building Winnow around physical and cryptographic boundaries an online exploit cannot cross on its own. Winnow is a mobile light wallet that deliberately errs on the side of being fast and private, syncing straight from your pocket without handing your addresses to a server, which means dealing with privacy, Byzantine hardware, safety, and liveness at the same time instead of locking everything in a bank vault:

1. Keep unneeded machinery out of the room, and formally verify what you can. There is no central Winnow server holding user state or address lists; the wallet reads compact block filters straight from Bitcoin peers so peers never learn which addresses are yours. When extra networking machinery doesn't belong inside the signing app, like Tor and I2P daemons, we keep it outside the wallet and make it optional and automatic when present instead of bundling more attack surface next to your keys. For the core that stays inside the room, I've been porting Winnow (wallet logic, P2P networking, UI state machine, and a formally proven secp256k1) into Lean 4, taking the specification discipline Lamport started with TLA+ all the way to machine-checked code compiled straight to C and differential-tested against Bitcoin Core (over a thousand multisig checks with zero disagreements, alongside the rest of the test suite).
2. Force the attacker to burn two independent 0-days instead of one. Most apps treat a hardware wallet as a single-key replacement for the phone, which just trades one single point of failure for another. Winnow treats every signer as potentially Byzantine and builds around multisig, not hardware-wallet replacement, so you have to hack both the iPhone and the hardware wallet to take the money. In Winnow's Taproot multisig accounts (sortedmulti_a over an unspendable internal key), any k of n keys sign plain PSBTs in any order, with no coordinator server and no physical connection between the wallets required. Because Winnow carries its own cryptography and wallet stack, there is minimal overlap of implementation or dependencies between the signers: Apple silicon and iOS running Winnow's code on one side, and a completely different chip, OS, firmware, and physical screen on the other. We are also investigating how those two keys can work together even better to foil real hardware attack attempts we've seen in the wild.
3. Put the circuit breaker on Bitcoin's logical clock. Another of Lamport's classic points is that wall clocks on networked servers lie; only causal, logical time is trustworthy. Just like an Intel network card shouldn't trust its host OS during a worm outbreak, custody shouldn't depend on a Linux container's clock or policy service to enforce time delays and recovery rules. Winnow supports timelocked Taproot vaults directly on Bitcoin: an account can require your full multisig threshold today while baking in a block-delayed path, spendable by fewer keys or a separate recovery key only after a chosen number of proof-of-work blocks, enforced by every node on the Bitcoin network. Even when liveness breaks because of a lost phone or a quarantined key, safety holds unconditionally until the timelock matures on-chain.
4. If you can't upgrade it using AI, unplug it. Legacy human-reviewed stacks won't keep pace with AI-armed state teams. Before the Lean port, we used AI to build an independent Swift secp256k1 checked differential-style against libsecp256k1 and Bitcoin Core so one library's bug isn't silently everyone's bug, and AI is what finally makes machine-checked proofs practical in days instead of specialist-years per module. Anything you can't continuously upgrade, test, and prove at AI speed has no business sitting on the internet guarding money.

Winnow still has plenty of work ahead on this. Building each piece separately is much easier than combining them without ruining either safety or liveness. Stack separate devices, hardware signers, and block-height timelocks clumsily and you either lock people out when a phone dies or make everyday spending annoying enough that users give up and leave their coins on Binance anyway. Getting pocket payments to feel fast and normal while independent keys, hardware screens, compact filters, and timelocked recovery work together underneath is the hard part we are still grinding through.

Binance will cover the $6.36 billion out of SAFU and corporate reserves and keep repeating that no private keys leaked, even though any general-purpose machine left online can be turned Byzantine fast enough to empty whatever liveness pipeline sits behind it. That leaves one question I keep coming back to: why is there so much resistance to building real depth into Bitcoin custody? Against an adversary hunting for the easiest payday, security is relative. The experts don't need to be perfect; they just need not to be the least protected people in the room. Every exchange hot wallet and every single-key setup out in the open soaks up the zero-days and the state-sponsored attention first. Maybe the reason there is so little depth in public Bitcoin security isn't that insiders don't see the problem. Maybe keeping public security shallow is the experts' protection in private.