From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 12 Feb 2026 10:41:41 -0800 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vqbdE-0001dn-AO for bitcoindev@gnusha.org; Thu, 12 Feb 2026 10:41:41 -0800 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-4081db82094sf1193307fac.0 for ; Thu, 12 Feb 2026 10:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1770921694; x=1771526494; 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=cE3ehr1gKu9b98BcI2Ti8cLnEolCCxdczfNxMqa7HhU=; b=mKtB0lx1uZbS6+sIB+t2Xsbfw7ktwQEZ7cVmiCqQM1V+P97s51EKPOYZ7n86B3Y5b7 yaXGJoNvRy1Z7cHKY/LwJ1G64/acrELzI2gM+3rDGn9TfOlJBPK7REdeSUIj9FdgA67W 6kF4Szb6OugfQ0m2H17MEF0ShvhNk0ltGlfZWrc0qYGe6NYWZc6PyiAfEDIQXYpUNEN1 wboR5iK2qd1n6zbhEgoxoZxK96rF3EgxV0FMgXPDoYT+jN6hufhvsS0b92nOxDVOU5ZQ /HRiQiDHYO3PmbXZseXW6jVy92JNX+y1k+j5eAham2/ujqzEtM7FTzRYyew0x7eazMe6 OYFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770921694; x=1771526494; 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=cE3ehr1gKu9b98BcI2Ti8cLnEolCCxdczfNxMqa7HhU=; b=iBM/WfLhST+GWFCzv8Nh4sMNzFOiTcEpMUyW8t63PVerbweyWJ7p3ZhWwqPSN7h4E1 pNsVoIVvjOZQZ0RySTeSMcGFfGNzj9I+Ityr7x6DqUqx4hurOvTML6beEiuqd7bA8/nC hS3lzRqQQzUrWZTNzXJgmX6I1XBWNNn0e7cYm8FQrzjvQYTAK2wwBOn7h8u/dtiUA164 c0F6JpjXVCGmOXa5F8DTj3j9xQ1m3XXhM8vfbeiLc73oLQqaMuiLKK6ftg0kDqLsUBb1 GTat+vrq1vme9E7DNqQNd7v8Pfkboo1MdQmJ2Tfg+TT64XouprUBc0ZvM8cbrCKdkZQo +Bwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770921694; x=1771526494; 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=cE3ehr1gKu9b98BcI2Ti8cLnEolCCxdczfNxMqa7HhU=; b=EhPN0oF0n3wPlpMjNOGEr7+LClScXUTlPi9hT3rBF8dnj5nkkA2bUDUIZdibS+CRIK XbfBaFm33CR7PfBla+ykw0K9w6rWA0PUVUf7qt93ATSNav5cUEgzvf0Ty/HMz9dHjmVM zeuR0xdiNuwyggGeEcbEPFE/+1RaWPZAI1LrhAXGhbzJj0DaChqcNpsWopoYj4sxBUCm rHjhsQLH3u4tuXOZwWjAWkWSQl7w28C3sHNptm1v9HSJmvc3J3Rg+eC6TFPDd1Er+LLC QuyALhTvu5d7jsRCtuvfmjIf1Krv3DOY/qBBc3XAbpZUcHJ2eVCqXQ3eJyQfygGsseLj whBA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVfuRHzCf7z7tf9wUswk0AfPHvvklfUn5suJaVYaB6tt5jxzxMCOgLsYDkK/7xCU2xzMnRDmTYoFLk2@gnusha.org X-Gm-Message-State: AOJu0YyOsdmHU32dZ0FyoWG7nXDP8EZIy//ek7VYYRL2bUm69rbdjefe TxTEiFNN8mAFlxNzRE15AylzousI1UWJY3jx4xKQwKSo1LL/YL5nkK/3 X-Received: by 2002:a05:6870:9627:b0:409:9571:34e7 with SMTP id 586e51a60fabf-40ec6ea1519mr2083036fac.4.1770921694000; Thu, 12 Feb 2026 10:41:34 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HYeoK//o93BJCJ2rjhr1rERzYC69b1QIKdsIiea2ZeQQ==" Received: by 2002:a05:6870:9720:b0:3ff:9f0a:cf52 with SMTP id 586e51a60fabf-40eca71841dls663801fac.2.-pod-prod-07-us; Thu, 12 Feb 2026 10:41:28 -0800 (PST) X-Received: by 2002:a05:6808:4f5f:b0:450:ccef:c01f with SMTP id 5614622812f47-4637fc72524mr1379368b6e.34.1770921688383; Thu, 12 Feb 2026 10:41:28 -0800 (PST) Received: by 2002:a05:690c:8a42:b0:794:c577:7579 with SMTP id 00721157ae682-79529dfde67ms7b3; Thu, 12 Feb 2026 07:13:58 -0800 (PST) X-Received: by 2002:a05:690c:d88:b0:794:897:9039 with SMTP id 00721157ae682-79793184bc1mr19883317b3.34.1770909237719; Thu, 12 Feb 2026 07:13:57 -0800 (PST) Date: Thu, 12 Feb 2026 07:13:57 -0800 (PST) From: Alex To: Bitcoin Development Mailing List Message-Id: <9d991f8a-6eaf-4701-9226-9a35abc89b35n@googlegroups.com> In-Reply-To: References: <22073a56-1cbf-4ba9-a2ea-46c621d4619c@mattcorallo.com> Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_56898_367707913.1770909237280" X-Original-Sender: alexhultman@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.5 (/) ------=_Part_56898_367707913.1770909237280 Content-Type: multipart/alternative; boundary="----=_Part_56899_1475978092.1770909237280" ------=_Part_56899_1475978092.1770909237280 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > A new address type that is 10x more expensive to transact with is going to see ~zero adoption in=20 "consumer wallets" until its urgent, at which point its obviously way, way too late. This is dishonest strawman argumentation that only misrepresents the=20 proposal incorrectly. Migrating to a BIP360 wallet does not mean you pay 10x in fees. That is a= =20 made up claim. The proposal clearly states you still continue to use cheap= =20 Schnorr signatures, cheaply as before, while having a backup SLH-DSA script= =20 spend (that you never actually use until Schnorr is fully broken, or never)= . You do not pay for scripts that you never use and you only pay the 10x fee= =20 if you want (which you will want when all other signatures are fully=20 broken). And having a migration ready & settled _before_ Q-day so you know= =20 for sure you can move your funds (at 10x the cost) even after Q-day is an= =20 enormous relief to everyone holding more than peanuts. This is a forwards compatible migration that has no extra cost until you=20 freely decide to pay for the extra security (which should be an obvious=20 decision if ever Schnorr gets entirely broken). SLH-DSA in inefficient but= =20 simple to implement. Having it as an OP-code means you can wait for more=20 efficient signatures to mature (like SQIsign) and then use SLH-DSA to=20 migrate to SQIsign. SLH-DSA would be a stepping stone, a guarantee that you can always move=20 your funds even after Q-day. It is clearly not meant to be your default=20 signature (which is explicitly stated in the post). torsdag 12 februari 2026 kl. 00:14:35 UTC+1 skrev Ethan Heilman: > > For what its worth I do not see a scenario where a decision ultimately= =20 > made by the market will pick the fork side with materially, say 5-10x=20 > higher, supply, over the side with lower supply... > > Completely agree, the incentives favor lower supply. I wouldn't want to= =20 > count on it happening and even if it does happen the freeze fork might no= t=20 > freeze P2TR. According to the 2025 chaincode report [0] P2TR represents= =20 > only 0.75% of total supply. > > > > ~all wallets today use seedphrases, which could still be spent with a= =20 > ZK proof-of-seedphrase :). > > I'm all for putting ZKPs in consensus, but it seems unlikely to me that i= t=20 > will happen. It is better to make Bitcoin safe than promise safety that= =20 > requires a future hardfork. This is especially true since as you point ou= t=20 > lower supply is incentivized, so a soft fork that freezes coins would be= =20 > fighting an uphill battle. > > > > Hell, *any* PQ soft fork is going to see limited adoption in=20 > "consumer wallets" until its urgent, hence why I think the community will= =20 > be basically forced to disable insecure spend paths and only > allow spends via ZK proof-of-seedphrase. But at least something that=20 > doesn't also 10x transaction costs might reasonably be adopted by default= =20 > by wallets that don't use seedphrases like Bitcoin Core. > > I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use=20 > quantum-safe outputs (Schnorr OR PQ) with Schnorr as the default spend. T= he=20 > wallets can market themselves as quantum safe. The cost in transaction fe= es=20 > to a user is small, a 1 input P2MR transaction would only be 37 bytes=20 > larger when compared with a 1 input P2TR transaction. Those 37 bytes are = in=20 > the witness, so the real cost is ~10 vbytes. > > Yes, if Q-day happens, time passes and then quantum computers become=20 > powerful enough to perform short-exposure attacks, anyone needing to move= =20 > their coins to an output have to pay fees for an additional 8,000 bytes= =20 > (SLH_DSA) or 324 bytes (SHRINCs). This is still better than a PQ ZKP proo= f=20 > of the seed which would be between 20,000 to 120,000 bytes and more likel= y=20 > to have a security flaw than SLH_DSA. > > If efficient quantum signatures or compression techniques are developed,= =20 > we can and should adopt them. If they are efficient enough, they can beco= me=20 > the default. This proposal is designed to keep funds safe in the=20 > intermediate period while better techniques are developed to cover the ta= il=20 > risk where Q-day happens before the technology we need to completely read= y. > > > > No it doesn't - it requires a soft fork when the risk is imminent, but= =20 > it happening somewhat before that time is okay too. > > We might wait too long and misjudge the risk and Q-day happens before the= =20 > soft fork activates? What happens if freeze fork is activated but then 3= =20 > years pass and it looks like a CRQC isn't going to happen after all? Now= =20 > people who had their coins frozen are pushing to undo the soft fork.=20 > > This approach carries too much risk from uncertainty and it was "the plan= "=20 > it signles that Bitcoin leaving things up to chance that don't have to b= e=20 > left to chance. > > Enabling people to opt in as early as possible enables the prudent to=20 > protect themselves for very little effort and cost. Those people know the= ir=20 > coins are safe and can still use their coin as they did before. > > > > I mean people can create invalid addresses today in plenty of ways. Ho= w=20 > is this unique? > > P2TRD would be an address, which looks exactly like a 100% valid address= =20 > and which can be spend from like a valid address and hwoever at some futu= re=20 > time, it may or may not, become frozen. > > [0]: https://chaincode.com/bitcoin-post-quantum.pdf > > On Wed, Feb 11, 2026 at 1:53=E2=80=AFPM Matt Corallo =20 > wrote: > >> >> >> On 2/10/26 11:44 AM, Ethan Heilman wrote: >> > > If Bitcoin disables Taproot key path spends before Q-day, then doin= g=20 >> this via Taproot instead of=20 >> > BIP 360 would be preferable. >> >=20 >> > I worry about making the transition to quantum-safe outputs depend on = a=20 >> contentious debate over a=20 >> > confiscatory soft fork. Uncertainty over whether the soft fork would b= e=20 >> released and if released=20 >> > would be activated means that wallets and custodians are unlikely to= =20 >> have invested the resources=20 >> > into upgrading to support script only P2TR. >> >> For what its worth I do not see a scenario where a decision ultimately= =20 >> made by the market will pick=20 >> the fork side with materially, say 5-10x higher, supply, over the side= =20 >> with lower supply...supply=20 >> and demand is king, especially with the "confiscatory" nature is=20 >> basically nil as ~all wallets today=20 >> use seedphrases, which could still be spent with a ZK proof-of-seedphras= e=20 >> :). >> >> > The benefit of BIP 360's P2MR (Pay-to-Merkle-Root) + SLH_DSA is that i= t=20 >> avoids this controversy by=20 >> > being opt-in and non-confiscatory. This also means that BIP 360 +=20 >> SLH_DSA is likely to activated=20 >> > early, allowing wallets and custodians ample time to build support=20 >> after activation. >> >> The drawback being that it will see zero relevant adoption until its way= =20 >> too late. >> >> The only entities that would reasonably adopt something like this are=20 >> large custodians, who aren't=20 >> worth worrying about as they'll easily migrate all their coins over the= =20 >> course of a few days or=20 >> weeks in an emergency scenario, and highly specialty wallets. The point= =20 >> of any PQ soft fork today is=20 >> if it can actually drive wallets to start making progress on PQ=20 >> deployment. A new address type that=20 >> is 10x more expensive to transact with is going to see ~zero adoption in= =20 >> "consumer wallets" until=20 >> its urgent, at which point its obviously way, way too late. >> >> Hell, *any* PQ soft fork is going to see limited adoption in "consumer= =20 >> wallets" until its urgent,=20 >> hence why I think the community will be basically forced to disable=20 >> insecure spend paths and only=20 >> allow spends via ZK proof-of-seedphrase. But at least something that=20 >> doesn't also 10x transaction=20 >> costs might reasonably be adopted by default by wallets that don't use= =20 >> seedphrases like Bitcoin Core. >> >> > > We could define a new SegWit version that is a copy of Taproot. The= =20 >> new version number simply=20 >> > signals that the owner consents to a future deactivation of key path= =20 >> spends. Unlike BIP 360, this >> > approach would still require actually disabling the key path before=20 >> Q-day, but it is not=20 >> > confiscatory and allows using Taproot's benefits until then (with=20 >> a privacy hit from having two=20 >> > versions of Taproot in parallel). >> >=20 >> > Let's call this P2TRD (Pay-to-Tap-Root-Disablable). BIP 360 evolved=20 >> from this P2TRD idea, to=20 >> > minimize the following hazards in P2TRD. >> >=20 >> > 1. P2TRD requires a soft fork that depends on accurately predicting= =20 >> Q-day or when EC Schnorr is=20 >> > classically broken. We must not only predict Q-day but also convince= =20 >> the community that the=20 >> > prediction is correct. If we mess up the timing, Bitcoin is=20 >> significantly harmed. This means that=20 >> > people will constantly be yelling that we are messing up the timing. I= t=20 >> will make quantum FUD worse=20 >> > not better. >> >> No it doesn't - it requires a soft fork when the risk is imminent, but i= t=20 >> happening somewhat before=20 >> that time is okay too. >> >> > 2. P2TRD (Pay-to-Tap-Root-Disablable) to be non-confiscatory users=20 >> must create a script spend that=20 >> > replicates their key spend, But users and wallets are likely to screw= =20 >> this up and not create script=20 >> > spends. The is no way to see if a wallet is actually creating the=20 >> script spend on the blockchain. >> >> I mean people can create invalid addresses today in plenty of ways. How= =20 >> is this unique? >> >> > 3. To be safe from long-exposure attacks P2TRD can't use the same=20 >> public key for the script spend as=20 >> > the key spend. Since wallets will prefer the key spend to the script= =20 >> spend, a user might not realize=20 >> > if they lost the keying material for their script spend until after=20 >> activation. >> >> It would almost certainly just be a key derived from the seedphrase via= =20 >> another hash function, so=20 >> there's no real risk of this. >> >> Matt >> > --=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/= 9d991f8a-6eaf-4701-9226-9a35abc89b35n%40googlegroups.com. ------=_Part_56899_1475978092.1770909237280 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >=C2=A0 A new address type that
is 10x more expensive to transact with is goin= g to see ~zero adoption in "consumer wallets" until
its urgent, at whi= ch point its obviously way, way too late.

