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