From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 17 Mar 2026 12:01:39 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w2Zfd-0004ga-P1 for bitcoindev@gnusha.org; Tue, 17 Mar 2026 12:01:39 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-417371eeb0bsf24894754fac.2 for ; Tue, 17 Mar 2026 12:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1773774091; x=1774378891; 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=hmpTwEKn9qzeWrsJIPNXEQ1xrYz1Q69kyhp5etYhQ58=; b=IioKQ5TkR5eAa7H1ux0dfVhFurdczDHZydKKFc/7FCsGVgMOr0VuqLIHMpO3dFeoTV jRrV+fJ0l+z2Cf9WeioiPOkcKzX7GhPIy5z4emt3ZZj9awhxRANiB6UWZtLvRI+Rv834 n72Mrvv483KYhY22I/NeMWyQAfi3ck4Un+H9U2yeLJ6wtueEYYcia4DB+HHo4zs7qjFf P+0L3rtVabc9lduxILytRlbH4VzPfOWdlDTWI2cGvCHPe2H/mQWzFLzM4I3tksmkepkx UussOsll80ERMlhZsWcy61HXPYRYv161/sL5+gJ7nyrQn8Byg1dGJpj/Eq8pviDQU+Xn 1hAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773774091; x=1774378891; 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=hmpTwEKn9qzeWrsJIPNXEQ1xrYz1Q69kyhp5etYhQ58=; b=gjjZ7tQi/gz6f6pWsK/gE6quKQSNkZU8qxkbFl3XqQ0YPf6qeisbNqzkuQvK/xdkZE rDeBynSFVscONlx4JBQnaN/0HpzCA/srkRkmisuyMKuWhRermDiakP0GgXN2HGZ+nvmK 4Sg9TTQ68tDd/d5bjI7t/jZrvl7LQSprB/MOkTpd2qv7QfbIGo1kz8umjTu2Kuwmvle1 +fVWyXPY8eW6/68nLr4u3XisunecLWDzBk4RQnrJFpSL+xkZEAdSMAXMqzNwVy+oHf3q 04HBub/xnLGvGq7VXEFYNh8QCqPc1IW3JTdkIo72lQCtF94vbKOfStoC082vUvQeY5/H UecQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773774091; x=1774378891; 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=hmpTwEKn9qzeWrsJIPNXEQ1xrYz1Q69kyhp5etYhQ58=; b=aW0O/bq4081+ZFD4Cl8rLQUjkT7aGflzSNY9ikaKZR8Z/qj9tPIA289BbGFbc1zxei QzcqiNpXdt0Wvp13zlNE0BbcswThDzgyWFWxM3Cb4mAe0yE8jqgu2XvF6YqDfHQ9W1TL pvqPD5acqKPtKCcMJh8ub4n2b0QT0WsWj7moc2Kwh1a2s8XWHb5yv+DRglB97b6lgmKu eOGIZxBwnUEULfaeD2/iXL88xiuwjaQYBwAnGGwC9hLKunZtUk+t18QCtNEO/h1pJv7e +soclOxiuNUcuCc5YIw5gS1zeBBdefuVz5Syk2cHFROyIPBMIEkVKWer8ruG8qrusVB3 slSA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUj0Uj+/REVssUmfhaHsx/2rSpGJcSi8EJZB3XWYY8ykh3BpaQ609fgfzCx69vIEfa3/gsfqW0Vwf27@gnusha.org X-Gm-Message-State: AOJu0YxCl1pKBpJCgQ04S4jK5dBaXDtDmLZ6L3QVOa/6LGr7GTlxKgho KTRD9JxC5yuJ410UMMAf7Z0NBqqrFWS5O6GgcKLklMyE71ril5dBuoR9 X-Received: by 2002:a05:6870:831e:b0:3ec:3189:9671 with SMTP id 586e51a60fabf-41bd4140544mr342813fac.23.1773774091049; Tue, 17 Mar 2026 12:01:31 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HwuYio8rElVZriU1bcmdbjLx7OPXQIVNeGb6yutS4WTA==" Received: by 2002:a05:6870:fba0:b0:417:821f:fca0 with SMTP id 586e51a60fabf-417b4f9b7d0ls3464357fac.0.-pod-prod-09-us; Tue, 17 Mar 2026 12:01:25 -0700 (PDT) X-Received: by 2002:a05:6808:1813:b0:467:1212:46fd with SMTP id 5614622812f47-467ba2442d7mr371474b6e.33.1773774085469; Tue, 17 Mar 2026 12:01:25 -0700 (PDT) Received: by 2002:a05:690c:a0aa:20b0:79a:37dc:255a with SMTP id 00721157ae682-79a72da5a3ems7b3; Tue, 17 Mar 2026 11:30:52 -0700 (PDT) X-Received: by 2002:a05:690c:398:b0:79a:7126:b0d7 with SMTP id 00721157ae682-79a71dc1f5amr3909487b3.61.1773772251473; Tue, 17 Mar 2026 11:30:51 -0700 (PDT) Date: Tue, 17 Mar 2026 11:30:50 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <171b3d0e-e694-4ebc-9eeb-bb1917a9da69n@googlegroups.com> References: <3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en@googlegroups.com> <4df4b49e-f8f8-4d6f-b98f-7a4a27902800n@googlegroups.com> <967d68e7-ba38-4e28-bc36-bf256a8c85a9n@googlegroups.com> <171b3d0e-e694-4ebc-9eeb-bb1917a9da69n@googlegroups.com> Subject: Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2820_531437663.1773772250991" 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_2820_531437663.1773772250991 Content-Type: multipart/alternative; boundary="----=_Part_2821_2107316028.1773772250991" ------=_Part_2821_2107316028.1773772250991 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi sashabeton, Apologies - I didn't read your proposal carefully. You were of course in=20 fact pubkey-prefixing here (with the hash-160 of P), so my entire saga=20 about pubkey prefixing is not actually relevant! (maybe someone found it interesting tho' , lol). Cheers, AdamISZ/waxwing On Tuesday, March 17, 2026 at 3:00:50=E2=80=AFPM UTC-3 waxwing/ AdamISZ wro= te: > 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 IR= C.=20 > I'm sure others, including the taproot designers, discussed this issue we= ll=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 wha= t=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 w= as=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=20 > meaningful, since it can make the concept of "resistant to forgery" much= =20 > more wide-ranging and powerful (in short, imagine the idea that you can= =20 > make up a schnorr signature for some arbitrary key that wasn't used befor= e=20 > .. this is sorta kinda true for non-pubkey-prefixed Schnorr). And that ha= s=20 > big implications for perhaps the biggest application of Schnorr in Bitcoi= n,=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 versio= ns=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, i= f=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 o= f=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= =20 >> the entire ecosystem almost instantly =E2=80=94 which is simply not goin= g 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= =20 >>> by using a CPU to grind r-value and s-value, to shrink it by 4 bytes ea= ch,=20 >>> you will get 63 bytes in a DER signature. And that won't reveal your=20 >>> private key to anyone else. It would require around 2^33 operations, so= it=20 >>> is 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 pus= hed=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, whil= e 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 Tapro= ot's=20 >>>> key-path uses. That's it. >>>> >>>> The goal is giving users who are already happy with the P2WPKH model= =20 >>>> (no script spending, simple single-key payments) the witness efficienc= y 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. Lik= e 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, use= rs=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 Tapr= oot 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" c= hose=20 >>>>> whether to use the key-spend path or the script-spend path. Your solu= tion=20 >>>>> fully removes the script spend path, so you're not really optimizing = an=20 >>>>> equally capable solution, you're optimizing for only 1 part of it. >>>>> >>>>> Removing scriptability for 12 bytes could possibly be warranted in=20 >>>>> some specific cases (I'm sure there are cases), but it's not a fair= =20 >>>>> comparison against Taproot or BIP360. And since we will need quantum= =20 >>>>> upgrade at some point, this upgrade is kind of (in my personal=20 >>>>> interpretation) doubling down to the part that will eventually break. >>>>> >>>>> Do you have any plan on how one could quantum secure the funds in=20 >>>>> 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= =20 >>>>>> upgradeability and basically locking yourself to a non-quantum-secur= e 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=A1= tiak: >>>>>> >>>>>>> Taproot specifically did not do this for good reasons that are well= =20 >>>>>>> documented. I recommend you to read documentation first before atte= mpting=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 Schnor= r=20 >>>>>>>> Key Hash (P2SKH). >>>>>>>> >>>>>>>> =3D=3D The problem =3D=3D >>>>>>>> >>>>>>>> The two most relevant output types today each solve half the=20 >>>>>>>> problem: >>>>>>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and=20 >>>>>>>> puts the full 33-byte compressed public key in the witness (~108 w= itness=20 >>>>>>>> bytes per input). >>>>>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the= =20 >>>>>>>> full 32-byte x-only public key directly in the scriptPubKey, makin= g outputs=20 >>>>>>>> 12 bytes larger than P2WPKH and exposing the key in every unspent = output. >>>>>>>> >>>>>>>> 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 hash1= 60(P.x)=20 >>>>>>>> matches the program. The sighash reuses the BIP341 transaction dig= est, 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 w= itness =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. Thi= s 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 = P2SKH. >>>>>>>> 2. Naming =E2=80=94 "P2SKH" follows the established pattern but "P= 2TRKH"=20 >>>>>>>> has been suggested to emphasise Schnorr/taproot lineage. Opinions = welcome. >>>>>>>> >>>>>>>> Full draft:=20 >>>>>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e= 7218620be580dc/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-ad= 6c-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-4= 89a77012038n%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/= fc83173c-f4b3-4a2e-a662-dd6eecebb7ban%40googlegroups.com. ------=_Part_2821_2107316028.1773772250991 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi sashabeton,