This is dishonest stra= wman argumentation that only misrepresents the proposal incorrectly.
Migrating to a BIP360 wallet does not mean you pay 10x in fe= es. That is a made up claim. The proposal clearly states you still continue= to use cheap Schnorr signatures, cheaply as before, while having a backup = SLH-DSA script spend (that you never actually use until Schnorr is fully br= oken, or never).

You do not pay for scripts that= you never use and you only pay the 10x fee if you want (which you will wan= t when all other signatures are fully broken). And having a migration ready= & settled _before_ Q-day so you know for sure you can move your funds = (at 10x the cost) even after Q-day is an enormous relief to everyone holdin= g more than peanuts.

This is a forwards compatib= le migration that has no extra cost until you freely decide to pay for the = extra security (which should be an obvious decision if ever Schnorr gets en= tirely broken). SLH-DSA in inefficient but simple to implement. Having it a= s an OP-code means you can wait for more efficient signatures to mature (li= ke SQIsign) and then use SLH-DSA to migrate to SQIsign.

SLH-DSA would be a stepping stone, a guarantee that you can always = move your funds even after Q-day. It is clearly not meant to be your defaul= t signature (which is explicitly stated in the post).

torsdag 12 fe= bruari 2026 kl. 00:14:35 UTC+1 skrev Ethan Heilman:
>=C2=A0 For what its worth I do not see a scenario where a decision ultimately made= by the market will pick the fork side with materially, say 5-10x higher, s= upply, over the side with lower supply...

