From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 20 Jul 2025 09:06:51 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1udWYs-0007i8-GF for bitcoindev@gnusha.org; Sun, 20 Jul 2025 09:06:51 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-2ffa5b5f321sf2522514fac.0 for ; Sun, 20 Jul 2025 09:06:50 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1753027604; cv=pass; d=google.com; s=arc-20240605; b=Wgmo5cntgG+KegEMMIQYq6Pb4B0bdRSqUAfdJ2vd0ZFx/nbHtDpkzIj9Y6R9ENiJJP Awd0ZNe7pl6+EiAE/zveguWOzvLWAqHayNhtTzSekuVIMjqxZU6g0I8LLTx24068Me6p CmNTKxJH3nqMheFc3gQfQc73e/kFDDNOsvvMwSw8AKliiU50/LiT53QmGRz0kCtQFbP9 OJMNlcGKTlUpCWixY5d6WD5j6ZXS5Pb9A/685IaqjrlJi/f5/5uR9aCv5wK9S/Ub4cxq znWn4UXGIguavm7j5zJSDnP7O1Wb4wAl5AEDqerDr5jp4f5K1MxJVPI3boLKOKOnQv3z 0NEA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=FBwcEOoZzlZESe88D8QQKv2yIMXFRCvRB+/sN3FbGKk=; fh=NJ8izJBy1uzTzi0xOZt0lcLIO5XV6IrPqC6X76zuxpw=; b=ZacRslyjlKiz1IiFRNCXScCXFVuuYeO2Sas7+9Cfni/YcLL+JWG8wqFBLPuuhIyXW0 B0o+I/lDvrCilF3F7bQrFco8pMWO9lfhDvCSiDI2OYZ/3ZQl2sDvaRrb1p+BoJyN/LFJ 61Tw0SK04/Cr9/3LRnCFZBetIp2FyDA6y8JEYmKtXsTxjCL1cFpNEiRwLJDUVvwJ0lvF PjFVsoGxSkMk2yL0a3zRxY0uoS/d8g/kAklNS65ecWRjWKWKqD6s7Rtmp74sm1KszQvM xVdorwJdQZLDMSKN383is5v8X/Bv+mIQbkx10mUpm75tvxtjT1U5mvyqfEngN1PkwlMc Abzg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=IClwIPer; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.28 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1753027604; x=1753632404; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=FBwcEOoZzlZESe88D8QQKv2yIMXFRCvRB+/sN3FbGKk=; b=qKPTyRbNjDzN116HnACASdnU+K/3kcXwB9vUu9bIGAKKQ63gtdusxY9SCvu7s/AVp6 Eg894beB++vZortClRN/oX/43CM4phMv8kQG3m4VHRlC8op5A/GX1TYvLdEyx70mp5jQ zqaFsZljmvjO3WvvKTKJFmD6zlO2slzwpDYl5t9ilgPnYVZwL0gOpJY47x+sOXdhPiRl X7WSR/Nf5Hk3OggKh7PmdRO9ux1SCb1fF7rQHHW/q3Tpsw6OV10hTzqjjw6TNN4csna6 DgkMsQ3eLmhtodonev+3g7Ey1oct3FcrEpI+TDUsiQ+jLgDoVQWjzxRCm4TBdsn0kRk+ BkHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753027604; x=1753632404; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FBwcEOoZzlZESe88D8QQKv2yIMXFRCvRB+/sN3FbGKk=; b=VmyQJzrFSWq/9hjPdTtBUwurlLgV6crUQnYJ7oC3yNA2Zaowi0PN9F2G25mL9uYkJ+ 6lEEVbTV98FhpxSTpXHn2aa+9ojubMnKsiQHA5J0/OHWmnc3iQdSCDVOXaiFoWghsUgX 7nr0jsykqeS1y1Bj7zfdY70lENJszsUtrmds9rPilMbKCQhxF55UtvijfeNgAJsNBt/2 SCe5kczAKeckb3xIRE8zK5fwUsd5GeV7MPcee4EfOkWSPDbuXc4zF0S2j93ZZL6bgjOf 7G7O1i41P5wLRWy70SDmfR00lt+SeAcxnQnaZ68HKt332F24cMlES5oCm/hwta6xrIwI Z7pw== X-Forwarded-Encrypted: i=2; AJvYcCU9vjAE3MK7LoaBsmCYlR6Ke3/7cz7KQvlWVZhDtez9saaAHHjcqplG5kWlRG9cxbIsCl5QIJKLwwpk@gnusha.org X-Gm-Message-State: AOJu0YyXVy63twe27C7FOJW2rZbc0R3xDIuiy2EU61d4ZD9wla0fS42y 1S9ajsKfFQ25y2kb0z0bbfyak4Uc+tL3lIPNaoTF3Oc4DL+PmIA3sctQ X-Google-Smtp-Source: AGHT+IEudZPatZsq2m+Yu6JdNkX9vZvaAOAS25LzlAWsqy/MNfHqtNEEMPqwwg/Enpr7DtSrJGMl8Q== X-Received: by 2002:a05:6871:5a11:b0:2b8:78c0:2592 with SMTP id 586e51a60fabf-2ffb244a887mr11106308fac.23.1753027604247; Sun, 20 Jul 2025 09:06:44 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfCoOaqA59ZhWQDAwfxU4R2lYNbiSesDBqqVohgtzWwQA== Received: by 2002:a05:6870:6c02:b0:2ff:8cb6:b720 with SMTP id 586e51a60fabf-2ffca3d2a0als2607183fac.0.-pod-prod-05-us; Sun, 20 Jul 2025 09:06:41 -0700 (PDT) X-Received: by 2002:a05:6808:4494:b0:40b:441e:3a5f with SMTP id 5614622812f47-41d04d8a574mr10759582b6e.25.1753027600943; Sun, 20 Jul 2025 09:06:40 -0700 (PDT) Received: by 2002:a05:600c:a297:b0:456:53b:5b5e with SMTP id 5b1f17b1804b1-4563a8f4e6bms5e9; Sun, 20 Jul 2025 08:37:15 -0700 (PDT) X-Received: by 2002:a05:600c:4ecd:b0:456:fdd:6030 with SMTP id 5b1f17b1804b1-4562e373d83mr169117575e9.19.1753025833353; Sun, 20 Jul 2025 08:37:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1753025833; cv=none; d=google.com; s=arc-20240605; b=axvRZuavpz9JUbHJurlHHfz6WviriyyuTic+bgvsesVOB6hAmh69fIuFoXpBPTi9KM 3zeqsbiN2jPC+tIb92RpT7/jV7VT8fguzmGTF8uMTNVhOY2/xZAda27KTyCXkqGfTwIw p4MG0SM95Iur0PGlpa0+6xa3Lo5orVVC9Ch/klpUai0MjrS8bRju1+Qgv68lw4JfpSmb tikK+rNDpZtqZ9tMUin8Tab+rqEwgUDwW0nGgLZb+HDWmpoajwy7s0+eChzmJ09pNmMV 493nAOJYAel777TJSOddx9iRC6EfP95cIngtu9iOisW+SG+cvffnCuVuFLPnANVALhgK 9sew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=XLqfEydL5ZVSvd/+viPzp1ID829BUL+VDX/EMOZJdiQ=; fh=6b1pLcW6tcZ6I7AhOCDpUTdU/HBZRb+DjIxd1ga4+Sc=; b=TwONmaFD46hQDB0KYGsWgmFgUFdfKiO/rkAWOzKKmy4XTV7H5Glyi2pYtP86j2y2qn e0s3YA8fjnkec/eAR7xFVtMdAbIr/B+BXkRbdRq0nZ/RHot1LO/gQRWpVH30puic6EeD jhB6hdD+Q8ZNxKIbzv03HUDfPzm9+IBvF4xFntRQRryL0RMOmPZ1LeYXSqC/2tZDHumo +3DevGyWZqd14LpkPEzcGF9+ZiMUDz9+/dem10Uk7UbyXTD4nZuHIWH8h4yuZDVkEVPa fz85j1vgBJs4c8fd5nKSUloL/HI5Ee+zbF6im0katZpZnLQM7MeBcYUHoFlSBMVk/fTW u63g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=IClwIPer; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.28 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch. [79.135.106.28]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-45627899918si4009795e9.1.2025.07.20.08.37.13 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 20 Jul 2025 08:37:13 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.28 as permitted sender) client-ip=79.135.106.28; Date: Sun, 20 Jul 2025 15:37:05 +0000 To: Boris Nagaev From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] A Post Quantum Migration Proposal Message-ID: In-Reply-To: <02f2130c-c024-40ce-8623-c09ceb090619n@googlegroups.com> References: <88a7b020-e84f-4052-9716-fb40b23f07ddn@googlegroups.com> <02f2130c-c024-40ce-8623-c09ceb090619n@googlegroups.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 9287953f8bb0294bb187ab3492ce485972df5024 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------9ac74a0ec5295f78b5947e7333939603053aecebf35b3bb386e7f3c7129cdb08"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=IClwIPer; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.28 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------9ac74a0ec5295f78b5947e7333939603053aecebf35b3bb386e7f3c7129cdb08 Content-Type: multipart/mixed;boundary=---------------------483d638301960e48d863ca115c276842 -----------------------483d638301960e48d863ca115c276842 Content-Type: multipart/alternative;boundary=---------------------e8a7cf808aa2130caf35992785a36afe -----------------------e8a7cf808aa2130caf35992785a36afe Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > 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 a= void exposing a public key by spending too early. @Boris Yes, this should definitely be the case. Restrictions should be base= d on cryptographic operations needed to spend, not by output script type br= oadly. Though in the case of P2QRH, the best case should be that everyone u= sing P2QRH includes a leaf script that supports post-quantum opcodes, even = if they're not fully defined yet. Then spending with PQ crypto is as easy a= s a software update. regards, conduition On Wednesday, July 16th, 2025 at 5:05 PM, Boris Nagaev = wrote: > Hey Conduition and all! >=20 > On Wednesday, July 16, 2025 at 1:48:27=E2=80=AFPM UTC-3 conduition wrote: >=20 > > Hey Boris and list, > >=20 > >=20 > > > What if all vulnerable coins are temporarily locked during phase B, w= ith a clearly defined future block height X (e.g., in 5-10 years) at which = point these coins become EC-spendable again? > >=20 > >=20 > >=20 > > 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 ind= ependently to protect procrastinators against a fast-arriving quantum adver= sary, even if the STARK system isn't ready yet. If quantum progress is slow= er (or phase C development is faster) than anticipated, we also have the op= tion to merge the phases B and C together into a single deployment. > >=20 > > If we do that, should we apply the same logic to phase A though, and ev= entually permit sending to pre-quantum addresses at height X? Because as de= scribed, once phase A is locked in, we can never again permit sending to pr= e-quantum addresses (without a hard fork). >=20 >=20 >=20 > If the proposal gets traction, it is better to replace permanent blocking= with temporary restrictions in case of both sending to and spending from v= ulnerable addresses. That way, we leave the door open for future recovery s= chemes without needing a hard fork. >=20 > 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 add= ress. If that path is blocked, the funds could be lost. If sending is tempo= rary, the funds can be recovered later. >=20 > 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. >=20 > I'm trying to place myself in the position of someone who can't move thei= r 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 futu= re recovery. It really comes down to individual risk appetite and time pref= erence. And the challenge is, we can't ask them now -- that's the nature of= the problem. >=20 > > Maybe we should also talk about BIP360 P2QRH addresses and how they'd b= e treated by these phases. As Ethan pointed out, P2QRH addresses can contai= n EC signature spending conditions (OP_CHECKSIG). Would phase B's stricter = rules also block EC spends from P2QRH UTXOs? > >=20 > > If yes, and phase B restricts EC spending from P2QRH, users may acciden= tally 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 p= urpose of phase A was to avoid exactly this from happening. Restricting P2Q= RH EC spending also makes hybrid spending conditions, which require both EC= signatures and PQ signatures for extra safety, harder to implement explici= tly in P2QRH script - We'd need dedicated EC/PQ hybrid checksig opcodes (wh= ich is an option if we want it). >=20 > > 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 quan= tum attacker than those who have exposed pubkeys in pre-quantum UTXOs: Pre-= quantum UTXOs would have better protection, since they are temporarily lock= ed by phase B but P2QRH UTXOs aren't. >=20 >=20 > 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 a= void exposing a public key by spending too early. >=20 > > Personally i think phase B should restrict ALL EC spending across all s= cript types, because at least then users can eventually reclaim their BTC w= hen phase C rolls out. We can ameliorate the situation by properly standard= izing P2QRH address derivation, providing libraries to generate addresses w= ith ML-DSA and SLH-DSA leafs. We should recommend strongly against creating= P2QRH addresses without at least one post-quantum spending path. > >=20 > > 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 che= cksig opcode was executed earlier in the script. This implicitly blocks spe= nding of pre-quantum UTXOs (until the predefined height X as Boris suggeste= d). P2QRH addresses can explicitly define flexible hybrid signature schemes= in the P2QRH tree using a two-leaf construction: one leaf with just OP_CHE= CKSIG, and one leaf with both OP_CHECKSIG and a PQ checksig opcode (such as= OP_MLDSACHECKSIG). > >=20 > > 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 sm= all witness stack. On the other hand, nodes upgraded to phase B would rejec= t the OP_CHECKSIG-only branch, because there is no PQ-checksig opcode in th= e same script. Phase B nodes require the OP_MLDSACHECKSIG + OP_CHECKSIG bra= nch to validate the spend. This branch needs a much larger witness stack, b= ut would still permit a hybrid spend, covered by the combined security of S= chnorr + Dilithium. > >=20 > >=20 > > 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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/02f2130c-c024-40ce-8623-c09ceb090619n%40googlegroups.com. --=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/= a9xGMAv-oogmIdFuXMuXcgn_dkcCrIX9UNjXA-UuTqKrp6Tn8n6Q6usj33q66tr9SVP_jRpzeeq= 7Bw9wgcwCXsv2H5QTA1WL_JKvPH0eFdU%3D%40proton.me. -----------------------e8a7cf808aa2130caf35992785a36afe Content-Type: multipart/related;boundary=---------------------a702f8253f9222a563439779dafe5b26 -----------------------a702f8253f9222a563439779dafe5b26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Will phase C also unblock such EC-dependent P2QRH addresses? If so, t= hey are equally protected as classic P2PKH -- both must wait until phase C = to avoid exposing a public key by spending too early.