Apologies - I didn't read yo= ur proposal carefully. You were of course in fact pubkey-prefixing here (wi= th the hash-160 of P), so my entire saga about pubkey prefixing is not actu= ally relevant!

(maybe someone found it interesti= ng tho' , lol).

Cheers,
AdamISZ/waxwin= g

On Tuesday, March 17, 2026 at 3:00:50=E2=80=AFPM UTC-3 waxwing/ AdamISZ= wrote:
= 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 recovery). I = remember bringing it up in the taproot review sessions on IRC. I'm sure= others, including the taproot designers, discussed this issue well before = I thought about it :)

Perhaps this clarifies it fo= r other mailing list readers:

BIP340 Schnorr signa= tures are the form of Schnorr signature which has what is commonly termed &= quot;pubkey prefixing"; the challenge hash is e =3D H(R, P, m) with P = the public 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-on= ly-historical 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 design= ed to avoid the Schnorr patent, and later, it was a point of considerable c= ontention amongst various system designers, whether pubkey prefixing was ne= eded or not.

Pubkey prefixing makes all of the sec= urity reductions much more meaningful, since it can make the concept of &qu= ot;resistant to forgery" much more wide-ranging and powerful (in short= , imagine the idea that you can make up a schnorr signature for some arbitr= ary key that wasn't used before .. this is sorta kinda true for non-pub= key-prefixed Schnorr). And that has big implications for perhaps the bigges= t application of Schnorr in Bitcoin, which is aggregation; aggregation in a= bitcoin context means *aggregating arbitrary, new, ephemeral keys*, not ke= ys previously recorded in some certificate registry or whatever. You're= not going to get sensible versions of MuSig without pubkey prefixing, beca= use you couldn't stop adversaries making up malicious keys that they do= n't have to commit to.