Com= pletely agree, the incentives favor lower supply. I wouldn't want to co= unt on it happening and even if it does happen the freeze fork might not fr= eeze P2TR. According to the 2025 chaincode report [0] P2TR represents only = 0.75% of total supply.


>=C2=A0 ~all wallets today use seedphrases, which could still be spent with a ZK pr= oof-of-seedphrase :).

I'm all for putting= ZKPs in consensus, but it seems unlikely to me that it will happen. It is = better to make Bitcoin safe than promise safety that requires a future hard= fork. This is especially true since as you point out lower supply is incent= ivized, so a soft fork that freezes coins would be fighting an uphill battl= e.


>=C2=A0=C2=A0 Hell, *any* PQ soft fork is going to see limited adoption in "consumer= wallets" until its urgent,=C2=A0hence why I think the community will = be basically forced to disable insecure spend paths and only
allow spend= s via ZK proof-of-seedphrase. But at least something that doesn't also = 10x transaction=C2=A0costs might reasonably be adopted by default by wallet= s that don't use seedphrases like Bitcoin Core.

I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets ca= n use quantum-safe outputs (Schnorr OR PQ) with Schnorr as the default spen= d. The wallets can market themselves as quantum safe. The cost in transacti= on fees to a user is small, a 1 input P2MR transaction would only be 37 byt= es larger when compared with a 1 input P2TR transaction. Those 37 bytes are= in the witness, so the real cost is ~10 vbytes.

