From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 23 Mar 2026 02:54:30 -0700 Received: from mail-qv1-f60.google.com ([209.85.219.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w4bzR-0004GH-23 for bitcoindev@gnusha.org; Mon, 23 Mar 2026 02:54:30 -0700 Received: by mail-qv1-f60.google.com with SMTP id 6a1803df08f44-89a0a2afc55sf347538726d6.0 for ; Mon, 23 Mar 2026 02:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1774259662; x=1774864462; 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=5/3oVlSv4Y+bp2Rf+t8QWuIFfYdc18Zm6qMrKx2pAog=; b=ubHRmbWznoDf1aOfeGITVeuO5k9cJW+D2G49Yo2adtqF+uGux87AcSbveqPY5WKPb0 KAbtYv38AUk8keC86RSnedqCMhZB8shsR6edstbOMmselb0vMONHaI71GdQxLHeaYbfs FwDOk/m0tONApgbsDHX1eOEPAz1bpO3gt/GvOqNUxJIGd/K1A5bSZ02LhfPdIpH1YbsE HqPibADqykwKVvROdRxXdN5LV4vGJ/YeGcb91XbKUiYdCDfvbKc5bx9ApRZJ8twLfLbj RgH4jHxXY0J+Etr15V4H4y5vH54bxkFwKKO6TxVTpbqQVGcp3ZVmNINAmq8PmTAU2Z3X caVA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1774259662; x=1774864462; 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=5/3oVlSv4Y+bp2Rf+t8QWuIFfYdc18Zm6qMrKx2pAog=; b=CsIL7grt22piGGDKnVNedhNzoL9qNxrAdRLNwXf2kfO8ZHCKCAJ1iq8bOv6wo4EZww Jbh/AA1HxE2anPcNHb+QNmF2l07vYzfZ/Qv4s8pyxW571EFijbd9oJYzM6Aage48T0zo CD8l2qcZSIbpnsM6wUE0i4Nh10vQ7E2S/19Thiq3wEv3hKGhj3WNwX71EhFhAnTfMRRs 5JTQZksVmiVkVWSnUx7MuT2ipvfNYk7nMp+5Hf03BF84uFk4zPOhaZnMVVKm+LqWYHHI ptFLpy6d9g2sGgkHJPlN9yV+Uny/GrcsTh1cFY7OxZrVRdVtGYxuW9U9gcHJWW6eRC88 HnmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774259662; x=1774864462; 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=5/3oVlSv4Y+bp2Rf+t8QWuIFfYdc18Zm6qMrKx2pAog=; b=bOthakGXHt3izO+FKd7/LeLRymztSavgeqgG2xTeIwv/3+FvzOqLYLyOUsB/TrqCWJ PSLpcjQ9gpl+88KRAveaBIMwHvjr+9/gYPlQxHObkf5gjPVPuB219BlWLWXCSPhESEFF bmOI/zYZkMY7bJLfASxfyv3K2UlEXkjsqrQzJv3Bx4AVt48BTvYCMFeM+EvKDiykhUe5 WpwzoZaiIxodBATEb3UCD/0Wj9lkZdyEy9kqwAJ51rTMfuUj33M8peIs2+IPm24W5t5v cvmh9iaSrSJqwof+L3m5qjvTGZRMXc1WTQmQppSEoFu/ebt6NSw7cCtKEPlRG7Q82VLj Dvnw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXXZX3keHhCArJrSHzHIxc80NfE49yvFfNcCXQV0c0dv2KIREhmOA4liqvJ6K4tS6eZQlNV+xQrJF/s@gnusha.org X-Gm-Message-State: AOJu0YxCSmR1X1eWIjCs6jxGvjIVh3XWmnCSFMf0t8aOoWGN1oJ5EmQu KtNfDlJnCD033uYJNp3DtP9yIPbhKv/N6tvTAcBoIWGaxThRjiwekQ1n X-Received: by 2002:a05:6214:2dc9:b0:89c:5289:4bf5 with SMTP id 6a1803df08f44-89c859d0895mr185341096d6.3.1774259661837; Mon, 23 Mar 2026 02:54:21 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJ2sDI2ZJmWPRb1gWQqCZ8nQzbMN+k1ASWBhhXuk4jI/Q==" Received: by 2002:a05:6214:21cb:b0:895:4b79:839f with SMTP id 6a1803df08f44-89c781f78dcls82450546d6.2.-pod-prod-03-us; Mon, 23 Mar 2026 02:54:16 -0700 (PDT) X-Received: by 2002:a05:620a:294e:b0:8cd:c01e:f000 with SMTP id af79cd13be357-8cfc7b65b98mr1699627885a.12.1774259656745; Mon, 23 Mar 2026 02:54:16 -0700 (PDT) Received: by 2002:a05:690c:c003:b0:794:c577:7579 with SMTP id 00721157ae682-79a1c173ca3ms7b3; Mon, 16 Mar 2026 12:29:25 -0700 (PDT) X-Received: by 2002:a05:690c:6186:b0:79a:55f5:a3f6 with SMTP id 00721157ae682-79a55f5ee8dmr30639017b3.26.1773689364296; Mon, 16 Mar 2026 12:29:24 -0700 (PDT) Date: Mon, 16 Mar 2026 12:29:23 -0700 (PDT) From: Alex To: Bitcoin Development Mailing List Message-Id: 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_2826_790370918.1773689363825" 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_2826_790370918.1773689363825 Content-Type: multipart/alternative; boundary="----=_Part_2827_1653702928.1773689363825" ------=_Part_2827_1653702928.1773689363825 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Okay sorry, I got a bit hyper focused on the comparison with Taproot. m=C3=A5ndag 16 mars 2026 kl. 17:12:33 UTC+1 skrev sashabeton: > To clarify the design intent: P2SKH is not a stripped-down Taproot =E2=80= =94 it is=20 > P2WPKH upgraded to Schnorr. The starting point is P2WPKH (compact 20-byte= =20 > hash commitment, no script path, single-key payments), and the only chang= e=20 > 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 P= 2WPKH, it=20 > relies on secp256k1 and will need to be migrated once post-quantum scheme= s=20 > are deployed in Bitcoin. But until that happens, it serves the same users= =20 > as P2WPKH today, just more efficiently. When the time comes, users migrat= e=20 > =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 Taproot= 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" chos= e=20 >> whether to use the key-spend path or the script-spend path. Your solutio= n=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 compariso= n=20 >> against Taproot or BIP360. And since we will need quantum upgrade at som= e=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 k= ey=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=A1tia= k: >>> >>>> Taproot specifically did not do this for good reasons that are well=20 >>>> documented. I recommend you to read documentation first before attempt= ing=20 >>>> to make changes. >>>> >>>> D=C5=88a po 16. 3. 2026, 11:48 sashabeton 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 b= ytes=20 >>>>> per input). >>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the full= =20 >>>>> 32-byte x-only public key directly in the scriptPubKey, making output= s 12=20 >>>>> 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 as= =20 >>>>> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verifi= cation=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 verifi= er=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-v= ersion=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 witn= ess =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 i= s 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 P2S= KH. >>>>> 2. Naming =E2=80=94 "P2SKH" follows the established pattern but "P2TR= KH" has=20 >>>>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcome= . >>>>> >>>>> Full draft:=20 >>>>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e721= 8620be580dc/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, sen= d=20 >>>>> 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 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/= cce91330-c897-471e-903a-5a3bea7c622dn%40googlegroups.com. ------=_Part_2827_1653702928.1773689363825 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Okay sorry, I got a bit hyper focused on the comparison with Taproot.
=
m=C3=A5nd= ag 16 mars 2026 kl. 17:12:33 UTC+1 skrev sashabeton:
To clarify the design intent: 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 p= ath, single-key payments), and the only change is replacing ECDSA with the = same Schnorr signature scheme Taproot's key-path uses. That's it.
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 without forcing them onto a 34-byte output type designed for a rich= er 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 to be migrated once post-quantum schemes are deployed in Bitcoin= . But until that happens, it serves the same users as P2WPKH today, just mo= re efficiently. When the time comes, users migrate =E2=80=94 the same way P= 2PKH 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 by= tes by removing all the scriptability, OP-code upgradeability and basically= locking yourself to a non-quantum-secure key spend path that is only quant= um secure if never spent? Or did I missunderstand?

m=C3=A5ndag 16 mars 2026 k= l. 12:25:57 UTC+1 skrev Martin Habov=C5=A1tiak:
Taproot specifically did not d= o this for good reasons that are well documented. I recommend you to read d= ocumentation first before attempting to make changes.

D=C5=88a po 16. 3. 2= 026, 11:48 sashabeton <sashabe...@gmail.com> = nap=C3=ADsal(a):
Hi everyone,
=
I'd like to propose a new native SegWit output type: Pay to Schnorr= Key Hash (P2SKH).

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

The two most rel= evant output types today each solve half the problem:
- P2WPKH has a com= pact 22-byte scriptPubKey, but uses ECDSA and puts the full 33-byte compres= sed public key in the witness (~108 witness bytes per input).
- P2TR use= s Schnorr signatures (64-byte witness), but embeds the full 32-byte x-only = public key directly in the scriptPubKey, making outputs 12 bytes larger tha= n P2WPKH and exposing the key in every unspent output.

Neither type = achieves both a compact output and a compact witness simultaneously.
=3D=3D The proposal =3D=3D

P2SKH uses OP_2 <hash160(P.x)> as = the scriptPubKey (22 bytes, same as P2WPKH). Spending requires a single 64-= byte Schnorr signature. Verification works by key recovery: given the signa= ture (R, s) and the challenge 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 BI= P341 transaction digest, so cross-version replay is prevented by the script= PubKey commitment.

The result is the smallest combined footprint of = any current single-key output type =E2=80=94 a 22-byte output with a 64-byt= e witness =E2=80=94 while keeping the public key off-chain until spending.<= br>
=3D=3D Tradeoffs =3D=3D

The key-recovery step costs roughly o= ne extra field inversion and scalar multiplication compared to direct Schno= rr verification. This is the price of the 12-byte output size reduction.
=3D=3D Open questions =3D=3D

1. BIP360 also claims witness vers= ion 2. If both proposals advance, one needs to move. Version 3 seems like a= natural alternative for P2SKH.
2. Naming =E2=80=94 "P2SKH" fo= llows the established pattern but "P2TRKH" has been suggested to = emphasise Schnorr/taproot lineage. Opinions welcome.

Full draft: https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370= ab7e7218620be580dc/p2skh.md
PoC implementation: https://github.= com/bitcoin/bitcoin/pull/34826

Thanks in advance for any feedbac= k.

--
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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/cce91330-c897-471e-903a-5a3bea7c622dn%40googlegroups.com.
------=_Part_2827_1653702928.1773689363825-- ------=_Part_2826_790370918.1773689363825--