Without that kind of ag= gregation scheme (and see e.g. DahLIAS and CISA, if you don't actually = care about multisig for whatever reason; it could end up being very importa= nt for Bitcoin scaling anyway), Schnorr is a lot less of an upgrade to our = signing algorithm (though to be fair, still not nothing, it's on sounde= r theoretical foundations).

Cheers,
Adam= ISZ/waxwing

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

After reading 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 address type would need to be adopted by the entire eco= system almost instantly =E2=80=94 which is simply not going to happen.
<= br>Honestly, this idea might have had better timing a few years ago. Today,= the landscape has moved on, and I don't think pushing this further wou= ld be 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:3= 2:06 UTC+1 Saint Wenhao wrote:
> The goal is giving users who are already hap= py with the P2WPKH model (no script spending, simple single-key payments) t= he 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 wi= thout grinding, which means, that by using a CPU to grind r-value and s-val= ue, to shrink it by 4 bytes each, you will get 63 bytes in a DER signature.= And that won't reveal your private key to anyone else. It would requir= e around 2^33 operations, so it is doable on CPUs.

Which means, that= if you want to have smaller signatures, and you are willing to put some Pr= oof of Work into that, then you will get better results by just staying wit= h P2WPKH. And, as leading zeroes are not pushed in DER signatures, because = of BIP-66, and as computing power is getting better and better, your signat= ures could be smaller in the future, while in Schnorr signatures, you won&#= 39;t have any way to go below 64 bytes.

pon= ., 16 mar 2026 o 17:12=C2=A0sashabeton <sashabe...@g= mail.com> napisa=C5=82(a):
To clarify the design in= tent: P2SKH is not a stripped-down Taproot =E2=80=94 it is P2WPKH upgraded = to Schnorr. The starting point is P2WPKH (compact 20-byte hash commitment, = no script path, single-key payments), and the only change is replacing ECDS= A with the same Schnorr signature scheme Taproot's key-path uses. That&= #39;s it.

The goal is giving users who are already happy with the P2= WPKH model (no script spending, simple single-key payments) the witness eff= iciency of Schnorr without 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 sec= p256k1 and will need to be migrated once post-quantum schemes are deployed = in Bitcoin. But until that happens, it serves the same users as P2WPKH toda= y, just more efficiently. When the time comes, users 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:
>=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/fc83173c-f4b3-4a2e-a662-dd6eecebb7ban%40googlegroups.com.
------=_Part_2821_2107316028.1773772250991-- ------=_Part_2820_531437663.1773772250991--