Yes, if Q-day happe= ns, time passes and then quantum computers become powerful enough to perfor= m short-exposure attacks, anyone needing to move their coins to an output h= ave=C2=A0to pay fees for an additional 8,000 bytes (SLH_DSA) or=C2=A0324 by= tes (SHRINCs). This is still better than a PQ ZKP proof of the seed which w= ould be between 20,000 to 120,000 bytes and more likely to have a security = flaw than SLH_DSA.

If efficient quantum signatures or compression te= chniques are developed, we can and should adopt them. If they are efficient= enough, they can become the default. This proposal is designed to keep fun= ds safe in the intermediate period while better techniques are developed to= cover the tail risk where Q-day happens before the technology we need to c= ompletely ready.


>=C2=A0 No it doesn't - it requires a soft fork when the risk is imminent, but = it happening somewhat before that time is okay too.

We might wait too long and misjudge the risk and Q-day happens bef= ore the soft fork activates? What happens if freeze fork is activated but t= hen 3 years pass and it looks like a CRQC isn't going to happen after a= ll? Now people who had their coins frozen are pushing to undo the soft fork= .

This approach carries too much risk from uncertainty and it was &= quot;the plan" it signles that Bitcoin=C2=A0 leaving things up to chan= ce that don't have to be left to chance.

