From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 16 Jul 2025 14:06:02 -0700 Received: from mail-yw1-f189.google.com ([209.85.128.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uc9KE-0005R4-1B for bitcoindev@gnusha.org; Wed, 16 Jul 2025 14:06:02 -0700 Received: by mail-yw1-f189.google.com with SMTP id 00721157ae682-70e72e81fafsf3278697b3.2 for ; Wed, 16 Jul 2025 14:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1752699956; x=1753304756; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=x4YYX55SaSKQFSvBRaFx+r2JiK9PJQIXJWJL7lX1g5U=; b=fajDwTGLs3cnA8tW7wCOLyflvVNT3vBDG9kQOhZW54wZlT7bbrYCMlO40glItzb0E+ 80pTHGnwhYhr7Lz7uZYCiHtpkiLDY3IrONkpnewcNRqgbFK01JAjH6aLDTgSLI80NkiR NH2nNnkwOdvReXWWRLWIXKyCQpeVZthN+in7t4kSzkL3U3sO7+SSILeqTTCBkRFAIDig 3MPm0VQYTA9JU6bRFwm8vPutjQf4bbUGgR1PFsuz1U71TCxemfI7UtDQVRlZrG9Kf+g8 usqf6rNmmeze1B3eX245gmC0aMNLxaUOFGVd3udjqN18UWd1iajk01kAeLYpCGx5p6wk X4fA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752699956; x=1753304756; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=x4YYX55SaSKQFSvBRaFx+r2JiK9PJQIXJWJL7lX1g5U=; b=iSI85LEzdvpihRSaByo9GcRUNNvh+B8jS+5eKnMCBh5XCbQE4vjGBfp0ols7ROhIJi 9ubW0ly/jAnFGjvzChUtGy7+SiwlQsaEtZVLa+cmBLAu4a4Y2QgRwt+OZ36G6UuL7Pep XOSACbcOHULUi485rIOju3lXBu0UboqedPR6u2ogyGBorrI5vuOe8TzFn5hJgKyCRNWy V292ncGt9GLIfj8eZBBxxeKsspTK2E5q3K1WIeGnel5GNyzIsemAtKPRHcpBzFZm1GYk Gsi1YGUxNdztziApoAOKYC1kkQPgVvcxu4wSwo1Q+vrVvklmH7MCd+wm6vyojsrCl88c BO8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752699956; x=1753304756; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=x4YYX55SaSKQFSvBRaFx+r2JiK9PJQIXJWJL7lX1g5U=; b=bciBdkj9jQDAhwCCYj6xVNvfGIJRyQmVCHv5oZ57NiVnhf3e8Y2P1o4XzuIGoUEz3T knMOZ8i9VbDhDhEdFOkjyzCw431+7/T+XWl4Zu2Idx61YUfhmv7PVvMs/cRr36OKl6iJ C+fm+5txSG+LVdHM23KkyMJgsjNNEYvqGFMNt4VqToJfUA2mKhXwvKyuTcL4xDEoLu+V urMRaZBAVV71WgR0jHDRe9jtjbxEAeZYtNFCDx1jQ/HN2T6fRazZZegzcB+2jljo1Mam bAN3wXdb7XSJ0QsYAGYBiAMZoDLV3CoWnLUXNI26Nc2w7ltxwGU1ArXNeGipvNUoQeUU JRjw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWxpoi3x5+oZiduboa4G3C6edxZpot3gNvUIhhg7Y7wkbgzCruA5krz/8Zb7qhuGjmAdQqcqQLx4GVl@gnusha.org X-Gm-Message-State: AOJu0Yy3tt8IXA2TjXKHJS5Y3D06reiJi58TpBXCjvKp8h9xVdXSSCOt HNClovN2stNcCv6AwcStNwQG7fIgjgYL+frtLJtJPHzloMz3cmRHtffj X-Google-Smtp-Source: AGHT+IGDovPrLBDT8LkPb/FZJqqUoK1aC7xA12NhAjihamO7gqF81a+NOKBjpYSnD7FmLZwK9Dnf5g== X-Received: by 2002:a05:6902:983:b0:e8b:53ba:2a2 with SMTP id 3f1490d57ef6-e8bc250f36amr5115860276.39.1752699955514; Wed, 16 Jul 2025 14:05:55 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeP6oeoF11TXNUFDnFIAhuy5/r2WIcuhbqvfON+MlHCpw== Received: by 2002:a25:d6c4:0:b0:e7d:801a:4dd6 with SMTP id 3f1490d57ef6-e8bd43ed90als360456276.0.-pod-prod-05-us; Wed, 16 Jul 2025 14:05:51 -0700 (PDT) X-Received: by 2002:a05:690c:708b:b0:712:c55c:4e65 with SMTP id 00721157ae682-71836c63d32mr59892357b3.16.1752699951095; Wed, 16 Jul 2025 14:05:51 -0700 (PDT) Received: by 2002:a05:690c:4684:b0:710:fccf:6901 with SMTP id 00721157ae682-71834b57adams7b3; Wed, 16 Jul 2025 10:34:49 -0700 (PDT) X-Received: by 2002:a05:690c:628a:b0:70f:83af:7dab with SMTP id 00721157ae682-71836c259b7mr43654897b3.4.1752687288876; Wed, 16 Jul 2025 10:34:48 -0700 (PDT) Date: Wed, 16 Jul 2025 10:34:48 -0700 (PDT) From: Boris Nagaev To: Bitcoin Development Mailing List Message-Id: <02f2130c-c024-40ce-8623-c09ceb090619n@googlegroups.com> In-Reply-To: References: <88a7b020-e84f-4052-9716-fb40b23f07ddn@googlegroups.com> Subject: Re: [bitcoindev] A Post Quantum Migration Proposal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_88998_707175299.1752687288515" X-Original-Sender: bnagaev@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 0.1 (/) ------=_Part_88998_707175299.1752687288515 Content-Type: multipart/alternative; boundary="----=_Part_88999_534962838.1752687288515" ------=_Part_88999_534962838.1752687288515 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Conduition and all! On Wednesday, July 16, 2025 at 1:48:27=E2=80=AFPM UTC-3 conduition wrote: Hey Boris and list, What if all vulnerable coins are temporarily locked during phase B, with a= =20 clearly defined future block height X (e.g., in 5-10 years) at which point= =20 these coins become EC-spendable again? Great idea. It gives us more time to get the zk-STARK proof system for=20 phase C tightened up, but we still have the option of deploying phase B=20 independently to protect procrastinators against a fast-arriving quantum=20 adversary, even if the STARK system isn't ready yet. If quantum progress is= =20 slower (or phase C development is faster) than anticipated, we also have=20 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=20 eventually permit sending to pre-quantum addresses at height X? Because as= =20 described, once phase A is locked in, we can never again permit sending to= =20 pre-quantum addresses (without a hard fork). If the proposal gets traction, it is better to replace permanent blocking= =20 with temporary restrictions in case of both sending to and spending from=20 vulnerable addresses. That way, we leave the door open for future recovery= =20 schemes without needing a hard fork. Note that permanently blocking sends to vulnerable addresses can also be=20 confiscatory. For example, someone might have a presigned transaction, like= =20 a Lightning force-close, where the destination address is a vulnerable=20 address. If that path is blocked, the funds could be lost. If sending is=20 temporary, the funds can be recovered later. If nothing is permanently blocked, and temporary blocking is intended to=20 allow legitimate owners to recover their funds, this could be seen as a=20 win-win. It is no longer one group trying to capture the purchasing power= =20 of another. However, I still have doubts about whether this is an ethical= =20 solution. I'm trying to place myself in the position of someone who can't move their= =20 funds before the deadline -- for example, a young heir with a timelocked=20 inheritance. It's genuinely difficult to say what's better: risking loss to= =20 a quantum adversary, or facing a temporary block with the prospect of=20 future recovery. It really comes down to individual risk appetite and time= =20 preference. And the challenge is, we can't ask them now -- that's the=20 nature of the problem. =20 Maybe we should also talk about BIP360 P2QRH addresses and how they'd be=20 treated by these phases. As Ethan pointed out, P2QRH addresses can contain= =20 EC signature spending conditions (OP_CHECKSIG). *Would phase B's stricter= =20 rules also block EC spends from P2QRH UTXOs*? If yes, and phase B restricts EC spending from P2QRH, users may=20 accidentally send money to P2QRH addresses whose leafs all require at least= =20 one EC signature opcode. This locks the money up until phase C, even though= =20 the purpose of phase A was to avoid exactly this from happening.=20 Restricting P2QRH EC spending also makes hybrid spending conditions, which= =20 require both EC signatures *and* PQ signatures for extra safety, harder to= =20 implement explicitly in P2QRH script - We'd need dedicated EC/PQ hybrid=20 checksig opcodes (which is an option if we want it). If no, and phase B *doesn't* restrict EC spending from P2QRH, then P2QRH=20 UTXOs with exposed EC spending leafs will be even more vulnerable to a=20 quantum attacker than those who have exposed pubkeys in pre-quantum UTXOs:= =20 Pre-quantum UTXOs would have better protection, since they are temporarily= =20 locked by phase B but P2QRH UTXOs aren't. Will phase C also unblock such EC-dependent P2QRH addresses? If so, they=20 are equally protected as classic P2PKH -- both must wait until phase C to= =20 avoid exposing a public key by spending too early. =20 Personally i think phase B should restrict ALL EC spending across all=20 script types, because at least then users can eventually reclaim their BTC= =20 when phase C rolls out. We can ameliorate the situation by properly=20 standardizing P2QRH address derivation, providing libraries to generate=20 addresses with ML-DSA and SLH-DSA leafs. We should recommend strongly=20 *against* creating P2QRH addresses without at least one post-quantum=20 spending path. To better support hybrid spending conditions in P2QRH, we should modify=20 phase B as follows: Fail any EC checksig opcode unless at least one PQ=20 checksig opcode was executed earlier in the script. This implicitly blocks= =20 spending of pre-quantum UTXOs (until the predefined height X as Boris=20 suggested). P2QRH addresses can explicitly define flexible hybrid signature= =20 schemes in the P2QRH tree using a two-leaf construction: one leaf with just= =20 OP_CHECKSIG=E2=80=8B, and one leaf with both OP_CHECKSIG=E2=80=8B *and *a P= Q checksig=20 opcode (such as OP_MLDSACHECKSIG=E2=80=8B). To nodes who have upgraded to phase A (or earlier), funds sent to this=20 address could be unlocked with the OP_CHECKSIG=E2=80=8B branch using a rela= tively=20 small witness stack. On the other hand, nodes upgraded to phase B would=20 reject the OP_CHECKSIG=E2=80=8B-only branch, because there is no PQ-checksi= g opcode=20 in the same script. Phase B nodes require the OP_MLDSACHECKSIG + OP_CHECKSI= G=E2=80=8B branch=20 to validate the spend. This branch needs a much larger witness stack, but= =20 would still permit a hybrid spend, covered by the combined security of=20 Schnorr + Dilithium. regards, conduition --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 02f2130c-c024-40ce-8623-c09ceb090619n%40googlegroups.com. ------=_Part_88999_534962838.1752687288515 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Conduition and all!

On Wednesday= , July 16, 2025 at 1:48:27=E2=80=AFPM UTC-3 conduition wrote:
Hey Boris and list,

What if all vulnerable coins are te= mporarily 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 aga= in?

Great idea. It gives us more time to = get the zk-STARK proof system for phase C tightened up, but we still have t= he option of deploying phase B independently to protect procrastinators aga= inst a fast-arriving quantum adversary, even if the STARK system isn't read= y yet. If quantum progress is slower (or phase C development is faster) tha= n 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 phas= e A though, and eventually permit sending to pre-quantum addresses at heigh= t X? Because as described, once phase A is locked in, we can never again pe= rmit 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 cas= e of both sending to and spending from vulnerable addresses. That way, we l= eave the door open for future recovery schemes without needing a hard fork.=

Note that permanently blocking sends to vulnerable addresses ca= n also be confiscatory. For example, someone might have a presigned transac= tion, like a Lightning force-close, where the destination address is a vuln= erable address. If that path is blocked, the funds could be lost. If sendin= g 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 a= nother. However, I still have doubts about whether this is an ethical solut= ion.

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 b= lock with the prospect of future recovery. It really comes down to individu= al risk appetite and time preference. And the challenge is, we can't ask th= em now -- that's the nature of the problem.
=C2=A0
Maybe we should also talk about BIP360 P2QRH addresses and= how they'd be treated by these phases. As Ethan pointed out, P2QRH address= es can contain EC signature spending conditions (OP_CHECKSIG). Would pha= se B's stricter rules also block EC spends from P2QRH UTXOs?

If yes, and pha= se 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 w= as to avoid exactly this from happening. Restricting P2QRH EC spending also= makes hybrid spending conditions, which require both EC signatures and<= /i>=C2=A0PQ 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=C2=A0restrict EC s= pending from P2QRH, then P2QRH UTXOs with exposed EC spending leafs will be= even more vulnerable to a quantum attacker than those who have exposed pub= keys in pre-quantum UTXOs: Pre-quantum UTXOs would have better protection, = since they are temporarily locked by phase B but P2QRH UTXOs aren't.
<= /blockquote>

Will phase C also unblock such EC-depende= nt P2QRH addresses? If so, they are equally protected as classic P2PKH -- b= oth must wait until phase C to avoid exposing a public key by spending too = early.
=C2=A0
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 derivatio= n, providing libraries to generate addresses with ML-DSA and SLH-DSA leafs.= We should recommend strongly against=C2=A0creating P2QRH addresses = without at least one post-quantum spending path.

To better suppo= rt 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 ex= ecuted earlier in the script. This implicitly blocks spending of pre-quantu= m 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=C2=A0OP_CHECKSIG=E2=80=8B, and one leaf with both=C2=A0OP_CHECKSIG=E2=80= =8B and a PQ checksig opcode (such as OP_MLDSACHECKSIG= =E2=80=8B).

To nodes who have up= graded to phase A (or earlier), funds sent to this address could be unlocke= d with the OP_CHECKSIG=E2=80=8B branch using a relatively smal= l witness stack. On the other hand, nodes upgraded to phase B would reject = the OP_CHECKSIG=E2=80=8B-only branch, because there is no PQ-c= hecksig opcode in the same script. Phase B nodes require the=C2=A0OP_= MLDSACHECKSIG + OP_CHECKSIG=E2=80=8B=C2=A0branch to validate the spe= nd. 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/02f2130c-c024-40ce-8623-c09ceb090619n%40googlegroups.com.
------=_Part_88999_534962838.1752687288515-- ------=_Part_88998_707175299.1752687288515--