From: Boris Nagaev <bnagaev@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A Post Quantum Migration Proposal
Date: Wed, 16 Jul 2025 10:34:48 -0700 (PDT) [thread overview]
Message-ID: <02f2130c-c024-40ce-8623-c09ceb090619n@googlegroups.com> (raw)
In-Reply-To: <gSvbx255CIbMSivfsn-1cGECh7UpJufvfVP4lwnp5r7gIamZo9t5LdBZBEYyiw4Eb9zNSvLXoi2SW8Sq3i7shSwBkWwxLRjoPkncexfCPRM=@proton.me>
[-- 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 --]
next prev parent reply other threads:[~2025-07-16 21:06 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
2025-07-16 17:34 ` Boris Nagaev [this message]
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=02f2130c-c024-40ce-8623-c09ceb090619n@googlegroups.com \
--to=bnagaev@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/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