From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Boris Nagaev <bnagaev@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A Post Quantum Migration Proposal
Date: Wed, 16 Jul 2025 16:43:23 +0000 [thread overview]
Message-ID: <gSvbx255CIbMSivfsn-1cGECh7UpJufvfVP4lwnp5r7gIamZo9t5LdBZBEYyiw4Eb9zNSvLXoi2SW8Sq3i7shSwBkWwxLRjoPkncexfCPRM=@proton.me> (raw)
In-Reply-To: <88a7b020-e84f-4052-9716-fb40b23f07ddn@googlegroups.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 4115 bytes --]
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).
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.
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/gSvbx255CIbMSivfsn-1cGECh7UpJufvfVP4lwnp5r7gIamZo9t5LdBZBEYyiw4Eb9zNSvLXoi2SW8Sq3i7shSwBkWwxLRjoPkncexfCPRM%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 6610 bytes --]
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
next prev parent reply other threads:[~2025-07-16 16:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-12 21:36 Jameson Lopp
2025-07-13 23:19 ` [bitcoindev] " Tadge Dryja
2025-07-14 2:07 ` Antoine Riard
2025-07-14 16:08 ` Ethan Heilman
2025-07-15 2:50 ` Boris Nagaev
2025-07-14 18:52 ` Jameson Lopp
2025-07-19 12:05 ` Peter Todd
2025-07-20 15:56 ` 'conduition' via Bitcoin Development Mailing List
2025-07-20 17:39 ` Marin Ivezic
2025-07-14 13:50 ` Jameson Lopp
2025-07-15 2:32 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
2025-07-15 14:13 ` Boris Nagaev
2025-07-16 16:43 ` 'conduition' via Bitcoin Development Mailing List [this message]
2025-07-16 17:34 ` Boris Nagaev
2025-07-20 15:37 ` 'conduition' via Bitcoin Development Mailing List
2025-07-15 17:57 ` Ethan Heilman
2025-07-20 22:54 ` [bitcoindev] " Boris Nagaev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='gSvbx255CIbMSivfsn-1cGECh7UpJufvfVP4lwnp5r7gIamZo9t5LdBZBEYyiw4Eb9zNSvLXoi2SW8Sq3i7shSwBkWwxLRjoPkncexfCPRM=@proton.me' \
--to=bitcoindev@googlegroups.com \
--cc=bnagaev@gmail$(echo .)com \
--cc=conduition@proton$(echo .)me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox