From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 16 Mar 2026 03:48:51 -0700 Received: from mail-oo1-f64.google.com ([209.85.161.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 1w25VC-00050G-UU for bitcoindev@gnusha.org; Mon, 16 Mar 2026 03:48:51 -0700 Received: by mail-oo1-f64.google.com with SMTP id 006d021491bc7-67bb5810407sf78491035eaf.3 for ; Mon, 16 Mar 2026 03:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1773658125; x=1774262925; 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:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=o/8FsdwvQvjHX1iV/KxWu/AVz0zXt/GcQJIqyDdEVk4=; b=uoDJHn6eO6Yz1EuGv1LTuYndOjnE/bhOFtmoVBOmfL3z1E65ABOxn0Z4u2nT/9iiC+ 7Z/Gu2e26UYvrbsdXone83gur3reCyUmDposxsp3dCMiI4HBzvDphkenXCK0xoUx6k9C U+FnUWPIsgnbfvSKTKRJx52AYXMGLCEZ2fR2GZIg8c7uXE8GQ93NRr+ZxYkxR2cNsrSM Hei19IP/tMdKBy/4PSTyrht5blVt+Iy03Pj4BfBkoj4d+SIUqO5TXJuZScism0AYBrkv bSrgYG7slCs6kXaQQOEH6u85DeiS/GLyEamJoB+VbB/Ml/Xg0+q0syNgGXaVbq5UcSGr vG4g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773658125; x=1774262925; 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:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=o/8FsdwvQvjHX1iV/KxWu/AVz0zXt/GcQJIqyDdEVk4=; b=NLF0Xk+4XOK2AMMknQtATNbW7tq3JoFQKAgOjm8tlemGkE+pUdckua+sGlH8r+9Vm5 KMGEtxZ0FOF7LPPnMW4kMJ6jfiq6O/Ulh/iEhYbBpS6mJpBuVjlUynTiwehRlfxRgJsk FERfDrK1Q7hyl1kHI0ZwDfzcZgORGnkLsM2f0gIoSb04vG772wP7IS8743CkUVfITo86 68o764icT3ZPiCdG/fdMtjbf9IitnMa/HaIsoCNI+nR3ClJrGubNkmjUVFITahePPbk/ fSgZIvVNKxHexfGwf/v6q/qD/k2Sl9z9B1AFE6Cw1qXQRbWKKPMxin3aBTB+pXxepAoO 6SRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773658125; x=1774262925; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=o/8FsdwvQvjHX1iV/KxWu/AVz0zXt/GcQJIqyDdEVk4=; b=LZejsC9vi2feA1cCxnTNfIlW1/V1W6ACo79HoP7cjPQNLQLpWuksYBKKnN/TeuZ7V1 CQqepPd+daj/SSpgtWs/0v1xEXC730LSU0LeQqTmCRpc3hy7t7qX6c61zHz1J+ANHTpf HjCnDJyIXGJZnEoSo/4d4WeN834ulmnvVCJ9/59Vp0ObfXW3jF9vHKCb7U1Xtxf8I5E7 4jqkC6ME6PwioTs4uiXhMESwU9TVXlD88DQpMIokHlmM373TiScj8GlFtd0Ipk02z8kq 13MrIhHfcHkM6G6ndt8t4eEc9iVZbO3IaFkFtAt57gZ/JD5ZOgWmeG9qJog2ZztdyZcY FrDw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVbhfDnfD1L1MIceMyQCCRhwk5eskKNccJ5GvXZJYBggre+svghpDnpkE6NjbfMewoTPEtePpRo0D7Z@gnusha.org X-Gm-Message-State: AOJu0YzC4+W+SI8qhkKo2fySE1JQoHTTTjvHaSE/gDGmWvUnroCsVvTL 65DbnfmLIBNa8KZqPUHGy89kmqTFm7/khst8RUjTdgRPUlk5viQ5SdKR X-Received: by 2002:a05:6820:1624:b0:67b:c7a0:e4ec with SMTP id 006d021491bc7-67bda9c0f51mr8967632eaf.22.1773658125038; Mon, 16 Mar 2026 03:48:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+Ghx0Bnk5j3WsnGu8atNXOL0DAHHSzjFFtQcMofPvVEqg==" Received: by 2002:a05:6870:176a:b0:3c9:732d:60f2 with SMTP id 586e51a60fabf-417b55467f4ls1875474fac.1.-pod-prod-02-us; Mon, 16 Mar 2026 03:48:40 -0700 (PDT) X-Received: by 2002:a05:6808:15a2:b0:467:100d:22c9 with SMTP id 5614622812f47-467571425f6mr6560567b6e.19.1773658120803; Mon, 16 Mar 2026 03:48:40 -0700 (PDT) Received: by 2002:a05:690c:e585:b0:79a:4274:53d4 with SMTP id 00721157ae682-79a42747e04ms7b3; Mon, 16 Mar 2026 01:51:46 -0700 (PDT) X-Received: by 2002:a05:690c:3387:b0:798:6400:c876 with SMTP id 00721157ae682-79a1c1d9d5dmr128609567b3.51.1773651105934; Mon, 16 Mar 2026 01:51:45 -0700 (PDT) Date: Mon, 16 Mar 2026 01:51:45 -0700 (PDT) From: sashabeton To: Bitcoin Development Mailing List Message-Id: <3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en@googlegroups.com> Subject: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_473128_235442720.1773651105333" 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_473128_235442720.1773651105333 Content-Type: multipart/alternative; boundary="----=_Part_473129_1884035140.1773651105333" ------=_Part_473129_1884035140.1773651105333 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 the=20 full 33-byte compressed public key in the witness (~108 witness bytes per= =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. Verification= =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 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 single-key=20 output type =E2=80=94 a 22-byte output with a 64-byte witness =E2=80=94 whi= le 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 scalar=20 multiplication compared to direct Schnorr verification. This is the price= =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" ha= s been=20 suggested to emphasise Schnorr/taproot lineage. Opinions welcome. Full draft:=20 https://github.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be= 580dc/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 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/= 3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com. ------=_Part_473129_1884035140.1773651105333 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 types today each solve half the proble= m:
- P2WPKH has a compact 22-byte scriptPubKey, but uses ECDSA and put= s the full 33-byte compressed public key in the witness (~108 witness bytes= per input).
- P2TR uses Schnorr signatures (64-byte witness), but emb= eds 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 output and a compac= t 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. Verificatio= n works by key recovery: given the signature (R, s) and the challenge e =3D= TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifier re= covers P =3D e^-1 * (s*G - R) and checks that hash160(P.x) matches the prog= ram. The sighash reuses the BIP341 transaction digest, so cross-version rep= lay is prevented by the scriptPubKey commitment.

The result is t= he smallest combined footprint of any current single-key output type =E2=80= =94 a 22-byte output with a 64-byte witness =E2=80=94 while keeping the pub= lic key off-chain until spending.

=3D=3D Tradeoffs =3D=3D
<= br />The key-recovery step costs roughly one extra field inversion and scal= ar multiplication compared to direct Schnorr verification. This is the pric= e of the 12-byte output size reduction.

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

1. BIP360 also claims witness version 2. If both proposal= s advance, one needs to move. Version 3 seems like a natural alternative fo= r P2SKH.
2. Naming =E2=80=94 "P2SKH" follows the established pattern b= ut "P2TRKH" has been suggested to emphasise Schnorr/taproot lineage. Opinio= ns welcome.

Full draft: https://github.com/sashabeton/bips/blob/= 3cb9e07984b571e9510370ab7e7218620be580dc/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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com.
------=_Part_473129_1884035140.1773651105333-- ------=_Part_473128_235442720.1773651105333--