=
@Boris Yes, this should definitely be the case. Restrictions sho= uld be based on cryptographic operations needed to spend, not by output scr= ipt type broadly. Though in the case of P2QRH, the best case should be that= everyone using P2QRH includes a leaf script that supports post-quantum opc= odes, even if they're not fully defined yet. Then spending with PQ crypto i= s as easy as a software update.

regards,
conduition
On Wednesday, July 16th, 2025 at 5:05 PM, Boris Nagaev <bnagaev@= gmail.com> wrote:
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 clearly defined future block = height X (e.g., in 5-10 years) at which point these coins become EC-spendab= le again?

Great idea. It gives us more time t= o 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 a= gainst a fast-arriving quantum adversary, even if the STARK system isn't re= ady yet. If quantum progress is slower (or phase C development is faster) t= han anticipated, we also have the option to merge the phases B and C togeth= er 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 i= s better to replace permanent blocking with temporary restrictions in case = of both sending to and spending from vulnerable addresses. That way, we lea= ve 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 t= emporary, the funds can be recovered later.

If not= hing is permanently blocked, and temporary blocking is intended to allow le= gitimate 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 hei= r with a timelocked inheritance. It's genuinely difficult to say what's bet= ter: risking loss to a quantum adversary, or facing a temporary block with = the prospect of future recovery. It really comes down to individual risk ap= petite 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 stricte= r rules also block EC spends from P2QRH UTXOs?

