Re: [bitcoindev] A Post Quantum Migration Proposal

[Boris Nagaev <bnagaev@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 5861 bytes --]

Hey Conduition and all!

On Wednesday, July 16, 2025 at 1:48:27 PM UTC-3 conduition wrote:

Hey Boris and list,

What if all vulnerable coins are temporarily locked during phase B, with a 
clearly defined future block height X (e.g., in 5-10 years) at which point 
these coins become EC-spendable again?


Great idea. It gives us more time to get the zk-STARK proof system for 
phase C tightened up, but we still have the option of deploying phase B 
independently to protect procrastinators against a fast-arriving quantum 
adversary, even if the STARK system isn't ready yet. If quantum progress is 
slower (or phase C development is faster) than anticipated, we also have 
the option to merge the phases B and C together into a single deployment.

If we do that, should we apply the same logic to phase A though, and 
eventually permit sending to pre-quantum addresses at height X? Because as 
described, once phase A is locked in, we can never again permit sending to 
pre-quantum addresses (without a hard fork).


If the proposal gets traction, it is better to replace permanent blocking 
with temporary restrictions in case of both sending to and spending from 
vulnerable addresses. That way, we leave the door open for future recovery 
schemes without needing a hard fork.

Note that permanently blocking sends to vulnerable addresses can also be 
confiscatory. For example, someone might have a presigned transaction, like 
a Lightning force-close, where the destination address is a vulnerable 
address. If that path is blocked, the funds could be lost. If sending is 
temporary, the funds can be recovered later.

If nothing is permanently blocked, and temporary blocking is intended to 
allow legitimate owners to recover their funds, this could be seen as a 
win-win. It is no longer one group trying to capture the purchasing power 
of another. However, I still have doubts about whether this is an ethical 
solution.

I'm trying to place myself in the position of someone who can't move their 
funds before the deadline -- for example, a young heir with a timelocked 
inheritance. It's genuinely difficult to say what's better: risking loss to 
a quantum adversary, or facing a temporary block with the prospect of 
future recovery. It really comes down to individual risk appetite and time 
preference. And the challenge is, we can't ask them now -- that's the 
nature of the problem.
 

Maybe we should also talk about BIP360 P2QRH addresses and how they'd be 
treated by these phases. As Ethan pointed out, P2QRH addresses can contain 
EC signature spending conditions (OP_CHECKSIG). *Would phase B's stricter 
rules also block EC spends from P2QRH UTXOs*?

If yes, and phase B restricts EC spending from P2QRH, users may 
accidentally send money to P2QRH addresses whose leafs all require at least 
one EC signature opcode. This locks the money up until phase C, even though 
the purpose of phase A was to avoid exactly this from happening. 
Restricting P2QRH EC spending also makes hybrid spending conditions, which 
require both EC signatures *and* PQ signatures for extra safety, harder to 
implement explicitly in P2QRH script - We'd need dedicated EC/PQ hybrid 
checksig opcodes (which is an option if we want it).

If no, and phase B *doesn't* restrict EC spending from P2QRH, then P2QRH 
UTXOs with exposed EC spending leafs will be even more vulnerable to a 
quantum attacker than those who have exposed pubkeys in pre-quantum UTXOs: 
Pre-quantum UTXOs would have better protection, since they are temporarily 
locked by phase B but P2QRH UTXOs aren't.


Will phase C also unblock such EC-dependent P2QRH addresses? If so, they 
are equally protected as classic P2PKH -- both must wait until phase C to 
avoid exposing a public key by spending too early.
 

Personally i think phase B should restrict ALL EC spending across all 
script types, because at least then users can eventually reclaim their BTC 
when phase C rolls out. We can ameliorate the situation by properly 
standardizing P2QRH address derivation, providing libraries to generate 
addresses with ML-DSA and SLH-DSA leafs. We should recommend strongly 
*against* creating P2QRH addresses without at least one post-quantum 
spending path.

To better support hybrid spending conditions in P2QRH, we should modify 
phase B as follows: Fail any EC checksig opcode unless at least one PQ 
checksig opcode was executed earlier in the script. This implicitly blocks 
spending of pre-quantum UTXOs (until the predefined height X as Boris 
suggested). P2QRH addresses can explicitly define flexible hybrid signature 
schemes in the P2QRH tree using a two-leaf construction: one leaf with just 
OP_CHECKSIG​, and one leaf with both OP_CHECKSIG​ *and *a PQ checksig 
opcode (such as OP_MLDSACHECKSIG​).

To nodes who have upgraded to phase A (or earlier), funds sent to this 
address could be unlocked with the OP_CHECKSIG​ branch using a relatively 
small witness stack. On the other hand, nodes upgraded to phase B would 
reject the OP_CHECKSIG​-only branch, because there is no PQ-checksig opcode 
in the same script. Phase B nodes require the OP_MLDSACHECKSIG + OP_CHECKSIG​ branch 
to validate the spend. This branch needs a much larger witness stack, but 
would still permit a hybrid spend, covered by the combined security of 
Schnorr + Dilithium.


regards,
conduition

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/02f2130c-c024-40ce-8623-c09ceb090619n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 8640 bytes --]