From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 16 Mar 2026 08:45:39 -0700 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w2A8Q-0001a3-PO for bitcoindev@gnusha.org; Mon, 16 Mar 2026 08:45:39 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-417573e447bsf38757576fac.3 for ; Mon, 16 Mar 2026 08:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1773675933; x=1774280733; 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=LmxoAjZREqxNksfte2JLvd9fHsxZNq5cOYzvyByo6II=; b=lcC7w3ZNkCMl3sTZQG5+x98pTvCcT8/u9u9tASmWLsPKcXBYsjYPys5Bq0jQkRpWwZ RX9Gep8i4OvtksaBRiW1L+FYt9jgwnjFA6piYihK06F/B21kYdlAYITYH3MwwieBRw5I CE8vi0q7u9oPX0muMd5rjA3ONi95TL+K+a+hx0iZwpkMRN/0+S9nTBh7pQ5O135074TN feoUaq7Jala+gSn20lzUTdJvtvnGsc25+vnJTstHogbHUMly6mgGgI971LTZkal1Slba EJ29ZF6aaeINh51PUkx4CrYXt3+/aW3H6slQ1dXDLHs1zIzgTZ6BWI6jwC+GIiQgazeP LqBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773675933; x=1774280733; 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=LmxoAjZREqxNksfte2JLvd9fHsxZNq5cOYzvyByo6II=; b=lAIjuUE9nmbLZpfaBzs22hZtSsx6FwUJ+QTGhEzZ9zBPMUJswn7PI/rQb2FIGNVLkM 2AGJp7qAJ0OUNb5mOlHoZkGTzt11XN3j9WPBqiLbBA8rYD1iFHTqh1Wh/FKv5DLwcAaH bWBX34eARigEEPCXFFvJJAY/s8YBLVk6p+VgUQ07CKcX/gWAZdu3BkU7UKFCtIBaT0VR GVmpxky+R+zfi7dCzu0lE4hRoAwKr6caLkCq9m6Eo5LZswtvPIlNXPSP094py1PQ+0M6 XgZVmcIV69zj4TPfeeyh9xkYsm90TXrcLPPwijZpxWzJHRGnQpmEpKHEapnufKm6WQdp 6xQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773675933; x=1774280733; 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=LmxoAjZREqxNksfte2JLvd9fHsxZNq5cOYzvyByo6II=; b=eM9Nr9ghTai1lsPRoS/R2qrw0AXc5op37oLPHgmttl7jM5w9por1EwMvst7cGr7Wws LT4Oaz4lrRM4zthlU04/Z32uDAfR6bXvQ5umpSOOxasqo9O32YHT9++9KTOFqK8pXWWo aJ+O+emY2HPVXN9MaFr5wp/zNoorIH2DT5fgHFkoiuF1c9izeSwql6RcrYRqg/CjvpG4 J/lBEJc6Z8W/FfohCHbaRpd6JNnHmiRQmkIZzyx4elgs1NNbAbkkqzKH1zsmMiWEXLkv fLg2QLDBGLlfrseDQrSWv98BFx3vmoiUNNjqhCnCnJlJ6g/zK90LzLo9yusSlKAI76hk eHtQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVe5oJ1sKzpH+pdprZT8bLFiUpeWCiGyWtI7YjtEq8syfp9i5kttdlEFL+SRR+4vOfFEYkP4S4a8JiM@gnusha.org X-Gm-Message-State: AOJu0YzSqVmJqnrLZ2do9B8NeX385bAak2S1u9TRyAZupn0gDbE4zZOv bVmTm++BX2oDgUdr4ew8pQsAaF3fwWA+orSqtGUC6rTyC6tbZmUdfg2g X-Received: by 2002:a05:6870:3b8e:b0:417:22c9:a311 with SMTP id 586e51a60fabf-417b902ecbcmr8266767fac.6.1773675932639; Mon, 16 Mar 2026 08:45:32 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+FFf9x7FG7jN5uMTP4yC3RmE6EOR/mhJVgrvX3tFXxB3A==" Received: by 2002:a05:6871:e78e:b0:40e:fc09:2e2e with SMTP id 586e51a60fabf-417b560d75els2206740fac.1.-pod-prod-05-us; Mon, 16 Mar 2026 08:45:28 -0700 (PDT) X-Received: by 2002:a05:6808:1a0a:b0:466:fd68:c876 with SMTP id 5614622812f47-4675766f4d7mr7375026b6e.53.1773675928222; Mon, 16 Mar 2026 08:45:28 -0700 (PDT) Received: by 2002:a05:690c:a193:b0:794:2788:2ae4 with SMTP id 00721157ae682-79a1c07b7c5ms7b3; Mon, 16 Mar 2026 08:43:44 -0700 (PDT) X-Received: by 2002:a05:690c:c16:b0:798:d8c2:94 with SMTP id 00721157ae682-79a1c1a708dmr129485827b3.32.1773675823227; Mon, 16 Mar 2026 08:43:43 -0700 (PDT) Date: Mon, 16 Mar 2026 08:43:42 -0700 (PDT) From: Alex To: Bitcoin Development Mailing List Message-Id: <4df4b49e-f8f8-4d6f-b98f-7a4a27902800n@googlegroups.com> In-Reply-To: References: <3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en@googlegroups.com> Subject: Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_753086_1405835808.1773675822789" 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_753086_1405835808.1773675822789 Content-Type: multipart/alternative; boundary="----=_Part_753087_127098770.1773675822789" ------=_Part_753087_127098770.1773675822789 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > In that use case P2TR key-path spending offers no scriptability either = =E2=80=94=20 this is not a new trade-off, it is the same one Taproot already made. This is not true. Taproot has 2 modes; its key-spend path is 12 bytes more= =20 bloated than your solution, yes. but Taproot can "dynamically" chose=20 whether to use the key-spend path or the script-spend path. Your solution= =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 comparison= =20 against Taproot or BIP360. And since we will need quantum upgrade at some= =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=A1tiak: > >> Taproot specifically did not do this for good reasons that are well=20 >> documented. I recommend you to read documentation first before attemptin= g=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 Key= =20 >>> 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 th= e=20 >>> full 33-byte compressed public key in the witness (~108 witness bytes p= er=20 >>> input). >>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the full= =20 >>> 32-byte x-only public key directly in the scriptPubKey, making outputs = 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. Verifica= tion=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 verifier= =20 >>> recovers P =3D e^-1 * (s*G - R) and checks that hash160(P.x) matches th= e=20 >>> program. The sighash reuses the BIP341 transaction digest, so cross-ver= sion=20 >>> replay is prevented by the scriptPubKey commitment. >>> >>> The result is the smallest combined footprint of any current single-key= =20 >>> output type =E2=80=94 a 22-byte output with a 64-byte witness =E2=80=94= while keeping the=20 >>> public key off-chain until spending. >>> >>> =3D=3D Tradeoffs =3D=3D >>> >>> The key-recovery step costs roughly one extra field inversion and scala= r=20 >>> multiplication compared to direct Schnorr verification. This is the pri= ce=20 >>> of the 12-byte output size reduction. >>> >>> =3D=3D Open questions =3D=3D >>> >>> 1. BIP360 also claims witness version 2. If both proposals advance, one= =20 >>> needs to move. Version 3 seems like a natural alternative for P2SKH. >>> 2. Naming =E2=80=94 "P2SKH" follows the established pattern but "P2TRKH= " has=20 >>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcome. >>> >>> Full draft:=20 >>> https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e72186= 20be580dc/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, send= =20 >>> an email to bitcoindev+...@googlegroups.com. >>> To view this discussion visit=20 >>> https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2d= dfe68ec73en%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/= 4df4b49e-f8f8-4d6f-b98f-7a4a27902800n%40googlegroups.com. ------=_Part_753087_127098770.1773675822789 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >=C2=A0 In that use case P2TR key-path spending offers no= scriptability either =E2=80=94 this is not a new trade-off, it is the same= one Taproot already made.

