From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 17 Mar 2026 11:00:57 -0700 Received: from mail-oo1-f56.google.com ([209.85.161.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 1w2Yiu-0003uW-C6 for bitcoindev@gnusha.org; Tue, 17 Mar 2026 11:00:57 -0700 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-67ba8eabf6dsf69517909eaf.1 for ; Tue, 17 Mar 2026 11:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1773770450; x=1774375250; 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=1go7Kaq2sXZRSrQH0pPW+xhHUko8b2IlNGeUwKfDMeI=; b=xE0WJFcvraOQm67xlKZYtUX8zSpevMWgDOnoVijfRZK9hGnimgItFkvZo/xodSMp87 Bkrm5OYPVgclADyxIEwi5ySnmC2sn8yFfdm+L0RnE5OMO2xvtITv5D2sIdDPbhNuKrsE ceP58S9RQNRq+aKF2Q7/2N4WOjaNLKxkgR8Ro5Vxrg+0iHCB8SS3hoYARmNGu4BsHhb3 pMyLp8RsxgKR1qLKpqbdi5iAGynAqHv7naGiL1uNmXN4NQj0pPtea/sFnlHVghvbfHV+ U4vI3ckaSPSGpmEwT+H+GLuOxBtcZzScuUNDcJtGGDFyvpq0/4QHcMPAA9RNK5Nd5Yrp pTNQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773770450; x=1774375250; 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=1go7Kaq2sXZRSrQH0pPW+xhHUko8b2IlNGeUwKfDMeI=; b=HLbdX4aU7UpOfVYH7aUj5OTTU5iU93yE8m41uwoRHkBkLxeHO22X4p+Yx2WehR1m3x QDxJ2InV1sFy16T06hFXdSzV8KxBy6C1DcOgExWcrfsnuq/EdD+Zmb44i1ij8ko0d7DS UnJAMJ1Rtzl21SqxGsdft+6KG97zzAvqTWYjeXiyTV+JBlMBWfu8nkDQYHWzHYciara8 5yIu7JwHg4QoEt6UmagI/1ujZYsOgtyVJcAokmDPHoluADNHl97cRqnpiz06+c9ye22j ExEl8tdfhwNq7MB/KKqvUVrHRTbWc63acQh+zYDOXk6RD18y2I9bXTmw9btLUhkqla4M 1bvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773770450; x=1774375250; 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=1go7Kaq2sXZRSrQH0pPW+xhHUko8b2IlNGeUwKfDMeI=; b=STjCD2xcO6wY+HtzUuS2ZZnSKoKUR+J1X4SZ0lx4/77t297sQBA+OGOiaUv4p32ryv w5Tm1u4qqaL1DhZ50SmMht/fhVCpZtXNL1SrNqw24HtIRt+1hbh4wjSvD1cwqiyevIwj SmqcOzNFrbGzqkrZgciOSGqsAWFBNIfjF/eFypKXd1Ot0/zjgZQsW9rBm+HkuA3QvxQv FgqZbppMCa+K7WrvQYz3VMmLagWQ17GYoC2C5pnBPyaWPcrRsfwfGGP9x5EkjwpNSAqS kD17aNjVBIMsulFSxBD+Fru7jxusfKUg2WKRIaniHspk9Ij7T663EwMvN4hARmgMcs+w dqOw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUJk3CZj8DfeCwsz2g/kYNdhc3HA7SyRSF5le8fWpZnKWFZops81Pe6Nh6Kf4p55Zc9YcjpL8RTH23j@gnusha.org X-Gm-Message-State: AOJu0YwZH13dJ2tu61OeIN2SA4QR9FLEs+9/ZBrCwiyICwiZ0FQaTETK KuG27ewTMZE7leiY6m65ivm98boRjb71IJLkoE3iDsJpWoLTF2YP654P X-Received: by 2002:a05:6820:1f07:b0:67b:a712:f4da with SMTP id 006d021491bc7-67c0daf4150mr142794eaf.34.1773770449897; Tue, 17 Mar 2026 11:00:49 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+EC5sw1+Phv9eaDw76+VL/9eAX2Vq8cWtd0KwNCG/3dAQ==" Received: by 2002:a05:6820:618:b0:67a:6db:233f with SMTP id 006d021491bc7-67c0d6c7a25ls49659eaf.1.-pod-prod-00-us; Tue, 17 Mar 2026 11:00:44 -0700 (PDT) X-Received: by 2002:a05:6808:1a17:b0:44d:9f05:7159 with SMTP id 5614622812f47-467a80c0652mr2506786b6e.29.1773770444841; Tue, 17 Mar 2026 11:00:44 -0700 (PDT) Received: by 2002:a05:690c:6902:b0:79a:6bb7:eb3 with SMTP id 00721157ae682-79a6bb7102bms7b3; Tue, 17 Mar 2026 11:00:07 -0700 (PDT) X-Received: by 2002:a05:690c:6e81:b0:794:f400:2bfb with SMTP id 00721157ae682-79a70c486f1mr5635497b3.26.1773770406353; Tue, 17 Mar 2026 11:00:06 -0700 (PDT) Date: Tue, 17 Mar 2026 11:00:05 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <171b3d0e-e694-4ebc-9eeb-bb1917a9da69n@googlegroups.com> In-Reply-To: <967d68e7-ba38-4e28-bc36-bf256a8c85a9n@googlegroups.com> References: <3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en@googlegroups.com> <4df4b49e-f8f8-4d6f-b98f-7a4a27902800n@googlegroups.com> <967d68e7-ba38-4e28-bc36-bf256a8c85a9n@googlegroups.com> Subject: Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1718_1152390008.1773770405892" X-Original-Sender: ekaggata@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_1718_1152390008.1773770405892 Content-Type: multipart/alternative; boundary="----=_Part_1719_1526176020.1773770405892" ------=_Part_1719_1526176020.1773770405892 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi sashabeton, > Honestly, this idea might have had better timing a few years ago. No I don't think so; it was discussed at the time (specifically, pubkey=20 recovery). I remember bringing it up in the taproot review sessions on IRC.= =20 I'm sure others, including the taproot designers, discussed this issue well= =20 before I thought about it :) Perhaps this clarifies it for other mailing list readers: BIP340 Schnorr signatures are the form of Schnorr signature which has what= =20 is commonly termed "pubkey prefixing"; the challenge hash is e =3D H(R, P, = m)=20 with P the public key. This makes a pubkey recovery algorithm of the type= =20 that we have in our legacy ECDSA signatures, impossible. It's a point of=20 not-only-historical interest that the original Schnorr signature design was= =20 H(R, m) not H(R, P, m) and that even around the time when ECDSA was being= =20 designed to avoid the Schnorr patent, and later, it was a point of=20 considerable contention amongst various system designers, whether pubkey=20 prefixing was needed or not. Pubkey prefixing makes all of the security reductions much more meaningful,= =20 since it can make the concept of "resistant to forgery" much more=20 wide-ranging and powerful (in short, imagine the idea that you can make up= =20 a schnorr signature for some arbitrary key that wasn't used before .. this= =20 is sorta kinda true for non-pubkey-prefixed Schnorr). And that has big=20 implications for perhaps the biggest application of Schnorr in Bitcoin,=20 which is aggregation; aggregation in a bitcoin context means *aggregating= =20 arbitrary, new, ephemeral keys*, not keys previously recorded in some=20 certificate registry or whatever. You're not going to get sensible versions= =20 of MuSig without pubkey prefixing, because you couldn't stop adversaries=20 making up malicious keys that they don't have to commit to. Without that kind of aggregation scheme (and see e.g. DahLIAS and CISA, if= =20 you don't actually care about multisig for whatever reason; it could end up= =20 being very important for Bitcoin scaling anyway), Schnorr is a lot less of= =20 an upgrade to our signing algorithm (though to be fair, still not nothing,= =20 it's on sounder theoretical foundations). Cheers, AdamISZ/waxwing On Tuesday, March 17, 2026 at 6:32:12=E2=80=AFAM UTC-3 sashabeton wrote: > Hi everyone, > > After reading all the feedback, I think it's time to accept that this=20 > proposal has no realistic path forward. > > For it to make sense, the new address type would need to be adopted by th= e=20 > entire ecosystem almost instantly =E2=80=94 which is simply not going to = happen. > > Honestly, this idea might have had better timing a few years ago. Today,= =20 > the landscape has moved on, and I don't think pushing this further would = be=20 > a good use of anyone's time. > > I want to thank everyone who took the time to read, review, and respond. > > On Tuesday, 17 March 2026 at 08:32:06 UTC+1 Saint Wenhao wrote: > >> > The goal is giving users who are already happy with the P2WPKH model= =20 >> (no script spending, simple single-key payments) the witness efficiency = of=20 >> Schnorr >> >> If you have a DER signature, then it can take from 9 to 73 bytes. In=20 >> Schnorr signatures, it is set to 64 or 65 bytes. >> >> In practice, you can have 71 bytes without grinding, which means, that b= y=20 >> using a CPU to grind r-value and s-value, to shrink it by 4 bytes each, = you=20 >> will get 63 bytes in a DER signature. And that won't reveal your private= =20 >> key to anyone else. It would require around 2^33 operations, so it is=20 >> doable on CPUs. >> >> Which means, that if you want to have smaller signatures, and you are=20 >> willing to put some Proof of Work into that, then you will get better=20 >> results by just staying with P2WPKH. And, as leading zeroes are not push= ed=20 >> in DER signatures, because of BIP-66, and as computing power is getting= =20 >> better and better, your signatures could be smaller in the future, while= in=20 >> Schnorr signatures, you won't have any way to go below 64 bytes. >> >> pon., 16 mar 2026 o 17:12 sashabeton napisa=C5=82= (a): >> >>> To clarify the design intent: P2SKH is not a stripped-down Taproot =E2= =80=94 it=20 >>> is P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compact=20 >>> 20-byte hash commitment, no script path, single-key payments), and the = only=20 >>> change is replacing ECDSA with the same Schnorr signature scheme Taproo= t's=20 >>> key-path uses. That's it. >>> >>> The goal is giving users who are already happy with the P2WPKH model (n= o=20 >>> script spending, simple single-key payments) the witness efficiency of= =20 >>> Schnorr without forcing them onto a 34-byte output type designed for a= =20 >>> richer feature set they don't need. >>> >>> P2SKH is not quantum-resistant =E2=80=94 I fully acknowledge this. Like= P2WPKH,=20 >>> it relies on secp256k1 and will need to be migrated once post-quantum= =20 >>> schemes are deployed in Bitcoin. But until that happens, it serves the = same=20 >>> users as P2WPKH today, just more efficiently. When the time comes, user= s=20 >>> migrate =E2=80=94 the same way P2PKH and P2WPKH users will have to. >>> >>> On Monday, 16 March 2026 at 16:45:32 UTC+1 Alex wrote: >>> >>>> > In that use case P2TR key-path spending offers no scriptability=20 >>>> either =E2=80=94 this is not a new trade-off, it is the same one Tapro= ot already=20 >>>> made. >>>> >>>> This is not true. Taproot has 2 modes; its key-spend path is 12 bytes= =20 >>>> more bloated than your solution, yes. but Taproot can "dynamically" ch= ose=20 >>>> whether to use the key-spend path or the script-spend path. Your solut= ion=20 >>>> fully removes the script spend path, so you're not really optimizing a= n=20 >>>> equally capable solution, you're optimizing for only 1 part of it. >>>> >>>> Removing scriptability for 12 bytes could possibly be warranted in som= e=20 >>>> specific cases (I'm sure there are cases), but it's not a fair compari= son=20 >>>> against Taproot or BIP360. And since we will need quantum upgrade at s= ome=20 >>>> point, this upgrade is kind of (in my personal interpretation) doublin= g=20 >>>> down to the part that will eventually break. >>>> >>>> Do you have any plan on how one could quantum secure the funds in P2SK= H? >>>> m=C3=A5ndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex: >>>> >>>>> You are saving 12 bytes by removing all the scriptability, OP-code=20 >>>>> upgradeability and basically locking yourself to a non-quantum-secure= key=20 >>>>> spend path that is only quantum secure if never spent? Or did I=20 >>>>> missunderstand? >>>>> >>>>> m=C3=A5ndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habov=C5=A1t= iak: >>>>> >>>>>> Taproot specifically did not do this for good reasons that are well= =20 >>>>>> documented. I recommend you to read documentation first before attem= pting=20 >>>>>> to make changes. >>>>>> >>>>>> D=C5=88a po 16. 3. 2026, 11:48 sashabeton =20 >>>>>> nap=C3=ADsal(a): >>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> I'd like to propose a new native SegWit output type: Pay to Schnorr= =20 >>>>>>> Key Hash (P2SKH). >>>>>>> >>>>>>> =3D=3D The problem =3D=3D >>>>>>> >>>>>>> The two most relevant output types today each solve half the proble= m: >>>>>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and put= s=20 >>>>>>> the full 33-byte compressed public key in the witness (~108 witness= bytes=20 >>>>>>> per input). >>>>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the=20 >>>>>>> full 32-byte x-only public key directly in the scriptPubKey, making= outputs=20 >>>>>>> 12 bytes larger than P2WPKH and exposing the key in every unspent o= utput. >>>>>>> >>>>>>> Neither type achieves both a compact output and a compact witness= =20 >>>>>>> simultaneously. >>>>>>> >>>>>>> =3D=3D The proposal =3D=3D >>>>>>> >>>>>>> P2SKH uses OP_2 as the scriptPubKey (22 bytes, same= =20 >>>>>>> as P2WPKH). Spending requires a single 64-byte Schnorr signature.= =20 >>>>>>> Verification works by key recovery: given the signature (R, s) and = the=20 >>>>>>> challenge e =3D TaggedHash("P2SKH/challenge", R.x || hash160(P.x) |= | msg),=20 >>>>>>> the verifier recovers P =3D e^-1 * (s*G - R) and checks that hash16= 0(P.x)=20 >>>>>>> matches the program. The sighash reuses the BIP341 transaction dige= st, so=20 >>>>>>> cross-version replay is prevented by the scriptPubKey commitment. >>>>>>> >>>>>>> The result is the smallest combined footprint of any current=20 >>>>>>> single-key output type =E2=80=94 a 22-byte output with a 64-byte wi= tness =E2=80=94 while=20 >>>>>>> keeping the public key off-chain until spending. >>>>>>> >>>>>>> =3D=3D Tradeoffs =3D=3D >>>>>>> >>>>>>> The key-recovery step costs roughly one extra field inversion and= =20 >>>>>>> scalar multiplication compared to direct Schnorr verification. This= is the=20 >>>>>>> price of the 12-byte output size reduction. >>>>>>> >>>>>>> =3D=3D Open questions =3D=3D >>>>>>> >>>>>>> 1. BIP360 also claims witness version 2. If both proposals advance,= =20 >>>>>>> one needs to move. Version 3 seems like a natural alternative for P= 2SKH. >>>>>>> 2. Naming =E2=80=94 "P2SKH" follows the established pattern but "P2= TRKH" has=20 >>>>>>> been suggested to emphasise Schnorr/taproot lineage. Opinions welco= me. >>>>>>> >>>>>>> Full draft:=20 >>>>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7= 218620be580dc/p2skh.md >>>>>>> PoC implementation: https://github.com/bitcoin/bitcoin/pull/34826 >>>>>>> >>>>>>> Thanks in advance for any feedback. >>>>>>> >>>>>>> --=20 >>>>>>> You received this message because you are subscribed to the Google= =20 >>>>>>> Groups "Bitcoin Development Mailing List" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it,= =20 >>>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>>> To view this discussion visit=20 >>>>>>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6= c-2ddfe68ec73en%40googlegroups.com=20 >>>>>>> >>>>>>> . >>>>>>> >>>>>> --=20 >>> You received this message because you are subscribed to the Google=20 >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an email to bitcoindev+...@googlegroups.com. >>> >> To view this discussion visit=20 >>> https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-48= 9a77012038n%40googlegroups.com=20 >>> >>> . >>> >> --=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/= 171b3d0e-e694-4ebc-9eeb-bb1917a9da69n%40googlegroups.com. ------=_Part_1719_1526176020.1773770405892 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi sashabeton,

