From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 17 Mar 2026 02:32:20 -0700 Received: from mail-ot1-f64.google.com ([209.85.210.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w2Qmh-0005u7-9B for bitcoindev@gnusha.org; Tue, 17 Mar 2026 02:32:20 -0700 Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-7d7510702e6sf52632746a34.3 for ; Tue, 17 Mar 2026 02:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1773739933; x=1774344733; 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=59zVuZa6jkiTHXop2yO92T7RZ8G5xN7PfqfTXFG3wFY=; b=wvueKbULcnESNdhLsg/k7Gr2GCefHuaBW0Jmd4b09AwXLNKOXJ/BrlHW+yhc6R5Ipj 0yD2lCPPwT/Hv7FrEP2OrT9rnVhoflYwS/9rSz/TGYt5QcntDD5neTzjCiyVNUAy9h6/ MzsWAcvRhvfypuvZjvazhzlVhXFXQSu7/VxFLt9VQI7iuLHMnYRYEFQw8xWxzC+GC/4R fc+gtP+h78ZX6PgWcAL49Y+PbiorRU2dVx+ZsvA4kz8kkOV+9uHZgbazuuekUdrMn92Y pmPxVf291NqvYGEHClMO7I1qxDbg+MkWcHYGonh3ho5iVPzOcXGx9sb5CWpEgx8S3On2 f0rg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773739933; x=1774344733; 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=59zVuZa6jkiTHXop2yO92T7RZ8G5xN7PfqfTXFG3wFY=; b=i2yGjaWHi1gy+KUNkQYPekRlzbCV1N+RHc/McuHWQx3WrDPZ6y5tz0qPogS33bRgVE Wo/DvOyQZ8Tb/dnjoH9DsaKrTx9C2AzxCNDdvCKCgQ0Q45cI9poWPRP/RM/3L4/9oyMI P3e3dsyIqbTO/EyzYxyeQO9pGfnlREUI12Wr3Z/uKXIcEcLtE0vtmwTD0NgxEIMXe7sI cjm+ySEzw2bn+pt3WE9loDEgjZCp5KRuDFMNMK8RMOhSnBldH3Sx0DdTbJeuIcBxFMOJ SZmNk0XpLffReF8DKZlNfHKmJgxa9zG30Oev+Xt0aLVPPIJTuFZgkvRTv13V8srRcdNl 7yFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773739933; x=1774344733; 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=59zVuZa6jkiTHXop2yO92T7RZ8G5xN7PfqfTXFG3wFY=; b=IfVhhlu3hOr+1To3gnneofXeDeYrUAyQOsAKp/VRO5HXDIAnKAkcEqBoOpP5XvEvcr FL4bAq7QlLZssTuDNvphYqtBPR0RyZEM9gMHh90sG9bCkr5IrQsdUjgKGUZhNiIqVx05 ba68HDWQBMAG3IQLV5cZC/H0apSh/nHOwnZJ4q+CaRu4uvXSedad8xjpOVBktFn9TyTF dFRa8xa91FRweYmpEzjOgD2veVofhXRkvFp2b1ZGxogXmuQXgoxjxl+Pp+pBmlcxC690 Cfidek6rm+GSJtAQSO9Fk/6KKCIIaBVpA00faKQDyqXMcdMrP8BhbpI/YQ0pr3hnxtHT mLuw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCU/PNZgIl+H3wdHE585IRCdqpsbQMpwtpm0oglyO56CUVNRjRn05Vpk0xTeozZywDxaA+BbJnYzcBYS@gnusha.org X-Gm-Message-State: AOJu0YwFDx/x8wYIRUrcVMbru9FayUqJYuaYW/G/XKDo7FH91rMS12E+ Yv8ULKyJcIDArBTyJJTGgQIJPA3OtlHzOaA5RC4D68YnjWiifJar+44B X-Received: by 2002:a05:6870:d154:b0:3e8:40e4:eb8d with SMTP id 586e51a60fabf-417b918e530mr9294236fac.16.1773739932593; Tue, 17 Mar 2026 02:32:12 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+GUDVcxFwT3nwtsAeHNgARosrQgfHyu69784/KOqHOFPQ==" Received: by 2002:a05:6870:a0a6:b0:3ec:406d:5582 with SMTP id 586e51a60fabf-417b556f264ls1816639fac.2.-pod-prod-04-us; Tue, 17 Mar 2026 02:32:06 -0700 (PDT) X-Received: by 2002:a05:6808:2218:b0:467:1e7f:c76f with SMTP id 5614622812f47-4675742afccmr9258506b6e.48.1773739926562; Tue, 17 Mar 2026 02:32:06 -0700 (PDT) Received: by 2002:a05:690c:a193:b0:794:2788:2ae4 with SMTP id 00721157ae682-79a1c07b7c5ms7b3; Tue, 17 Mar 2026 00:40:59 -0700 (PDT) X-Received: by 2002:a05:690c:f09:b0:796:6df5:485a with SMTP id 00721157ae682-79a1c187ce4mr161152997b3.39.1773733258494; Tue, 17 Mar 2026 00:40:58 -0700 (PDT) Date: Tue, 17 Mar 2026 00:40:58 -0700 (PDT) From: sashabeton To: Bitcoin Development Mailing List Message-Id: <967d68e7-ba38-4e28-bc36-bf256a8c85a9n@googlegroups.com> In-Reply-To: References: <3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en@googlegroups.com> <4df4b49e-f8f8-4d6f-b98f-7a4a27902800n@googlegroups.com> Subject: Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_64870_1020186924.1773733258101" X-Original-Sender: sashabeton2007@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_64870_1020186924.1773733258101 Content-Type: multipart/alternative; boundary="----=_Part_64871_460028237.1773733258101" ------=_Part_64871_460028237.1773733258101 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 the= =20 entire ecosystem almost instantly =E2=80=94 which is simply not going to ha= ppen. 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 (n= o=20 > 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 by= =20 > using a CPU to grind r-value and s-value, to shrink it by 4 bytes each, y= ou=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 pushe= d=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 o= nly=20 >> change is replacing ECDSA with the same Schnorr signature scheme Taproot= 's=20 >> key-path uses. That's it. >> >> The goal is giving users who are already happy with the P2WPKH model (no= =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 s= ame=20 >> users as P2WPKH today, just more efficiently. When the time comes, users= =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 Taproo= t 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" cho= se=20 >>> whether to use the key-spend path or the script-spend path. Your soluti= on=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 some= =20 >>> specific cases (I'm sure there are cases), but it's not a fair comparis= on=20 >>> against Taproot or BIP360. And since we will need quantum upgrade at so= me=20 >>> point, this upgrade is kind of (in my personal interpretation) doubling= =20 >>> down to the part that will eventually break. >>> >>> Do you have any plan on how one could quantum secure 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=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=A1ti= ak: >>>> >>>>> Taproot specifically did not do this for good reasons that are well= =20 >>>>> documented. I recommend you to read documentation first before attemp= ting=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 problem= : >>>>>> - P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and puts= =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 ful= l=20 >>>>>> 32-byte x-only public key directly in the scriptPubKey, making outpu= ts 12=20 >>>>>> bytes larger than P2WPKH and exposing the key in every unspent outpu= t. >>>>>> >>>>>> 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 a= s=20 >>>>>> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verif= ication=20 >>>>>> works by key recovery: given the signature (R, s) and the challenge = e =3D=20 >>>>>> TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verif= ier=20 >>>>>> recovers P =3D e^-1 * (s*G - R) and checks that hash160(P.x) matches= the=20 >>>>>> program. The sighash reuses the BIP341 transaction digest, so cross-= version=20 >>>>>> 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 wit= ness =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 P2= SKH. >>>>>> 2. Naming =E2=80=94 "P2SKH" follows the established pattern but "P2T= RKH" has=20 >>>>>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcom= e. >>>>>> >>>>>> Full draft:=20 >>>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e72= 18620be580dc/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-ad6c= -2ddfe68ec73en%40googlegroups.com=20 >>>>>> >>>>>> . >>>>>> >>>>> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489= a77012038n%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/= 967d68e7-ba38-4e28-bc36-bf256a8c85a9n%40googlegroups.com. ------=_Part_64871_460028237.1773733258101 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone,

After reading all the feedback, I think it's time t= o accept that this proposal has no realistic path forward.

For i= t to make sense, the new address type would need to be adopted by the entir= e ecosystem almost instantly =E2=80=94 which is simply not going to happen.=

Honestly, this idea might have had better timing a few years ag= o. Today, the landscape has moved on, and I don't think pushing this furthe= r would 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 202= 6 at 08:32:06 UTC+1 Saint Wenhao wrote:
> The goal is giving users w= ho are already happy with the P2WPKH model (no script spending, simple sing= le-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 ca= n have 71 bytes without grinding, which means, that by using a CPU to grind= r-value and s-value, to shrink it by 4 bytes each, you will get 63 bytes i= n a DER signature. And that won't reveal your private key to anyone els= e. It would require around 2^33 operations, so it is doable on CPUs.
Which means, that if you want to have smaller signatures, and you are will= ing to put some Proof of Work into that, then you will get better results b= y just staying with P2WPKH. And, as leading zeroes are not pushed in DER si= gnatures, because of BIP-66, and as computing power is getting better and b= etter, your signatures could be smaller in the future, while in Schnorr sig= natures, you won't have any way to go below 64 bytes.

pon., 16 mar 2026 o 17:12=C2=A0sashabeton <sashabe...@gmail.com> napisa=C5=82(a):=
To clarify the design intent: P2SKH is not a stripped-dow= n 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 paymen= ts), and the only change is replacing ECDSA with the same Schnorr signature= scheme Taproot's key-path uses. That's it.

The goal is givi= ng users who are already happy with the P2WPKH model (no script spending, s= imple single-key payments) the witness efficiency of Schnorr without forcin= g them onto a 34-byte output type designed for a richer feature set they do= n't need.

P2SKH is not quantum-resistant =E2=80=94 I fully ackno= wledge this. Like P2WPKH, it relies on secp256k1 and will need to be migrat= ed once post-quantum schemes are deployed in Bitcoin. But until that happen= s, it serves the same users as P2WPKH today, just more efficiently. When th= e time comes, users migrate =E2=80=94 the same way P2PKH and P2WPKH users w= ill 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://= github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2= skh.md
PoC implementation: https://github.com/bitcoin/bitcoin/= pull/34826

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-ad= 6c-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+...@googlegro= ups.com.
To view this discussion visit ht= tps://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a7701= 2038n%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/967d68e7-ba38-4e28-bc36-bf256a8c85a9n%40googlegroups.com.
------=_Part_64871_460028237.1773733258101-- ------=_Part_64870_1020186924.1773733258101--