If yes, and phase B restricts E= C spending from P2QRH, users may accidentally send money to P2QRH addresses= whose leafs all require at least one EC signature opcode. This locks the m= oney up until phase C, even though the purpose of phase A was to avoid exac= tly this from happening. Restricting P2QRH EC spending also makes hybrid sp= ending conditions, which require both EC signatures and PQ signature= s for extra safety, harder to implement explicitly in P2QRH script - We'd n= eed 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 qua= ntum attacker than those who have exposed pubkeys in pre-quantum UTXOs: Pre= -quantum UTXOs would have better protection, since they are temporarily loc= ked 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 a= void exposing a public key by spending too early.
Personally i think phase B should restrict ALL EC spending acr= oss all script types, because at least then users can eventually reclaim th= eir BTC when phase C rolls out. We can ameliorate the situation by properly= standardizing P2QRH address derivation, providing libraries to generate ad= dresses with ML-DSA and SLH-DSA leafs. We should recommend strongly agai= nst creating P2QRH addresses without at least one post-quantum spending= path.

To better support hybrid spending conditions in P2QRH, we s= hould modify phase B as follows: Fail any EC checksig opcode unless at leas= t one PQ checksig opcode was executed earlier in the script. This implicitl= y blocks spending of pre-quantum UTXOs (until the predefined height X as Bo= ris suggested). P2QRH addresses can explicitly define flexible hybrid signa= ture schemes in the P2QRH tree using a two-leaf construction: one leaf with= just OP_CHECKSIG=E2=80=8B, and one leaf with both OP_CH= ECKSIG=E2=80=8B and a PQ checksig opcode (such as OP_ML= DSACHECKSIG=E2=80=8B).