> Honestly, this idea mig= ht have had better timing a few years ago.

No I = don't think so; it was discussed at the time (specifically, pubkey recovery= ). I remember bringing it up in the taproot review sessions on IRC. I'm sur= e others, including the taproot designers, discussed this issue well before= I thought about it :)

Perhaps this clarifies it= for other mailing list readers:

BIP340 Schnorr = signatures are the form of Schnorr signature which has what is commonly ter= med "pubkey prefixing"; the challenge hash is e =3D H(R, P, m) with P the p= ublic key. This makes a pubkey recovery algorithm of the type that we have = in our legacy ECDSA signatures, impossible. It's a point of not-only-histor= ical interest that the original Schnorr signature design was H(R, m) not H(= R, P, m) and that even around the time when ECDSA was being designed to avo= id the Schnorr patent, and later, it was a point of considerable contention= amongst various system designers, whether pubkey prefixing was needed or n= ot.

Pubkey prefixing makes all of the security r= eductions much more meaningful, since it can make the concept of "resistant= to forgery" much more wide-ranging and powerful (in short, imagine the ide= a that you can make up a schnorr signature for some arbitrary key that wasn= 't used before .. this is sorta kinda true for non-pubkey-prefixed Schnorr)= . And that has big implications for perhaps the biggest application of Schn= orr in Bitcoin, which is aggregation; aggregation in a bitcoin context mean= s *aggregating arbitrary, new, ephemeral keys*, not keys previously recorde= d in some certificate registry or whatever. You're not going to get sensibl= e versions of MuSig without pubkey prefixing, because you couldn't stop adv= ersaries making up malicious keys that they don't have to commit to.
<= div>
Without that kind of aggregation scheme (and see e.g. = DahLIAS and CISA, if you don't actually care about multisig for whatever re= ason; it could end up being very important for Bitcoin scaling anyway), Sch= norr is a lot less of an upgrade to our signing algorithm (though to be fai= r, still not nothing, it's on sounder theoretical foundations).
<= br />
Cheers,
AdamISZ/waxwing

On Tuesday, = March 17, 2026 at 6:32:12=E2=80=AFAM UTC-3 sashabeton wrote:
Hi everyone,

After r= eading all the feedback, I think it's time to accept that this proposal= has no realistic path forward.

For it to make sense, the new addres= s type would need to be adopted by the entire ecosystem almost instantly = =E2=80=94 which is simply not going to happen.

Honestly, this idea m= ight have had better timing a few years ago. Today, the landscape has moved= on, and I don't think pushing this further would be a good use of anyo= ne's time.

I want to thank everyone who took the time to read, r= eview, and respond.

On Tuesday, 17 March 2026 at 08:32:06 UTC+1 Saint Wenhao = wrote:
> The goal is giving users who are already happy with the P2WPKH model= (no script spending, simple single-key payments) the witness efficiency of= Schnorr

If you have a DER signature, then it= can take from 9 to 73 bytes. In Schnorr signatures, it is set to 64 or 65 = bytes.

In practice, you can have 71 bytes without grinding, which me= ans, that by using a CPU to grind r-value and s-value, to shrink it by 4 by= tes each, you will get 63 bytes in a DER signature. And that won't reve= al your private key to anyone else. It would require around 2^33 operations= , so it is doable on CPUs.

Which means, that if you want to have sma= ller signatures, and you are willing to put some Proof of Work into that, t= hen you will get better results by just staying with P2WPKH. And, as leadin= g zeroes are not pushed in DER signatures, because of BIP-66, and as comput= ing power is getting better and better, your signatures could be smaller in= the future, while in Schnorr signatures, you won't have any way to go = below 64 bytes.

pon., 16 mar 2026 o 17:12= =C2=A0sashabeton <sashabe...@gmail.com> napis= a=C5=82(a):
To clarify the design intent: P2SKH is not a s= tripped-down Taproot =E2=80=94 it is P2WPKH upgraded to Schnorr. The starti= ng point is P2WPKH (compact 20-byte hash commitment, no script path, single= -key payments), and the only change is replacing ECDSA with the same Schnor= r signature scheme Taproot's key-path uses. That's it.

The g= oal is giving users who are already happy with the P2WPKH model (no script = spending, simple single-key payments) the witness efficiency of Schnorr wit= hout forcing them onto a 34-byte output type designed for a richer feature = set they don't need.

P2SKH is not quantum-resistant =E2=80=94 I = fully acknowledge this. Like P2WPKH, it relies on secp256k1 and will need t= o be migrated once post-quantum schemes are deployed in Bitcoin. But until = that happens, it serves the same users as P2WPKH today, just more efficient= ly. When the time comes, users migrate =E2=80=94 the same way P2PKH and P2W= PKH users will have to.

On Monday, 16 March 2026 at 16:45:32 UTC+1 Alex wrote= :
>=C2=A0 In that use case P2TR key-path spending offers no scriptabi= lity either =E2=80=94 this is not a new trade-off, it is the same one Tapro= ot already made.

This is not true. Taproot has 2 modes; its k= ey-spend path is 12 bytes more bloated than your solution, yes. but Taproot= can "dynamically" chose whether to use the key-spend path or the= script-spend path. Your solution fully removes the script spend path, so y= ou're not really optimizing an equally capable solution, you're opt= imizing for only 1 part of it.

Removing scriptability fo= r 12 bytes could possibly be warranted in some specific cases (I'm sure= there are cases), but it's not a fair comparison against Taproot or BI= P360. And since we will need quantum upgrade at some point, this upgrade is= kind of (in my personal interpretation) doubling down to the part that wil= l eventually break.

Do you have any plan on how one could quantum se= cure the funds in P2SKH?
m=C3=A5ndag 16 mars 2026 kl. 12:57:52 UTC+1 skrev Alex= :
You are saving= 12 bytes by removing all the scriptability, OP-code upgradeability and bas= ically locking yourself to a non-quantum-secure key spend path that is only= quantum secure if never spent? Or did I missunderstand?

m=C3=A5ndag 16 mars= 2026 kl. 12:25:57 UTC+1 skrev Martin Habov=C5=A1tiak:
Taproot specifical= ly did not do this for good reasons that are well documented. I recommend y= ou to read documentation first before attempting to make changes.

=
D=C5=88a p= o 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.co= m> nap=C3=ADsal(a):
Hi everyone,

I'd like to propos= e a new native SegWit output type: Pay to Schnorr Key Hash (P2SKH).

= =3D=3D The problem =3D=3D

The two most relevant output types today e= ach solve half the problem:
- P2WPKH has a compact 22-byte scriptPubKey,= but uses ECDSA and puts the full 33-byte compressed public key in the witn= ess (~108 witness bytes per input).
- P2TR uses Schnorr signatures (64-b= yte witness), but embeds the full 32-byte x-only public key directly in the= scriptPubKey, making outputs 12 bytes larger than P2WPKH and exposing the = key in every unspent output.

Neither type achieves both a compact ou= tput and a compact witness simultaneously.

=3D=3D The proposal =3D= =3D

P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 byt= es, same as P2WPKH). Spending requires a single 64-byte Schnorr signature. = Verification works by key recovery: given the signature (R, s) and the chal= lenge e =3D TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || = msg), the verifier recovers P =3D e^-1 * (s*G - R) and checks that hash160(= P.x) matches the program. The sighash reuses the BIP341 transaction digest,= so cross-version replay is prevented by the scriptPubKey commitment.
The result is the smallest combined footprint of any current single-key o= utput type =E2=80=94 a 22-byte output with a 64-byte witness =E2=80=94 whil= e keeping the public key off-chain until spending.

=3D=3D Tradeoffs = =3D=3D

The key-recovery step costs roughly one extra field inversion= and scalar multiplication compared to direct Schnorr verification. This is= the price of the 12-byte output size reduction.

=3D=3D Open questio= ns =3D=3D

1. BIP360 also claims witness version 2. If both proposals= advance, one needs to move. Version 3 seems like a natural alternative for= P2SKH.
2. Naming =E2=80=94 "P2SKH" follows the established pa= ttern but "P2TRKH" has been suggested to emphasise Schnorr/taproo= t lineage. Opinions welcome.

Full draft: https://git= hub.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh= .md
PoC implementation: https://github.com/bitcoin/bitcoin/pull/3= 4826

Thanks in advance for any feedback.

--
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 bitcoindev+...@googlegroups.com.=
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-= 2ddfe68ec73en%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 bitcoindev+...@googlegroups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a7701203= 8n%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/bitcoind= ev/171b3d0e-e694-4ebc-9eeb-bb1917a9da69n%40googlegroups.com.
------=_Part_1719_1526176020.1773770405892-- ------=_Part_1718_1152390008.1773770405892--