Timechain
Search Donate
Sponsors
Cake Wallet, private Bitcoin and Monero walletSideShift.ai, no-signup crypto exchangeOrangeRock, non-custodial bitcoin spot and perps tradingBraiins Hashpower, buy and sell Bitcoin hashrateLayer Two Labs, drivechains for Bitcoin
S16 · E35 · 1:24:26

S16 E35: Hunter Beast on Bitcoin's Quantum Resistance & BIP 360

24 Jul 2025 · by Vlad Costea · 10 min read
Published at block 906,987
MP3 (116 MB)

The audio keeps playing while you browse the site.

Read the transcript11,130 words, every line links to the minute it was said

Ask this episode

Embed this episode

Paste this on your site or blog. It is a small player that streams from here: no trackers, no cookies, no ads.

Preview the player

I came into this episode with a question I have asked a few quantum people before: is this a real threat or a fundraising story? Hunter Beast, the author of BIP 360, did not argue me out of the question so much as move the clock. "It's not real yet, it's existential," Hunter Beast said in the first few minutes, and then spent the next hour and a half explaining why that sentence means upgrade work should start now.

I wanted the skeptic's chair for this one, so I took it. I said I was not convinced the proposal was necessary, I pushed on privacy tooling I think is overrated, and I got my own qubit arithmetic wrong on air and had to fix it. Hunter Beast kept coming back to threat models and to a list of what can and cannot be done today. BIP 360 is a draft co-authored with Ethan Heilman, and it is still not merged into the main BIPs repository.

"Quantum computing isn't sovereign computing"

My first challenge was the obvious one: nobody has shown me a machine that can touch a Bitcoin key. Hunter Beast's reply was that the danger comes from institutions, not from some state sitting on a secret machine. "Quantum computing isn't sovereign computing," Hunter Beast said, which is to say the actors with the money and the motive are large organizations, and we may not know when one of them gets there. "It also doesn't mean that we're not already there or close to it, we just don't know it yet."

The evidence Hunter Beast leaned on was the behavior of the US government. "We're being repeatedly warned by the American government," Hunter Beast said, with a target "to achieve quantum resistance by 2030." Later I came back to this and said plainly, "I do think it's a threat." Hunter Beast's follow-up was a careful one: "They're warning banks, they're warning universities," and "I'm not asking you to trust the US government." Hunter Beast also granted that distrust of Washington is earned: "I totally get there's every reason to distrust the US government. They've done some really bad stuff in the past, and they will continue to do so."

Part of why this lands differently for Bitcoin, in Hunter Beast's telling, is who has to move. Banks and cloud providers can hire experts and harden their systems: "It's the kind of thing where it's relatively trivial for centralized systems to hire experts and upgrade their systems and make sure they're hardened and audited and that sort of thing." Bitcoin has no such department, and "it's much more difficult to upgrade, for good reason." Elsewhere Hunter Beast put the same idea more generally: "the more value it secures, the harder it becomes to change." On quantum paranoia in general, Hunter Beast went with an Andy Grove line: "only the paranoid survive and I'm paranoid about quantum computers." And on the instinct itself: "people think it's like a bad thing to like to reason about it, think about it, listen to, but like, it's, it's like an evolutionary instinct. It's gotten us pretty far, you know, this far."

What a quantum machine would actually go after

The rule of thumb Hunter Beast gave me is short: "any address that has a public key exposed, that is potentially quantum vulnerable." That covers pay-to-public-key coins from the early days, reused addresses, transactions sitting in the mempool, and Taproot addresses. "Taproot is vulnerable to long exposure attack," Hunter Beast said, since the public key is on chain from the moment the output exists.

There was an earlier version of this story that did not survive contact with data. "And then we looked into the data, and it didn't hold up," Hunter Beast said of one scare narrative, and went as far as "we may not even need to do anything about this" for part of the problem. What remains is the Taproot piece, and the roughly 150,000 coins figure came up later as part of a harsh review, which I will get to.

For the qubit numbers I asked what it would take. Hunter Beast's estimate: "you need about 3,000 logical qubits," and with error correction, "maybe we only need 49 physical qubits to a logical qubit," so "it may require only 50 times 3,000, which is 150,000 qubits." The practical price tag is "six to seven figures range" per machine, not a garage project.

That is where I embarrassed myself. I had been quoting a machine with "1,121 qubits" and said the gap to 150,000 was a hundredfold. Doing the division in my head a few minutes later, I stopped and said, "it's not 100 times more. It's 20,000 times more." Hunter Beast let me recalibrate and landed on the useful framing: "That's plenty of time to upgrade Bitcoin," and the current hardware reminded Hunter Beast of "vacuum tube level stuff." The 20 million I had floated earlier was my own slip. The correct comparison is 20,000 times the current machine.

