WEBVTT Automatically timed original source text; AI narration; timing not manually listen-through verified. 00:00:00.000 --> 00:00:01.880 Breakout Session: DropKick. 00:00:02.180 --> 00:00:11.840 Notes from the breakout session led by conduition at the Post-Quantum Bitcoin Workshop at Stanford, 28 August 2026, written by Localhost Research. 00:00:12.240 --> 00:00:13.700 This is an AI recording. 00:00:14.000 --> 00:00:18.720 Find the original text and more information on btctranscripts.com. 00:00:19.020 --> 00:00:20.480 Reframing "rescue" 00:00:21.100 --> 00:00:30.560 Rescue protocols are often conflated with confiscation — but confiscation is not a requirement. The key concept is knowledge asymmetry. 00:00:31.020 --> 00:00:32.840 The post-Q-Day landscape 00:00:33.450 --> 00:00:46.730 Today, everyone is on legacy (pre-quantum) addresses. After a PQ output type is deployed, on Q-Day there will be coins that are PQ-safe and coins that are not — we only worry about the latter. 00:00:47.450 --> 00:01:00.450 Those users' keys are usually BIP32-derived, sometimes behind hashes. Crucially, these users know things a quantum computer does not — but this isn't uniform across the UTXO set: 00:01:00.870 --> 00:01:13.530 A never-used P2PKH address: the owner knows the preimage of their pubkey hash → asymmetry exists (assuming they never shared an xpub or the pubkey — a big assumption). 00:01:14.380 --> 00:01:34.110 A used P2WPKH address: the pubkey is exposed → no hash asymmetry. But they may have another one — BIP32 hardened derivation is quantum-secure, and most wallets never share root-level xpubs, so most BIP32 wallets retain this asymmetry. 00:01:35.050 --> 00:01:50.260 These asymmetries are not provable on-chain as-is — but we can introduce encumbrances on those UTXOs that let owners prove them (e.g., "prove you knew your public key before the quantum computer did"). That's what rescue protocols do. 00:01:50.440 --> 00:01:52.160 What counts as an asymmetry 00:01:52.160 --> 00:01:55.110 ✅ Asymmetries: ❌ Not asymmetries. 00:01:55.500 --> 00:01:58.060 Hashed addresses: Encrypted WIFs. 00:01:59.000 --> 00:02:03.510 BIP32 hardened derivation (≥1 hardened step): FROST keys. 00:02:04.430 --> 00:02:07.590 MuSig key aggregation: FROST signature nonces. 00:02:08.580 --> 00:02:09.320 BIP39. 00:02:09.660 --> 00:02:12.260 Knowledge of tapscript / Taproot tweaks. 00:02:13.960 --> 00:02:28.360 Generalization: think of each asymmetry as a quantum-hard one-way function, a statement f(x) = y. Abstracting to that generic object lets you plug any of them into a rescue protocol: proving you knew the witness before the quantum attacker did. 00:02:28.850 --> 00:02:32.290 Why not just create new asymmetries / migrate today? 00:02:32.810 --> 00:02:39.230 If people were willing to act, they'd just move to PQ outputs. They may not want to reveal themselves or pay fees. 00:02:39.910 --> 00:02:58.490 If you are standardizing ahead of time, why not standardize pre-registration (an obvious on-chain action)? Note: pre-registration must be standardized before use, or you risk making a commitment you can't redeem. That's out of scope here — this session covers what we can do after Q-Day. 00:02:58.980 --> 00:03:00.760 Two flavors of rescue protocol 00:03:01.180 --> 00:03:03.100 1. ZK protocols 00:03:04.000 --> 00:03:08.780 Prototypes exist (STARKs over BIP32 hardened derivation): 00:03:09.670 --> 00:03:13.650 roasbeef: proving time of a few seconds, but very large proofs 00:03:14.270 --> 00:03:16.690 P11: fast, but also large 00:03:17.630 --> 00:03:26.920 Proofs can be aggregated (complicated across different hash functions). Proof sizes can shrink from ~500 KB to ~50 KB with more proving time. 00:03:27.700 --> 00:03:35.600 Drawback: ZK only works for certain knowledge asymmetries; others require posting your witness with the spending transaction. 00:03:36.610 --> 00:03:42.450 Perspective: in a world where rescue protocols are in play, "we don't care so much about hard forks." 00:03:43.390 --> 00:03:46.310 2. Commit/reveal protocols 00:03:47.190 --> 00:03:52.690 Requirements: a timestamping system (the blockchain itself) and a hash function. 00:03:53.960 --> 00:04:14.180 Mechanics: hash your witness commitment together with a message, hide it in a particular block → wait → then reveal the witness and message. Anyone (assuming reorgs are impossible past some depth) can verify. Effectively, f(x) becomes a public key: anyone who knew x could have made the commitment. 00:04:14.920 --> 00:04:17.120 DropKick and Lifeboat are the two examples. 00:04:17.850 --> 00:04:21.320 Lifeboat vs. DropKick: locating commitments 00:04:21.320 --> 00:04:24.710 How does a verifier find the commitment on-chain? 00:04:25.780 --> 00:04:37.070 Lifeboat: uses an index — commitments flagged at the end of an OP_RETURN. But nothing proves a flagged entry is a true commitment, so the index can be griefed. 00:04:37.730 --> 00:04:51.950 DropKick: no index — the signer supplies a proof π (OpenTimestamps-style) that the commitment was included in a specific block: a Merkle/SPV-style proof revealing the path to the block hash. 00:04:52.670 --> 00:04:55.390 Upside: verifiers keep no indexes. 00:04:56.150 --> 00:05:02.910 Downside: π can be ~1 KB — "not the end of the world." (But is the index really that bad?) 00:05:03.290 --> 00:05:05.230 Miner censorship & game theory 00:05:06.030 --> 00:05:12.830 Lifeboat is not vulnerable to censorship-based theft: the index lets you show you were the first valid commitment. 00:05:14.040 --> 00:05:23.220 DropKick offers no such protection: a miner seeing your reveal in the mempool could censor/reorg it and insert their own commitment in the meantime. 00:05:23.990 --> 00:05:40.270 DropKick therefore relies on game-theoretic arguments: each reveal must carry a fee proportional to the input value — roughly fee > (input value) / (blocks you must wait) — to incentivize miners to include your transaction rather than attack it.