Bản chép lời đầy đủ của Panel: Output Type Design Considerations

WEBVTT Automatically timed original source text; AI narration; timing not manually listen-through verified. 00:00:00.000 --> 00:00:02.520 Output Type Design Considerations. 00:00:02.520 --> 00:00:16.940 Notes from a panel with Pieter Wuille and conduition, moderated by Justin of Localhost Research, at the Post-Quantum Bitcoin Workshop at Stanford, 28 August 2026, written by Mike Schmidt. 00:00:17.360 --> 00:00:19.220 This is an AI recording. 00:00:19.850 --> 00:00:24.910 Find the original text and more information on btctranscripts.com. 00:00:25.050 --> 00:00:30.170 Reference: delvingbitcoin.org — PQC output type discussion 00:00:31.150 --> 00:00:31.690 Framing 00:00:32.410 --> 00:00:38.310 Topic: how do PQ schemes hook into Bitcoin consensus — output types and their design? 00:00:38.630 --> 00:00:49.350 This isn't Bitcoin's first output-type transition (BIP11, BIP16, SegWit, Taproot) — but this time we're more informed, with real usage and migration data. 00:00:50.600 --> 00:00:52.060 The Two Main Proposals 00:00:52.060 --> 00:00:54.520 P2TRv2 (Pieter) 00:00:54.520 --> 00:01:08.700 Background: Taproot's key path / script path design, with unused paths hidden. Taproot hasn't seen the adoption hoped for — partly because the low-feerate environment blunts its space savings. 00:01:10.030 --> 00:01:16.690 P2TRv2 = P2TR with PQC opcodes / leaf types added. 00:01:17.420 --> 00:01:27.280 Crucially, with the explicit agreement and clear expectation that a user opting into this output type accepts that EC spending can and will be disabled. 00:01:28.180 --> 00:01:30.260 P2MR (Conduition) 00:01:30.620 --> 00:01:35.160 P2TR with EC key tweaking removed (~360 origins). 00:01:36.360 --> 00:01:42.260 No depth-zero trees — removes the mal-incentive toward a single spending condition, which degraded privacy. 00:01:42.820 --> 00:01:51.860 Possible combinations with other ideas: CISA, key recovery — since P2MR is less efficient to use pre-Q-Day. 00:01:53.030 --> 00:01:53.930 The Tripwire 00:01:53.930 --> 00:02:07.620 Codifies the expectation of disabling EC spending: if secp DLP is demonstrably broken (example triggers were listed), EC spending in P2TRv2 is disabled. 00:02:08.840 --> 00:02:20.080 Disabling applies only to P2TRv2 — not P2TR or other types. Because it's explicit in the output type, it avoids being seen as confiscation. 00:02:20.840 --> 00:02:40.240 Pieter doesn't actually expect EC disabling to happen via the tripwire — its purpose is an upper bound that forces users to take EC-disabling seriously, removes doubt, and removes the risk of EC disabling in it being considered confiscatory among users and potential migrators. 00:02:41.250 --> 00:02:43.490 Criticisms and alternatives discussed: 00:02:44.300 --> 00:02:47.720 Some see it as "at best a psychological thing." 00:02:48.340 --> 00:03:02.720 Similar proposals use toy curves — a ladder of increasing curve sizes — but there's no way to know whether attack progress will be fast or slow, and individuals can run such demonstrations independent of consensus rules. 00:03:03.830 --> 00:03:12.130 Tripwires could serve other purposes too (e.g., triggering rescue protocols), not just EC disabling. 00:03:13.590 --> 00:03:23.070 Incentivization: tripping the wire is a public good (cf. Google's demonstrations) — people could donate to the tripwire address to form a bounty. 00:03:24.660 --> 00:03:27.960 Steal vs. Freeze — "The Existential Threat" 00:03:28.990 --> 00:03:36.190 "The biggest threat, the hardest problem, is the steal-vs-freeze discussion" over Satoshi-era coins: 00:03:37.330 --> 00:03:44.300 Letting quantum computers steal violates the expectations people have of cryptocurrency — what's the point? 00:03:45.700 --> 00:03:51.600 Freezing coins — then what distinguishes Bitcoin from anything else, if coins can be frozen? 00:03:52.840 --> 00:03:57.220 Taking coins out of this equation — via migration — is the priority. 00:03:58.920 --> 00:04:02.530 Witness Structure & Costing PQ Signatures 00:04:03.460 --> 00:04:14.070 Pieter: introducing a new witness is a big step (but slightly less than segwit was), especially for hash-based signatures, given the bytes-vs-cost distinction. 00:04:15.290 --> 00:04:23.030 Effectively a block size increase available only to PQ signatures — justified because those bytes are easier to process. 00:04:24.290 --> 00:04:35.940 On costing: you could price PQ sigs per-byte like Schnorr, but that doesn't make sense — instead I argue for something based on both bandwidth and computation costs. 00:04:36.690 --> 00:04:42.470 Audience member comment: keep throughput the same and adjust the costs, alternatively 00:04:43.420 --> 00:04:51.200 Response to the above: Keeping the throughput the same is a technical possibility, not a goal on itself.. 00:04:52.450 --> 00:05:10.260 PQ data blob / new witness lessons learned: DoS concerns exist just at the P2P layer, plus data structures get duplicated everywhere. You can introduce a new witness and nest the old hash inside it — somewhat less painful to upgrade than the original SegWit witness. 00:05:11.440 --> 00:05:13.800 Should We Wait for Better Cryptography? 00:05:14.410 --> 00:05:23.830 Today's cryptography doesn't let Bitcoin migrate fully to PQ (no HD keys, limited confidence in schemes, etc.). 00:05:24.400 --> 00:05:37.750 To avoid the freeze/steal dilemma, migration should start sooner — especially for the long tail. The scheme should be reasonably adoptable by everyone (industry, Lightning, etc.). 00:05:38.950 --> 00:05:51.200 Having "something" people can adopt is enough to establish Bitcoin as quantum-ready ("street cred"). Throwing more features in risks delaying implementation and activation. 00:05:52.170 --> 00:05:53.970 Real-world adoption constraints: 00:05:54.750 --> 00:06:01.670 Engineering cost for the ecosystem (wallets — including multicoin wallets that rarely ship Bitcoin updates) 00:06:02.290 --> 00:06:06.920 Users must want to adopt it; fee considerations matter 00:06:07.720 --> 00:06:10.760 Witness changes are more invasive and more political 00:06:12.260 --> 00:06:13.720 Recommendations & Comparison 00:06:14.810 --> 00:06:26.980 Pieter's short-term recommendation: P2TRv2 with tripwire, using the simplest PQ signature scheme. P2MR later, or with a more advanced scheme. 00:06:28.510 --> 00:06:46.770 User/usage types influence the approach: assuming perfect usage (no address reuse or key disclosure), P2MR is PQ-secure — but assuming perfection isn't great. Thus the tripwire applies equally to both proposals. 00:06:47.110 --> 00:06:55.710 P2TRH was covered at a high level — summarized as "a weird middle ground" and not an easy-to-roll-out solution. 00:06:56.950 --> 00:07:05.090 A hash-based first step is the conservative option and can migrate the long tail of users without further action on their part. 00:07:06.220 --> 00:07:09.080 CISA / Signature Aggregation Impact 00:07:09.080 --> 00:07:18.360 Brief overview of cross-input signature aggregation (DahLIAS, etc.): more efficient blockspace use, lower fees. 00:07:18.860 --> 00:07:33.770 More beneficial to P2TRv2 than P2MR (P2MR needs the pubkey among other fields; 64-byte lower bound; half-agg gives ~96 bytes with P2MR). 00:07:34.470 --> 00:07:41.870 Note: these benefits exist only pre-Q-Day. Audience comment: this incentive muddies the waters. 00:07:43.380 --> 00:07:44.440 Audience Q&A 00:07:45.070 --> 00:08:15.010 Should the output type discussion be tied to a new PQ opcode? Runs into confiscation risks; P2TRv2 already carries both EC and PQ options. There's no realistic enforcement mechanism — that's what the tripwire is for — and people could just add a dummy key if forced. Since P2TRv2 has no other advantages, the whole point of using it is PQ. 00:08:15.670 --> 00:08:33.850 Spending from PQ back to quantum-vulnerable outputs defeats confidence — can it be made one-way? Idea floated: a standardness rule refusing to relay PQ→quantum-vulnerable spends. Pieter sees this as unrealistic — you couldn't pay "anyone" anymore. 00:08:35.020 --> 00:08:46.280 Special key-path key signaling the key path is disabled? No benefit vs. P2MR; feels hacked-in. (Debate about whether it eases deployment.) 00:08:47.370 --> 00:09:11.850 NUMS point generation for the tripwire? Options discussed for a BIP-specified generation process; also an OP_RETURN-with-private-key option; also: a Taproot script-only key put on chain — if it's ever spent via key path, that's proof DLP is broken. Counterpoint: a rational attacker will simply avoid the tripwire. 00:09:12.320 --> 00:09:19.400 Is the tripwire immediate, or does it take effect next targeting period? (Raised; discussion not captured.)