=
To no= des who have upgraded to phase A (or earlier), funds sent to this address c= ould be unlocked with the OP_CHECKSIG=E2=80=8B branch using a = relatively small witness stack. On the other hand, nodes upgraded to phase = B would reject the OP_CHECKSIG=E2=80=8B-only branch, because t= here is no PQ-checksig opcode in the same script. Phase B nodes require the= OP_MLDSACHECKSIG + OP_CHECKSIG=E2=80=8B branch to validate th= e spend. This branch needs a much larger witness stack, but would still per= mit 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 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= .

--
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/bitcoindev/a9xGMA= v-oogmIdFuXMuXcgn_dkcCrIX9UNjXA-UuTqKrp6Tn8n6Q6usj33q66tr9SVP_jRpzeeq7Bw9wg= cwCXsv2H5QTA1WL_JKvPH0eFdU%3D%40proton.me.
-----------------------a702f8253f9222a563439779dafe5b26-- -----------------------e8a7cf808aa2130caf35992785a36afe-- -----------------------483d638301960e48d863ca115c276842 Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------483d638301960e48d863ca115c276842-- --------9ac74a0ec5295f78b5947e7333939603053aecebf35b3bb386e7f3c7129cdb08 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0Fgmh9DRAJkHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdjL4s4IOchTaRnUm7oH2pT6EWUxnoTpi4pg+17 1iblhRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAANWgD+OPLg16cbCibGPHKp PhuLOXGffeJoo/JrTKHIMRtVChQA/R3pJiQ7d+pL4FxvqtKbKmEhFLXspVIw vNU7plXFLLEG =Eksv -----END PGP SIGNATURE----- --------9ac74a0ec5295f78b5947e7333939603053aecebf35b3bb386e7f3c7129cdb08--