Enabling people to opt = in as early as possible enables the prudent to protect themselves for very = little effort and cost. Those people know their coins are safe and can stil= l use their coin as they did before.


>=C2= =A0 I mean people can create invalid addresses today in plenty of ways. How is = this unique?

P2TRD would be an address, which= looks exactly like a 100% valid address and which can be spend from like a= valid address and hwoever at some future time, it may or may not, become f= rozen.
On We= d, Feb 11, 2026 at 1:53=E2=80=AFPM Matt Corallo <lf-l...@mattcorallo.com> wrote:


On 2/10/26 11:44 AM, Ethan Heilman wrote:
>=C2=A0 > If Bitcoin disables Taproot key path spends before Q-day, t= hen doing this via=C2=A0Taproot instead of
> BIP 360 would be preferable.
>
> I worry about making the transition to quantum-safe outputs depend on = a contentious debate over a
> confiscatory soft fork. Uncertainty over whether the soft fork would b= e released and if released
> would be activated means that wallets and custodians are unlikely to h= ave invested the resources
> into upgrading to support script only P2TR.

For what its worth I do not see a scenario where a decision ultimately made= by the market will pick
the fork side with materially, say 5-10x higher, supply, over the side with= lower supply...supply
and demand is king, especially with the "confiscatory" nature is = basically nil as ~all wallets today
use seedphrases, which could still be spent with a ZK proof-of-seedphrase := ).

