From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 16 Mar 2026 08:45:35 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w2A8M-0001a2-Jw for bitcoindev@gnusha.org; Mon, 16 Mar 2026 08:45:35 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-40ef793e45esf18405972fac.3 for ; Mon, 16 Mar 2026 08:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1773675928; x=1774280728; 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=eBiYHkdUuy6qG4gYbBbyfBn9Nbrq6UE2cDAjaY1/y9M=; b=cJz61VraKfqYphBzCQBgfk4q6krejVBEB2wdcsXrUI8qOuMQwL2Ses0w4boqMZ0GZ4 mGU2vIn63yu110mFvpcH02jqTYahUJtsXGbrX0w7A3RQt4vhECyScqkTv28YTzQLYGQe WvjCCSwfEPJQ11MhU2OSCDC7lgaWzsmb+KDDvvgLh6yMmZYR1MAo4kvkm59uduPk9VTY BkR826LRIuy4atTjUyjO4rBMmo4mjb14A8LkR64j70fLpI/drx9RcrPHRcf8qpFtCZxM k2RsAs65jI896u1evkUwoLtyEYqZlChJPv+vwzhqK/X+LXcdSbUxIrcqVnBqsjKQJWIR 0ZDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773675928; x=1774280728; 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=eBiYHkdUuy6qG4gYbBbyfBn9Nbrq6UE2cDAjaY1/y9M=; b=R2d4CiVNUDWNgIocLmTq3KQvr1Gmoes2o4aPh74eUWh5nF9hOYKJ6Qno15HPza+qXR Zi443vd6NgUtcpYzNSkRj7xQ7JtoAjW4Q/C4AN/ei7Z14ybj1oYh6u2kuVxOagm3cZ+r B4r7A/yxHPGg25pTDcgTKjj6F7VgsCkkwp6jmig4rL9LiVFui2c2SEUBMUPPDjCwbWKd FHQnQLYVxgxgbbt5E5m4FBR122B4Em7v0zldJ5SNo5DZgDKztMB6rhRezez3l4w7fy1J uhWTeP70qjeH80MjwUypE4/EqstMRY6NYnqxbd1mcng/Uuty2srtXlEfQtFgBLoeQsCc 2T+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773675928; x=1774280728; 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=eBiYHkdUuy6qG4gYbBbyfBn9Nbrq6UE2cDAjaY1/y9M=; b=jfHYFAyRcXKg5TSmgQbd+hrsd86Ev6TjN5j3K0nk8c5PgqulH6F7bYpTa0RTqeyDQH 6XGzz6ukdhKIzIET+moTtpg1wV8AYlnzy1Z5pqwSTqbb/EqsBm9XaeRAtMG6xS4v8d6+ R490ofZd6PssH+mDM3KAkCdvCpkspMELHghRYRAFKJFwL13/zMRUlf8RKWL3IoBdCA3Q wWw8C+eSuqrjSaBeQQfXkwaD+oCgoh78iWHy0LZYrd1qqoKVXOwiWe+tPDEFfXJX9vzM Q1EAA7Z+yiDEVKBqOHMR+7xd95/gIrbbWgcoxeVYnwfgF2WJQb+m/ngGGq3TxagEMLmd adDQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUG1RhId58Jt4V88S0nub2dqGXkr5zEbhlcz9qGEHcBnDrjeS0qtjvXS2LOYOmKsU/6N3CLbBr+36d2@gnusha.org X-Gm-Message-State: AOJu0YwN78GixDB8q94IQx3eHB11VWs1Vd/DMZpVx4dOascOHjCSx97I TRtGgvSrMct8b/AApMTaGfFHi82mhUPRShUmnjqzSksM+TzIZx7WayTV X-Received: by 2002:a05:6871:ca:b0:417:6237:cf82 with SMTP id 586e51a60fabf-417b923e031mr8093970fac.23.1773675928376; Mon, 16 Mar 2026 08:45:28 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+F/B1Nyh7QszAL4+0L9ppOEH33nionQbYGyp0S9Ud3DJw==" Received: by 2002:a05:6870:31b6:b0:409:6297:eafe with SMTP id 586e51a60fabf-417b815b485ls2130391fac.1.-pod-prod-07-us; Mon, 16 Mar 2026 08:45:22 -0700 (PDT) X-Received: by 2002:a05:6808:3008:b0:450:41ca:6bd8 with SMTP id 5614622812f47-467571391e1mr7540572b6e.25.1773675922306; Mon, 16 Mar 2026 08:45:22 -0700 (PDT) Received: by 2002:a05:690c:e585:b0:79a:4274:53d4 with SMTP id 00721157ae682-79a42747e04ms7b3; Mon, 16 Mar 2026 07:36:44 -0700 (PDT) X-Received: by 2002:a05:690c:6e85:b0:798:23f:7933 with SMTP id 00721157ae682-79a1c18f8cbmr123736397b3.37.1773671803820; Mon, 16 Mar 2026 07:36:43 -0700 (PDT) Date: Mon, 16 Mar 2026 07:36:43 -0700 (PDT) From: sashabeton To: Bitcoin Development Mailing List Message-Id: <9e030d1e-0eab-4463-948e-ef3ec3c43b1bn@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_743122_1778405622.1773671803198" 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_743122_1778405622.1773671803198 Content-Type: multipart/alternative; boundary="----=_Part_743123_2113279596.1773671803198" ------=_Part_743123_2113279596.1773671803198 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On scriptability and OP-code upgradeability: P2SKH is explicitly a=20 single-key output type, the same as P2TR key-path spending. If you need=20 Tapscript or OP-code upgradeability, you use P2TR. P2SKH targets the same= =20 use case as P2WPKH today: simple, high-volume payments where you have one= =20 key and no script conditions. In that use case P2TR key-path spending=20 offers no scriptability either =E2=80=94 this is not a new trade-off, it is= the=20 same one Taproot already made. On quantum security: the broader quantum-resistance question is legitimate,= =20 but it applies equally to all of Bitcoin's current output types. A proper= =20 solution requires a post-quantum signature scheme =E2=80=94 a new cryptogra= phic=20 assumption. Until such a scheme is designed, reviewed, and adopted by the= =20 network (a multi-year process), there is value in keeping the 20-byte=20 hashed address format that wallets and users already know, while gaining=20 Schnorr efficiency. P2SKH offers exactly that bridge, without waiting for a= =20 problem the entire ecosystem has yet to solve. On Monday, 16 March 2026 at 12:57:52 UTC+1 Alex wrote: > 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/= 9e030d1e-0eab-4463-948e-ef3ec3c43b1bn%40googlegroups.com. ------=_Part_743123_2113279596.1773671803198 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On scriptability and OP-code upgradeability: P2SK= H is explicitly a single-key output type, the same as P2TR key-path spendin= g. If you need Tapscript=C2=A0or OP-code upgradeability, you use P2TR. P2SK= H targets the same use case as P2WPKH today: simple, high-volume payments w= here you have one key and no script conditions. In that use case P2TR key-p= ath spending offers no scriptability either =E2=80=94 this is not a new tra= de-off, it is the same one Taproot already made.
On quantum security: the broader quantum-re= sistance question is legitimate, but it applies equally to all of Bitcoin's= current output types. A proper solution requires a post-quantum signature = scheme =E2=80=94 a new cryptographic assumption. Until such a scheme is des= igned, reviewed, and adopted by the network (a multi-year process), there i= s value in keeping the 20-byte hashed address format that wallets and users= already know, while gaining Schnorr efficiency. P2SKH offers exactly that = bridge, without waiting for a problem the entire ecosystem has yet to solve= .
O= n Monday, 16 March 2026 at 12:57:52 UTC+1 Alex wrote:
You are saving 12 bytes by removin= g all the scriptability, OP-code upgradeability and basically locking yours= elf to a non-quantum-secure key spend path that is only quantum secure if n= ever spent? Or did I missunderstand?

