From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 24 Mar 2026 08:26:30 -0700 Received: from mail-qt1-f185.google.com ([209.85.160.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w53eH-0004xV-BL for bitcoindev@gnusha.org; Tue, 24 Mar 2026 08:26:30 -0700 Received: by mail-qt1-f185.google.com with SMTP id d75a77b69052e-5090bc4823csf254327761cf.3 for ; Tue, 24 Mar 2026 08:26:28 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1774365983; cv=pass; d=google.com; s=arc-20240605; b=kXxcu1wN3Ix7fRSp4EebCj9FAS97U/ezFmV7YI2E5xMkPOiRFIg/87PRU7qBasMWNh kLVxRPpMXgcHQ+PaGUsvyjMRoCKaj+vM+wiR/yr/5RSbkzgRT704mDm9pjho3usfvLLM SNZPSVfXTCx6+ACOMGcngmXBZz0pvyQxIfXGTdo6OxebSW0U/WTgiiItgO43itLI0pW9 g42dujlxuZerCpWKgVHBrst+gVYfddpILbDbZw+uZEQX6quFtHuB2n5zwmvTFo7pKKPR rwMQasqYNglXOBWN+SMUOlvu1+zPsDvgEVfVFlMh8UHxmVD94KTf/rdfazuoo3OjUSaL z4JQ== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=+TglALgCkCUVjLvCu/46YuS77xdli1F1QCQ4XV1/X3w=; fh=UYJdxYjnmNERZGDqFZTGrXTnkZb0aQ3Gdrz8HM+Kd38=; b=UGq2xGTnv7YCVuNVcOsy+dDOG3jern9oMP098NAwGjzrYz6b/NGrfNxEJh2bPcDZXz JW1NCE5pRUPzVKHxbfHkTch1r7knD15HdM8UamsuHKjs5taRNAJOuCPNqzQSQ4aAR9Z1 Twm2yoTN3K/lsmvZXCf8DDa0C5Ywf1vfJcijE1aMD+JCTx+jpUHVg0bR6zh5myqR6MBo gWFyd6CooJgPLzAqYQDvpXkp18hDaw07KiHFjAuOaQWKksX7BAeq+Na7Ph2umRny9SxL Dl0P345tgY1jvNZspVm+Sd+WBOo9ABlmK1BION5BxLqUB/gWP7clIUVI3/mMA3/lROVc XgMw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=jPjk3V0K; arc=pass (i=1); spf=pass (google.com: domain of aaron.recompile@gmail.com designates 2a00:1450:4864:20::641 as permitted sender) smtp.mailfrom=aaron.recompile@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1774365983; x=1774970783; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=+TglALgCkCUVjLvCu/46YuS77xdli1F1QCQ4XV1/X3w=; b=nOnsrUh9X/WVNZsf9/kwQF5JwKbzSwPO0TEn7obuoh7sTsToXW8D91a2jU0UDSO1S8 t/q2/LEYxXmNIA4yPMdh1Sdic4o9wwKN3d856/o63a9UKFK6J05KgSaX+yvWganUYoP5 sftRttFTzM1+5vcVk3pY1P/N4S3GRVng1q/duT1SLlLi72vx9glHcqbOZ9bqaE3ozsFr 02yQ3v3M49CMc9dpivux9E8+++2Zt+ubjMpi9+e9HB8bDkct6LJ5yqtoIiE8zdoKAgW3 MpTj41YlhIJthFEI+ntAFNGm3SeuMDsjuq3v6T1THNs/QZMtN/4hzekiZRBo/ELVRlOY hDEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774365983; x=1774970783; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+TglALgCkCUVjLvCu/46YuS77xdli1F1QCQ4XV1/X3w=; b=Fc43A+pv5nE2vjwaLwkzRcyxeGAOpSpSsI6qtrPA44PUJnHLBUoj8ySU5gu9ypELnv P63GaGXhCKS79FU/qsiNUX/30etLYmAgof6MfbqfwHC/N3scZVtm5fc5xfT2+gkDFM6N VRES7Ebtc70IDworKGDi1nZ50pfPFp/ICXWuWAS8cSVfKs9cgURsAWkKdIbGzaIeC9Pe Eaqf/ObkLsckyECDI11frjHZ3DcG1NeuqbbeZZ01d3PL8793UCY/mfqL4q7nQXNlE5dG 2IeJN4PpeNG28Xm8ndkrKdSPnAHPVFzHf70vMHoM/+0V4eoiL9OOnaYd7ZPHWDAU1FNA pVpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774365983; x=1774970783; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=+TglALgCkCUVjLvCu/46YuS77xdli1F1QCQ4XV1/X3w=; b=rL+iXWJjdjo8qEsXDtpkJGiACF9n8tbegvKiAp2jEhsQglXt/zrZmyOYGbOFVhE/8J niwcgzLxfcXi8pmT25HCe9wgxvrBgm9OxNsxfWzZsVBzqCzwUjrFP1KpR/1rayGydG9K ro9WaPNosuP4BA/3xTcyMm5tTJWxpO2wKn/lZ8g1vxBEiWuu5SvVz/suaS2TQezQXMOr Xl9n58nypwBi+X6g/B4LyQrRnyQLXCbWYr6x0beP+wSJu8zkrTn7ul2fjcZBzrdlTg6o HWZh3c+dz9tgMcl7oR8eIpyOzskccuWGWILux9N4arFeBPdboodHClRoyViar3klDa1x eQZw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCUHP+FI1HOK/ibMEitLqb4SQONT1QFxnFezaG4u3ti4lHyf/N2K6iY+CxHFq50uS4A8rmRbW4YZ1Bvb@gnusha.org X-Gm-Message-State: AOJu0YyTKnFp2OgVftGFpo2ABVRS2jszMZFx/1m45f3ITUZkKlkTq84C Q7odNNir0pQCYy74J8oDTJUWBDwF1Uh2ia8FuZvK5gDe26BsT2uOlYOE X-Received: by 2002:a05:622a:6695:b0:50b:36cc:3350 with SMTP id d75a77b69052e-50b80e8f4c9mr121801cf.67.1774365982652; Tue, 24 Mar 2026 08:26:22 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HnbxeidSpxSl7eXBLcBLDXDMF4zRQZ/LwS9Q7fe1vgtg==" Received: by 2002:a05:622a:1308:b0:509:41df:80ff with SMTP id d75a77b69052e-50b2565139dls125366161cf.2.-pod-prod-06-us; Tue, 24 Mar 2026 08:26:16 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXjFu6Qm8nq2W51LP3v6O801g90LBg77R/S//5d7OhFXbPM91cihv9pxxW3AkSXwYKFfkFqBhTUApUj@googlegroups.com X-Received: by 2002:a05:622a:5c89:b0:509:4b11:6cf4 with SMTP id d75a77b69052e-50b80c862a5mr1051311cf.5.1774365976476; Tue, 24 Mar 2026 08:26:16 -0700 (PDT) Received: by 2002:a05:600c:548c:b0:483:6d47:ea7 with SMTP id 5b1f17b1804b1-486feb18167ms5e9; Mon, 23 Mar 2026 23:02:54 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCUYfqcWiXYOcdgANg5k8R2lH8++WUBfxyjZQ8jnXoqfCYbzlnAc6XwXdgjW8aCMYESRH7p2L9dnUYaP@googlegroups.com X-Received: by 2002:a05:600c:c167:b0:486:fab9:a578 with SMTP id 5b1f17b1804b1-486fedc3843mr223240085e9.11.1774332172044; Mon, 23 Mar 2026 23:02:52 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1774332172; cv=pass; d=google.com; s=arc-20240605; b=WpEcy2MkrgLjGNRLZh9UcO8R1cK91SZ95eipj0xUdpJ7EgwdF/QTXBRyUs0J1RMCr1 H4clr7M8zz9tDqXjvJc+MtRkcy8rQ4XbVYCywdHGrglfPsnwLhhP3d8f0UlUb7GHXOr+ gDsHl58oGtYoEKdjadFhcn/B34Sn2HdKwJ9ygPiTTbV5UN6PV5CDSyiKtZ4TFc0ANFQx 3u/FzzdInxVB0O3/6ogLVmWs/ECAyh6K2/c9Pa1OR2mVERkcRrrTdhORrZmeDUiyBOTW LC/xORWTsw4WU+j4H7CTdnlSUFJTfqBPCwCSrJGVtCvaw5LJ78X6vvp4cxrdZ1WCh3Id DS9A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=0b6Cka9lK1NQh0MCLMZc8Qi8ihx9A3B45U/FdeLa0RI=; fh=vVuf4IoEEhdTgR8n46CoSFp+ukyCB/iojzmBbZ1UU9Y=; b=faBbLGa7+SOoN/rqcKMTuDYkzc7F23P3daxmPzqZiSOwb2a845Ep2i5OabUSTPs5kC it3Di3DvCaCWXSXUwt9rFljpoKdLCwhxmDZ1VX1BeLZVuQocqwymiExV7F+MLB75drX7 G9lBEQxvkSHJe5BHgpW3Kh72xBliKLmEGN2pAoQWEAd350yg8kji4l1E9WTMfY50Nq0n Ol1axP62+oADmeDSMANG8hOvsTPof00KafZNHy+nFwBjR0VHiowIThYdpJresNoPoNi/ dubf2yaq1itIQWtr/5EeAvnaTJ1l3fgR1Lk6dd7zV+eyWw8DaZRnfpT+bpLqtpXntea9 2mDQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=jPjk3V0K; arc=pass (i=1); spf=pass (google.com: domain of aaron.recompile@gmail.com designates 2a00:1450:4864:20::641 as permitted sender) smtp.mailfrom=aaron.recompile@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com. [2a00:1450:4864:20::641]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-43b64712af4si272088f8f.8.2026.03.23.23.02.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Mar 2026 23:02:52 -0700 (PDT) Received-SPF: pass (google.com: domain of aaron.recompile@gmail.com designates 2a00:1450:4864:20::641 as permitted sender) client-ip=2a00:1450:4864:20::641; Received: by mail-ej1-x641.google.com with SMTP id a640c23a62f3a-b7cf4a975d2so120137766b.2 for ; Mon, 23 Mar 2026 23:02:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774332171; cv=none; d=google.com; s=arc-20240605; b=EJpWLMzx+t0o7IE572VWbU5jnejDEvHJplg137e5PYYIIaYv8qUbbx6MXzm15v3dHk fQHCE+j5tkOUWP4oPNQQcOeGZ38Jg8Ho92rwcXdeojuP+CdQmIb31NtCm6gdUOjLh0/w leKoVc9J/WUu1fM6OJke5Sees4Bg+Oms3jTWb1xyGTI2o4jiB6oBbA//lZSchqqSilyr Ed0zYUjD3YTpA9QLQf4rKjcmniRjmUOXxEpF+73SWRqlvdbi0fEMy0+/38rjr80vMyxV gD5+W763svyQFWC9ISdihRYYEDzMZZtF5mNnnqKnFpHw9Tc6e5cHJdlNvlP4zHFO3IsN Y4bA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=0b6Cka9lK1NQh0MCLMZc8Qi8ihx9A3B45U/FdeLa0RI=; fh=vVuf4IoEEhdTgR8n46CoSFp+ukyCB/iojzmBbZ1UU9Y=; b=ZaZoNuFcmoKea797/pAYFcdxqw+nQztMA9UncC0MZmNuKXhSgVCsDCh9Af397PYS8K Ap0VGGVRNfrYYI3Epa+Xt9gyqnFQCfBT34Q92xOZEH6oZVU0G/s0UTf3Yfu4W0re0jd5 XyAso/wWZXnLUOpHRLAP344pINa0r8Q1jXGiKmKFj460y4KyV7knepPDNmzpSU7uQziJ mXb1hGLEg9Ui/e3Cg/LAoAv/me0Sm6NqL05CZbCZO0u31Ig5IJ8DKR4yUE7X4z4RukkV 98ZXH8jgZqLOM0pQG1O2XJJuQWhJGGFvowNPiMZCsmFQzB1M2D7niCs+Vf9Ps9VWf0DT 53tg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCVHyRXuYb/JyYHRp0tLpXacOKW6Y+ml8MD2IfaEiQS/71iy4/1g/t45+dCNqMRVVsRFr5uXnbNP1N3T@googlegroups.com X-Gm-Gg: ATEYQzz4Dj4r/pc8kprH5Xd7F7m4VtZYPSVkcjlHvaPFxsc+RIKjSPBicAGMfzCo9Rt 4cyJgIs7VmXSJeRXD8XJ0N1kn54zEgEq8egr4K+qfd0bbSpWxWQZPkDfKU0V/qmyDZn3w/++sqa gMSEJRq39Z2/oIf2MR2zK+yWuPnLq4GXXbmqju22eCMhOlynGIOPcLrPvEyX0/fObEHDlezeGWy cLNgxWQgA/Q5RnrGyzSYD5hqLyQsCqXnm1kXq4tyI+l0cFfQlbEINn/3qhxoOd4u9KaciZubarr Fh59p3rKcSOtLurjAhndEKNOLYh21grgYsen+uk= X-Received: by 2002:a17:907:2d86:b0:b98:7e20:b1d with SMTP id a640c23a62f3a-b987e200e74mr279217566b.50.1774332171194; Mon, 23 Mar 2026 23:02:51 -0700 (PDT) MIME-Version: 1.0 References: <3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en@googlegroups.com> <4df4b49e-f8f8-4d6f-b98f-7a4a27902800n@googlegroups.com> In-Reply-To: From: "aaron.recompile" Date: Mon, 23 Mar 2026 23:02:39 -0700 X-Gm-Features: AQROBzBmSeK94KIjBTx-O76hgnIIeWZLNkv7Okypq0PZflUECeZLFXOMNLKLhHM Message-ID: Subject: Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) To: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= Cc: sashabeton , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000c71b5c064dbee6dd" X-Original-Sender: aaron.recompile@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=jPjk3V0K; arc=pass (i=1); spf=pass (google.com: domain of aaron.recompile@gmail.com designates 2a00:1450:4864:20::641 as permitted sender) smtp.mailfrom=aaron.recompile@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --000000000000c71b5c064dbee6dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, A small observation on the script path objection. The issue seems to come from committing to P rather than to the Taproot output key Q. If instead: Q =3D P + H(P || merkle_root)=C2=B7G (as in BIP341) scriptPubKey =3D OP_2 then the Taproot commitment structure is preserved =E2=80=94 script path works as in P2TR, key path uses recovery against Q. In other words, the loss of script path is not inherent to hashed-key outputs. It comes from hashing the wrong object. This doesn't address the broader concerns around hash security or deployment. But it might help clarify where the structural break actually is. Aaron Zhang On Mon, Mar 23, 2026 at 2:54=E2=80=AFAM Martin Habov=C5=A1tiak < martin.habovstiak@gmail.com> wrote: > It doesn't matter because it competes with Taproot and that is the > problem. People should be migrating from old schemes to Taproot to maximi= ze > anonset of Taproot, not to $a_new_key_only_scheme or Taproot. > > Forcing users to use Taproot even if they don't need scripting is a > desirable feature and intentional design from the beginning. 12B is > justified cost for better privacy. > > D=C5=88a po 16. 3. 2026, 17:12 sashabeton > nap=C3=ADsal(a): > >> 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 path, single-key payments), and the o= nly >> 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 >> richer 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 s= ame >> users as P2WPKH today, just more efficiently. When the time comes, users >> 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 >>> either =E2=80=94 this is not a new trade-off, it is the same one Taproo= t already >>> made. >>> >>> This is not true. Taproot has 2 modes; its key-spend path is 12 bytes >>> more bloated than your solution, yes. but Taproot can "dynamically" cho= se >>> whether to use the key-spend path or the script-spend path. Your soluti= on >>> fully removes the script spend path, so you're not really optimizing an >>> equally capable solution, you're optimizing 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 comparis= on >>> against Taproot or BIP360. And since we will need quantum upgrade at so= me >>> point, this upgrade is kind of (in my personal interpretation) doubling >>> 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 >>>> upgradeability and basically 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=A1ti= ak: >>>> >>>>> Taproot specifically did not do this for good reasons that are well >>>>> documented. I recommend you to read documentation first before attemp= ting >>>>> 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 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 full 33-byte compressed public key in the witness (~108 witness = bytes >>>>>> per input). >>>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the ful= l >>>>>> 32-byte x-only public key directly in the scriptPubKey, making outpu= ts 12 >>>>>> bytes larger than P2WPKH and exposing the key in every unspent outpu= t. >>>>>> >>>>>> Neither type achieves both a compact output and a compact witness >>>>>> simultaneously. >>>>>> >>>>>> =3D=3D The proposal =3D=3D >>>>>> >>>>>> P2SKH uses OP_2 as the scriptPubKey (22 bytes, same a= s >>>>>> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verif= ication >>>>>> works by key recovery: given the signature (R, s) and the challenge = e =3D >>>>>> TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verif= ier >>>>>> 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 output type =E2=80=94 a 22-byte output with a 64-byte wit= ness =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 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 proposals advance, >>>>>> 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 >>>>>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcom= e. >>>>>> >>>>>> Full draft: >>>>>> 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. >>>>>> >>>>>> -- >>>>>> 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 email 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 Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489= a77012038n%40googlegroups.com >> >> . >> > -- > 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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CALkkCJaZ8150yWFLGe6NUuBrNE_= N5AnekaqrG%3DNcnWy1zWUQHQ%40mail.gmail.com > > . > --=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/= CAEmKuUFxMi4NUMGrJTc-kMEJ0roS%2BrRP_OwyyNvaoFUP1vEzMA%40mail.gmail.com. --000000000000c71b5c064dbee6dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

A small observation on the script path objectio= n.

The issue seems to come from committing to P rather than
to t= he Taproot output key Q. If instead:

=C2=A0 Q =3D P + H(P || merkle_= root)=C2=B7G =C2=A0 (as in BIP341)
=C2=A0 scriptPubKey =3D OP_2 <hash= 160(x(Q))>

then the Taproot commitment structure is preserved =E2= =80=94 script
path works as in P2TR, key path uses recovery against Q.<= br>
In other words, the loss of script path is not inherent to
hashe= d-key outputs. It comes from hashing the wrong object.

This doesn= 9;t address the broader concerns around hash security
or deployment. Bu= t it might help clarify where the structural
break actually is.

= Aaron Zhang

On Mon, Mar 23, 2026 at 2:54=E2=80=AFAM Ma= rtin Habov=C5=A1tiak <mar= tin.habovstiak@gmail.com> wrote:
It doesn't matter becaus= e it competes with Taproot and that is the problem. People should be migrat= ing from old schemes to Taproot to maximize anonset of Taproot, not to $a_n= ew_key_only_scheme or Taproot.

Forcing users to use Taproot even if they don't need scripting i= s a desirable feature and intentional design from the beginning. 12B is jus= tified cost for better privacy.

D=C5=88a po 16. 3. 2026, 17:12 sa= shabeton <= sashabeton2007@gmail.com> nap=C3=ADsal(a):
To clarify the design intent: P2SKH is no= t a stripped-down Taproot =E2=80=94 it is P2WPKH upgraded to Schnorr. The s= tarting point is P2WPKH (compact 20-byte hash commitment, no script path, s= ingle-key payments), and the only change is replacing ECDSA with the same S= chnorr signature scheme Taproot's key-path uses. That's it.

= The goal is giving users who are already happy with the P2WPKH model (no sc= ript spending, simple single-key payments) the witness efficiency of Schnor= r without forcing them onto a 34-byte output type designed for a richer fea= ture 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 more eff= iciently. When the time comes, users migrate =E2=80=94 the same way P2PKH a= nd 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 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.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 relevant output typ= es today each solve half the problem:
- P2WPKH has a compact 22-byte scr= iptPubKey, but uses ECDSA and puts the full 33-byte compressed public key i= n the witness (~108 witness bytes per input).
- P2TR uses Schnorr signat= ures (64-byte witness), but embeds the full 32-byte x-only public key direc= tly in the scriptPubKey, making outputs 12 bytes larger than P2WPKH and exp= osing the key in every unspent output.

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

=3D=3D The prop= osal =3D=3D

P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey= (22 bytes, same as P2WPKH). Spending requires a single 64-byte Schnorr sig= nature. Verification 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 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 commitmen= t.

The result is the smallest combined footprint of any current sing= le-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://gi= thub.com/sashabeton/bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2sk= h.md
PoC implementation: htt= ps://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+...@googlegrou= ps.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-70= 2a-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 bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit h= ttps://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a770= 12038n%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+unsubscribe@googlegroups.com.
To view this discussion visit https:= //groups.google.com/d/msgid/bitcoindev/CALkkCJaZ8150yWFLGe6NUuBrNE_N5Anekaq= rG%3DNcnWy1zWUQHQ%40mail.gmail.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/bitcoindev/CAEmKuUFxMi4NUMGrJTc-kMEJ0roS%2BrRP_OwyyNvaoFUP1vEzMA%40ma= il.gmail.com.
--000000000000c71b5c064dbee6dd--