> The benefit of BIP 360's P2MR (Pay-to-Merkle-Root)=C2=A0+ SLH_DSA = is that it avoids this controversy by
> being opt-in and non-confiscatory. This also means that BIP 360 + SLH_= DSA is likely to activated
> early, allowing wallets and custodians ample time to build support aft= er activation.

The drawback being that it will see zero relevant adoption until its way to= o late.

The only entities that would reasonably adopt something like this are large= custodians, who aren't
worth worrying about as they'll easily migrate all their coins over the= course of a few days or
weeks in an emergency scenario, and highly specialty wallets. The point of = any PQ soft fork today is
if it can actually drive wallets to start making progress on PQ deployment.= A new address type that
is 10x more expensive to transact with is going to see ~zero adoption in &q= uot;consumer wallets" until
its urgent, at which point its obviously way, way too late.

Hell, *any* PQ soft fork is going to see limited adoption in "consumer= wallets" until its urgent,
hence why I think the community will be basically forced to disable insecur= e spend paths and only
allow spends via ZK proof-of-seedphrase. But at least something that doesn&= #39;t also 10x transaction
costs might reasonably be adopted by default by wallets that don't use = seedphrases like Bitcoin Core.

>=C2=A0 > We could define a new SegWit version that is a copy of Tapr= oot. The new version number simply
> signals that the owner=C2=A0consents to a future deactivation of key p= ath spends. Unlike BIP 360, this
> approach would still require actually disabling the key path before Q-= day, but=C2=A0it is not
> confiscatory and allows using Taproot's benefits until then (with = a=C2=A0privacy hit from having two
> versions of Taproot in parallel).
>
> Let's call this P2TRD (Pay-to-Tap-Root-Disablable). BIP 360 evolve= d from this P2TRD idea, to
> minimize the following hazards in P2TRD.
>
> 1.=C2=A0 P2TRD requires a=C2=A0soft fork that depends on accurately pr= edicting Q-day or when EC Schnorr is
> classically broken. We must not only predict Q-day but also convince t= he community that the
> prediction is correct. If we mess up the timing, Bitcoin is significan= tly harmed. This means that
> people will constantly be yelling that we are messing up the timing. I= t will make quantum FUD worse
> not better.

No it doesn't - it requires a soft fork when the risk is imminent, but = it happening somewhat before
that time is okay too.

> 2.=C2=A0 P2TRD (Pay-to-Tap-Root-Disablable) to be non-confiscatory use= rs must create a script spend that
> replicates their key spend, But users and wallets are likely to screw = this up and not create script
> spends. The is no way to see if a wallet is actually creating the scri= pt spend on the blockchain.

I mean people can create invalid addresses today in plenty of ways. How is = this unique?

> 3. To be safe from long-exposure attacks P2TRD can't use the same = public key for the script spend as
> the key spend. Since wallets will prefer the key spend to the script s= pend, a user might not realize
> if they lost the keying material for their script spend until after ac= tivation.

It would almost certainly just be a key derived from the seedphrase via ano= ther hash function, so
there's no real risk of this.

Matt

--
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/9d991f8a-6eaf-4701-9226-9a35abc89b35n%40googlegroups.com.
------=_Part_56899_1475978092.1770909237280-- ------=_Part_56898_367707913.1770909237280--