This is not true. Taproot has = 2 modes; its key-spend path is 12 bytes more bloated than your solution, ye= s. 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 you're not really optimizing an equally capable solution, you're optimiz= ing for only 1 part of it.

Removing scriptability for = 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 BIP360. 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 will eventual= ly break.

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

m=C3=A5ndag 16 mars 20= 26 kl. 12:25:57 UTC+1 skrev Martin Habov=C5=A1tiak:
Taproot specifically did no= t do this for good reasons that are well documented. I recommend you to rea= d documentation first before attempting to make changes.

D=C5=88a po 16. 3. = 2026, 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 Schnor= r Key Hash (P2SKH).

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

The two most re= levant output types today each solve half the problem:
- P2WPKH has a co= mpact 22-byte scriptPubKey, but uses ECDSA and puts the full 33-byte compre= ssed public key in the witness (~108 witness bytes per input).
- P2TR us= es Schnorr signatures (64-byte witness), but embeds the full 32-byte x-only= public key directly in the scriptPubKey, making outputs 12 bytes larger th= an 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 sign= ature (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 B= IP341 transaction digest, so cross-version replay is prevented by the scrip= tPubKey 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-by= te witness =E2=80=94 while 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 Schn= orr verification. This is the price of the 12-byte output size reduction.
=3D=3D Open questions =3D=3D

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

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

Thanks in advance for any feedba= ck.

--
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/4df4b49e-f8f8-4d6f-b98f-7a4a27902800n%40googlegroups.com.
------=_Part_753087_127098770.1773675822789-- ------=_Part_753086_1405835808.1773675822789--