A BIP scoped down to one fix

BIP 360 started bigger and got cut. "We've scoped it down so narrowly that all it does really is just fix the quantum vulnerability of Taproot to long exposure attacks." There is one further feature that survived: addresses can commit to more than one script, "so that way, you can choose at spend time which script you want to spend from." The motive for trimming was political as much as technical: "we've done our best to reduce the attack surface for criticism against the change."

I asked whether this meant forcing everyone to migrate, and the answer was no. "Choose whether you spend classically or you spend, with a post-quantum signature," Hunter Beast said, and then more bluntly: "this is an opt-in thing." Wallets would not have to be rewritten from scratch either: "it wouldn't be a significant departure from the way wallets currently work."

On the signature scheme, the discussion gets nerdy fast. Hunter Beast described the SPHINCS+ family (SLH-DSA is the NIST name) as "a hypertree of deterministically generated Winternitz one-time signatures," and the hypertree in the proposal has at least 20 million public keys. "The big problem with both of those signature schemes is that they're one-time signatures," Hunter Beast said, which is why you cannot just bolt them on without thinking about structure. On size, the public key side is small, "only about like 30, 34 bytes of data," while a signature costs "something like four to 8,000 bytes." On the second figure Hunter Beast added "actually not quite large either," compared with what already lives in blocks.

Hunter Beast also raised an operational wrinkle I had not considered: "Like we always think of the entropy required to generate the key, but we never think of the entropy required to sign a signature. Anyway, that's such a nerdy point anyway."

I did ask whether this means FROST and other elliptic-curve multisig tricks are dead for the quantum-minded. The fact sheet version is that FROST relies on elliptic curves and has to be abandoned if you want quantum resistance, and Hunter Beast does not pretend otherwise.

BitZip and how to pay for fat signatures

The cost of 4 to 8 kilobytes per signature makes people reach for the block size lever, which is the oldest fight in Bitcoin. Hunter Beast does not want to pull it. "I don't think we need to increase the block size necessarily, ever really." The alternative is BitZip, a block-wide compression scheme built on ZK-STARKs, which Hunter Beast says could "scale Bitcoin by a good 10x, at least." It is not close. "Maybe within five to 10 years, we'll be much more closer to readiness with BitZip."

That timeline sets up a hard sequencing problem, and I pressed on whether a compression system that does not exist yet can justify a signature format that is expensive today. Hunter Beast's view is that the two efforts feed each other: STARK-based compression would "solve a lot of problems," and it would make the post-quantum signature bill tolerable.

On the broader stack, Hunter Beast noted that BIP 360 would make RGB fully quantum-resistant (Hunter Beast follows RGB closely) and simplify life for BitVM developers. I later recorded S17 E21 with Paul Sztorc on hard forking Bitcoin to launch Ecash with Drivechains.

The BIP bureau, a skipped range and harsh reviews

The number is a story of its own. BIP 360 sits in a range that Hunter Beast describes this way: "BIP 360 is like the reserved range for quantum stuff." The 200 range was skipped because it is reserved for Lightning Network specifications, and I joked about Udi Wertheimer and his opinions on BIP numbers. Hunter Beast made clear it was not a pick: "it certainly wasn't something I picked."

Hunter Beast is the one who coined "BIP bureau," after the Politburo, and used "elite cabal of BIP reviewers" tongue in cheek. The reviewers on the proposal include Murch, Jon Atack and Ava Chow, with Bryan Bishop among the reviewers involved. The criticism was real. "Ava also called it stupid and dumb," Hunter Beast said, and then, "It was harsh criticism, but we definitely are making decisions based on it." That is where the narrower scope came from. Hunter Beast also described the comparison, "only about 150,000 coins," as part of how reviewers sized the Taproot exposure, and summarized the resulting design as "taking something we already have, and making it smaller and do less." The status line is simple: "it's still in draft."

Hunter Beast's attitude to the process is relaxed. "It might be smart," Hunter Beast said of a skeptical review, and "I'm fine having job security for 10 years." The rule Hunter Beast lives by on timing is "being too early is the same as being wrong," which is the one thing about this subject I can fully agree with from both sides. On governance, Hunter Beast was equally plain: "plebs like literally do not matter," and as for the user-activated soft fork as a lever, "there is like the UASF, but a UASF has never occurred. It's not like it's, it's just a threat. I spoke with Giacomo Zucco on Neutrino, The B, and Bitcoin-only conferences in an earlier episode.

Stablecoins, L-BTC and a privacy model that needs math

The government-money tangent came naturally. Hunter Beast thinks "stablecoins are going to be the CBDC equivalent," and argues that $2 trillion annual deficits do more damage than commercial bank credit creation ever did. I do not touch stablecoins for the same reason, and when the topic turned to the Liquid-style tokens I said "Yeah, it sucks. I would not touch that."

