TRANSCRIPTIE 🔗
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.)