m=C3=A5ndag 16 mars 2026 kl. 12:25:57 UT= C+1 skrev Martin Habov=C5=A1tiak:
Taproot specifically did not do this for good= reasons that are well documented. I recommend you to read documentation fi= rst before attempting to make changes.

=
D=C5=88a po 16. 3. 2026, 11:48 sashab= eton <sashabe...@gmail.com> nap=C3=ADsal(a):<= br>
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 relevant output type= s today each solve half the problem:
- P2WPKH has a compact 22-byte scri= ptPubKey, but uses ECDSA and puts the full 33-byte compressed public key in= the witness (~108 witness bytes per input).
- P2TR uses Schnorr signatu= res (64-byte witness), but embeds the full 32-byte x-only public key direct= ly in the scriptPubKey, making outputs 12 bytes larger than P2WPKH and expo= sing the key in every unspent output.

Neither type achieves both a c= ompact output and a compact witness simultaneously.

=3D=3D The propo= sal =3D=3D

P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey = (22 bytes, same as P2WPKH). Spending requires a single 64-byte Schnorr sign= ature. Verification works by key recovery: given the signature (R, s) and t= he 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 h= ash160(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 singl= e-key output type =E2=80=94 a 22-byte output with a 64-byte witness =E2=80= =94 while keeping the public key off-chain until spending.

=3D=3D Tr= adeoffs =3D=3D

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

=3D=3D Open= questions =3D=3D

1. BIP360 also claims witness version 2. If both p= roposals advance, one needs to move. Version 3 seems like a natural alterna= tive for P2SKH.
2. Naming =E2=80=94 "P2SKH" follows the establ= ished pattern but "P2TRKH" has been suggested to emphasise Schnor= r/taproot lineage. Opinions welcome.

Full draft: https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620b= e580dc/p2skh.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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/9e030d1e-0eab-4463-948e-ef3ec3c43b1bn%40googlegroups.com.
------=_Part_743123_2113279596.1773671803198-- ------=_Part_743122_1778405622.1773671803198--