On privacy, I pushed back on L-BTC. Hunter Beast's view of the thing I was defending was "they look to me like a harvest now, decrypt later system," which is the quantum framing: encrypted or blinded data that is recorded today can be broken later. On zk-SNARKs, Hunter Beast said it flat: "Except it uses zk-SNARKs." And the filter Hunter Beast applies is one question: "But what about quantum resistance?" Followed by "if it's not quantum resistant, it doesn't fit my threat model."

My answer was that I care about privacy built on math rather than on computing power: "I care about pristine, actually functional privacy that is rooted in math and not just computation. You don't just expect the hardware to get better all the time. You make it more efficient." We did not settle it, and I did not expect to.

What to do with your coins this week

The practical advice at the end of the episode was refreshingly boring. "Always use a new address whenever you receive new payments," Hunter Beast said, and "Definitely don't expose your xpub to anybody." The summary: "You should be fine." More precisely, "just don't HODL in Taproot, don't HODL in reused addresses." Native SegWit (bc1q) addresses are the recommended shape. For big transactions, Hunter Beast suggested "a private mempool like MARA Slipstream," so the transaction is not sitting in public view with its key exposed while it waits for a block.

I asked, as a non-specialist might, whether there is anything the average person should panic about. The answer was no, and Hunter Beast does not want panic as an outcome of any of this. The ask is to get the improvement proposal reviewed and, if it survives, activated well ahead of the 2030 target.

Near the end I asked the question I ask every guest: what happens to your own bitcoin? Hunter Beast joked about losing it all in a boating accident, and said investing in anything else was out of the question.

Listen to Hunter Beast on Spotify, Apple Podcasts, YouTube, and More

Time stamps:

  1. 00:01:08– Introducing Hunter Beast
  2. 00:01:27– BIP 360 and Quantum Resistance
  3. 00:02:19– Defining Bitcoin's Quantum Threat
  4. 00:03:58– U.S. Government Warnings
  5. 00:05:53– Consensus Challenges
  6. 00:06:38– Bitcoin’s Quantum Vulnerabilities
  7. 00:09:41– BIP 360 Solution for Taproot
  8. 00:13:07– Signature Schemes
  9. 00:17:10– User Experience Impact
  10. 00:20:14– Transaction Size and Costs
  11. 00:22:27– Sideshift.ai
  12. 00:23:17– Drivechains and Layer Two Labs
  13. 00:29:48– Bitcoin Ossification Debate
  14. 00:36:36– Conspiracy Theory Counter
  15. 00:54:26– Quantum Computing Progress
  16. 00:59:58– Sponsor Plugs
  17. 01:02:30– BIP 360 Number Selection
  18. 01:06:04– BIP 360 Reception from Core Devs
  19. 01:11:29– Unintended Consequences
  20. 01:12:42– Is Quantum Resistance Perishable and Needs Updates?
  21. 01:19:12– NoOnes, Bitcoin.com,
  22. 01:21:46– Best Practices for Quantum Safety
  23. 01:24:27– Closing Remarks

Verify this episode

This is the SHA-256 fingerprint of the MP3 as published here, timestamped in the Bitcoin blockchain with OpenTimestamps. If one byte of the file changes, the fingerprint changes.

SHA-256
7132216f32f0d379cacb5610c416807bb770e9e6d33d725c4382f6f0da839772
Proof
2025-07-24_s16_e33_hunter_beast_on_bitcoin_s_quantum_fragility_bip_360_-_24.07.2025_18.52.mp3.ots · all episode hashes (proof)
Status
Anchored in Bitcoin block 974,312
How to check it yourself
  1. Download the MP3 and the proof into the same folder.
  2. Run sha256sum 2025-07-24_s16_e33_hunter_beast_on_bitcoin_s_quantum_fragility_bip_360_-_24.07.2025_18.52.mp3 (on a Mac: shasum -a 256 2025-07-24_s16_e33_hunter_beast_on_bitcoin_s_quantum_fragility_bip_360_-_24.07.2025_18.52.mp3). The result must match the SHA-256 above.
  3. Install the OpenTimestamps client (pip install opentimestamps-client) and run ots verify 2025-07-24_s16_e33_hunter_beast_on_bitcoin_s_quantum_fragility_bip_360_-_24.07.2025_18.52.mp3.ots. It hashes the MP3 again and checks the proof against your own Bitcoin node, then prints the block and the date the file existed by. Without a node, ots info 2025-07-24_s16_e33_hunter_beast_on_bitcoin_s_quantum_fragility_bip_360_-_24.07.2025_18.52.mp3.ots shows the block height to look up in any block explorer.

Share: X · Email · Link

Related

Comments

Comments run on my own server. No trackers, no tracking cookies.

0:000:00