WEBVTT Automatically timed original source text; AI narration; timing not manually listen-through verified. 00:00:00.000 --> 00:00:02.940 Institutional Considerations for Post-Quantum Bitcoin. 00:00:03.200 --> 00:00:12.260 Notes from a talk by Yehuda Lindell at the Post-Quantum Bitcoin Workshop at Stanford, 28 August 2026, written by Localhost Research. 00:00:12.660 --> 00:00:14.280 This is an AI recording. 00:00:14.600 --> 00:00:19.380 Find the original text and more information on btctranscripts.com. 00:00:19.620 --> 00:00:30.930 (Background: started in pure theoretical cryptography, then moved into industry and applied work. This talk covers concerns at Coinbase and institutionally in general.) 00:00:31.890 --> 00:00:33.590 What Customers Are Saying 00:00:33.950 --> 00:00:42.670 Customers can't distinguish signal from noise. (They want to see you in a Gartner report precisely because they can't evaluate the noise themselves.) 00:00:43.310 --> 00:01:00.180 Reframing the timeline question: it's not "when will quantum computers arrive?" but "with what confidence can we bound the risk in a given time range?" If you can't rule it out with ~100% confidence, there's some percentage risk the entire ecosystem collapses. 00:01:00.980 --> 00:01:04.540 Conclusion: if it can happen, we need to move now. 00:01:04.940 --> 00:01:17.020 Real-world impact already visible: investors and institutional customers are concerned enough that it's dampening involvement and investment — pulling out or not investing at all. 00:01:17.450 --> 00:01:36.510 The biggest risk is inaction. What customers need to see is a plan, people working on solutions, and actual solutions. Ethereum has a roadmap; Bitcoin is much harder — which is why the current activity (BIPs being published) matters so much for customer confidence. 00:01:37.810 --> 00:01:41.770 The Institutional Challenge: Scale and Constraints 00:01:42.290 --> 00:01:46.270 Many blockchains to support; many different signature schemes. 00:01:46.730 --> 00:01:53.310 Institutions cannot move quickly — system changes must be disclosed to regulators and some customers. 00:01:53.910 --> 00:02:05.840 Asset migration, operational, and security challenges all require extreme care. The stakes are enormous: custodians hold people's savings and livelihoods. 00:02:05.980 --> 00:02:12.980 Three ownership models to think about: self-custody / custody / non-custodial (e.g., shared custody). 00:02:14.220 --> 00:02:17.800 MPC and Threshold Signing in a PQ World 00:02:18.160 --> 00:02:32.600 MPC/threshold signing is used heavily in custodial settings to prevent single points of failure: keys split across multiple machines and three environments — cloud, employee devices, and an offline machine in a private datacenter. 00:02:33.040 --> 00:02:40.620 MPC is crucial to the non-custodial model — but not every signature scheme has an efficient MPC protocol. 00:02:41.260 --> 00:02:48.260 For lattices: with focused community effort, Lindell believes efficient MPC protocols can be built. 00:02:48.520 --> 00:02:51.480 For hash-based signatures: a different story. 00:02:52.060 --> 00:03:00.520 Plain multisig doesn't support key rotation/refresh (proactive security) — you'd have to move funds on-chain, revealing your quorum. 00:03:01.260 --> 00:03:06.480 (Audience: what about Shamir?) — That only covers key generation, not signing. 00:03:07.080 --> 00:03:10.520 Case study: MPC for SLH-DSA 00:03:10.680 --> 00:03:19.180 Generic approach: translate signing into a Boolean circuit. Not every hash operation needs to be private, but the count is still enormous. 00:03:19.720 --> 00:03:27.080 Even at 32 bytes per AND gate, you're looking at ~66 GB of communication per signing operation. 00:03:27.460 --> 00:03:37.260 Not feasible except in very limited contexts. Something better for hash-based schemes might exist — but it's a maybe, with low confidence. 00:03:37.840 --> 00:03:45.300 Potential alternative directions: MPC-in-the-head / ZK-based approaches, or other signature families. 00:03:45.560 --> 00:04:00.620 Bottom line: the "safest" signature scheme doesn't necessarily get you to the most secure place. Securing Bitcoin doesn't just mean securing the protocol — it means securing the keys. So: did we actually land in the optimal place? 00:04:01.810 --> 00:04:05.070 Stateless vs. Stateful — an Operational View 00:04:05.070 --> 00:04:17.050 Stateless is what institutions expect: signature is a function of key and message only. Back up the key once; sign forever, in parallel, multiple times — you don't care. 00:04:17.500 --> 00:04:27.120 Stateful: a mistake means big trouble. Security assumes you can verify that state storage succeeded and was never rolled back or deleted. 00:04:28.200 --> 00:04:41.280 Institutionally: multiple server instances operate independently. With state that must be replicated, this architecture has to completely change. The theory exists, but it's hard to implement. 00:04:41.710 --> 00:04:48.750 Transactions requiring multiple signatures from a single key would become sequential (or need special handling). 00:04:49.170 --> 00:05:00.370 "I can say from experience: we have lost sync on state." That cannot be allowed to happen here. The scary case isn't knowing you lost state — it's not knowing. 00:05:00.950 --> 00:05:04.010 Mitigation: hybrid schemes until Q-Day. 00:05:05.050 --> 00:05:07.530 There Is No Single Good Choice 00:05:08.150 --> 00:05:16.950 Once you look beyond the protocol to the ecosystem, everything gets fuzzy. As Ross Anderson said: "more security is less security." 00:05:17.470 --> 00:05:19.630 Open questions posed to the room: 00:05:19.870 --> 00:05:22.590 Do we have time to wait for advanced MPC? 00:05:23.010 --> 00:05:35.530 Should Bitcoin support many signing schemes? (E.g., 1-of-N addresses with different key types, all keys hashed until used — so a vulnerability in an unused type doesn't affect security.) 00:05:36.120 --> 00:05:42.440 If no solution is good for everyone, what's the impact of a solution that's good for X but bad for Y? 00:05:42.740 --> 00:05:48.340 If we start with stateful hash-based, do we preserve the option to move to something more advanced? 00:05:48.600 --> 00:05:58.460 Should we look for MPC-friendly hash-based schemes, or MPC protocols for SHRINCS-like schemes? A question for this room and the broader cryptographic community. 00:05:59.600 --> 00:06:00.320 Q&A 00:06:00.320 --> 00:06:03.940 Q: Hybrid schemes seem popular — what are the downsides? 00:06:04.200 --> 00:06:09.960 Additional complexity is usually the enemy. More options means the weakest link will be broken. 00:06:10.420 --> 00:06:13.940 Comment (audience): on Bitcoin's security model 00:06:14.200 --> 00:06:30.780 We should think about the security assumptions that secure Bitcoin as a whole. Introducing weaker schemes becomes an existential risk. Pragmatically some optionality may be needed, but we should not add a scheme to Bitcoin unless we're confident it will remain secure. 00:06:31.400 --> 00:06:40.640 Q: If a PQ algorithm ships in ~3 years, will Coinbase require both signature schemes per address to hedge against the novel scheme? 00:06:40.880 --> 00:07:04.470 "Whatever happens, we will support it." Bottom line: Coinbase has to support every asset. Even if Bitcoin picks something requiring 1B hash operations per signature — they'll support it. It's not pretty, but workable: e.g., invert the architecture so MPC servers encrypt their output under a PQ encryption key and feed it to an offline device for signing.