From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 17 Mar 2026 00:32:14 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.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 1w2OuT-0004tm-2v for bitcoindev@gnusha.org; Tue, 17 Mar 2026 00:32:14 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-417ad9ac95fsf5398132fac.0 for ; Tue, 17 Mar 2026 00:32:12 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1773732726; cv=pass; d=google.com; s=arc-20240605; b=lWWpIm8TAjS6HCtVeQcL9P60VZ5OFe24SbzZrBEiMKgDL+YzghJXN2mLvjRgZPGOs7 hb0nXIlS9QIONY1BAZ9C10j7vQfeDL8/ysxMb0S4kfWgXo3KimcuIVsyUdNdHmztEwYc 2VpkW6vZ0KqCbQFfYcBHbTN+h9jNDCge1ww33zs5GqEyQM9JWx0CsY8u9h4UoxvuEMq9 9YYLWx4lC3Jo0g/XMMv3bxYzm4jNe0SsXeJJofi99fxyQqMNemlbD7K1THduB3PD2ANW 1gaDRdDBouWt+LpnV8rQwvk19+nfbRwKUDQZIbBWVBrZGVGGXTZr40ct6QgRyJnegqTz oVAg== 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=sIc0PS6jnfxsKvGOVMQAAftGfs4JIjAiesR/BlCxnBA=; fh=UpEOQ0r+e+13XYa0mplenZn+H+/42xOa5ZCVU8+NnlQ=; b=IC/9Fgk0IusRvhzOKpu/v9/xVxanlehpni47yV+hTj1lVKlFAhhlSdO+sHby6b3C1O me9AQ+pAhPjDJIjBaR6UmtIUvX9hWfWd68CkAfa9g5nodUcJapO1QplPs5IE2rWNmou9 nRXK0/YfptDhb4CKF2QZVBO219cMErTbHyENvpDpCB6W7Rp1kpRN4LaL3hKASLFV1LYe yhjnRuhrqeUspkcIZ9q0vPsj6BqSQtlgRRJe9fYFZHRZAoFqMYpHsIZGUaO18bFz/0oX 36f+yn8kJiMXQSmjld+vtxa2IqOyST3sy299cQHTXVGaIwT9NZ8YeOhfy0/VtGygqLtN qvfQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HBg8cTcz; arc=pass (i=1); spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=saintwenhao@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=20230601; t=1773732726; x=1774337526; 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=sIc0PS6jnfxsKvGOVMQAAftGfs4JIjAiesR/BlCxnBA=; b=wxW+57SorZjirQ5kQV7Kgn40jJ7F0ZbmMJUwJFk54Frdh5IXdfgrH26T/t/hVayyGE olMxRpGvTxy9o84gZ+5Cu4uI0Y4v2zt9XNlQ0YqX/anS+OZkuWf5TheJmiFeyDA3ees4 l6r0YeO3ARTXC2ozx9JoNQemhcCFUXCNt46R9wz/RCuNvyKWUiJsEKsvsZxDbBCS1WlM AqdQsvAeZBoyPYkSmmQTX+IKiRv+15IP9lW0puQE8KXF8J4gqD3ffJWqxogfwgfncLHb 8gzK8FgHvq9CigCdd5/E+awWTwBuUyQMr5TIUVLvgEmBhVwv6NA7JbLYG6Yf8hcS+PPe ibMA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773732726; x=1774337526; 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=sIc0PS6jnfxsKvGOVMQAAftGfs4JIjAiesR/BlCxnBA=; b=dUpvR9B1UG9q6RmKMRab+ZiQAb8a1RwNraNUqzCCWGa6jxY8QVmdXXBJ0BbcBXzm7n at5tIwVgK36WoJlCeel2EUy1Hh7fKtFIye4dBQVkS0fPEp8CFtHymeFAYsVEgEbDF4xe J6PYbDB6vPv/JlD0Qc7vEAiDsEhNF/KFntaFbhDlR/Z+RFsreW7SvWO4ymq37dTmkTKa V+/YYRq54rwWqCBZqKZVIXy9iyMjn3xh90LUoLYCQYtMVhLS0XdOgFl0I9TNsqMVhzY4 925YHYfjKfnzl0Q4VomHRNBtIUT2qaoqZ6pPTPcJLV3Hs9iG8xH9EC5F8o4Ipx1+0Lrm dYiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773732726; x=1774337526; 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=sIc0PS6jnfxsKvGOVMQAAftGfs4JIjAiesR/BlCxnBA=; b=eAN/taILTJdE0+sXv0ritSygNU3fZffNMb9BtEXdp1EgCyhn+Q4y4hQAedqP9jkdoh lf8pfoDozxHylfVenTZ7rFO53RVsOhWDg0l/nHR0bJgrR6GqS3N/EPrQiP9Pfn7FcCRO 24l369MM4jzDF+b8zENEBvLW4g4Mk8iX6SFV9hkZs5VevEFDgGUNndr1QIIqcDLjIME+ gvGppHnFzS4scyWmTznMzPvcc8Y7YRPk4ttGPirO9QQTZwFXYhh3y2/THSTHVkta6dD1 3NmrUa1I5YMqHQnpDtHaTwhSLsU06nysogJOP0G6jeFYpTK7MdeQgPiKji7QIFeiwjX2 JNnA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCXafz/ic+TrieE0DzkPM544cFXofgJzVWGYqrDhM3r7qCvc9EI60xyUenIvb13/GwfPSq5kfl47W/q2@gnusha.org X-Gm-Message-State: AOJu0YyaKkdXtp7sKwP9u9rfn9JX8IQsIhUu9XWgc46AhJCNtCKAWPg+ CE3iN7p5PmYyNqMDt+tbuUyRzMprSV5UYnKZ79ST3SDsNyH2CS3fClcP X-Received: by 2002:a05:6870:6708:b0:417:8539:bdba with SMTP id 586e51a60fabf-41bb05fe55dmr1479612fac.24.1773732726354; Tue, 17 Mar 2026 00:32:06 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+H3zxVWMAq/LYKTczD49iikPEQ2I7xgJDrHRi9uR8Ihfw==" Received: by 2002:a05:6870:c7aa:b0:417:576c:330a with SMTP id 586e51a60fabf-41777f22b96ls1383368fac.0.-pod-prod-00-us-canary; Tue, 17 Mar 2026 00:32:01 -0700 (PDT) X-Received: by 2002:a05:6808:2d8:b0:467:18a3:da78 with SMTP id 5614622812f47-467a7f01090mr1251974b6e.4.1773732721017; Tue, 17 Mar 2026 00:32:01 -0700 (PDT) Received: by 2002:a05:600d:8446:20b0:483:6d47:ea7 with SMTP id 5b1f17b1804b1-48556264e4ems5e9; Tue, 17 Mar 2026 00:23:36 -0700 (PDT) X-Received: by 2002:a05:600c:8519:b0:485:5812:bb9e with SMTP id 5b1f17b1804b1-4855812bbddmr302023235e9.0.1773732214569; Tue, 17 Mar 2026 00:23:34 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1773732214; cv=pass; d=google.com; s=arc-20240605; b=Vu2k9QX7KmQn/e+oOsRIdlegRCCu34+uCKlk0fF2+5YVK3asMe+Q5M4zoMzFpEaMLF genmxULhPDOcvXChG0m0SI1DEp2jO6OMUyeItFVMe4gHJYH4B1XlPBqbpJ/9yymWr/vA 3usLTEYJkwrruF8lyHm2sAkcHDLq3r2MASKt2/buCj/yiAQqD6GJYPvTdsX47DmT54WT MoKIAKl4sdhRu5qLU1AhnfaQYghgCGzvIc6zdLFVy35HUX631A/e6m9YDHKwMhXMLQH2 e1hAjajmbc3myV663FmEsFvpYkgwgKpVaRqEiRm2mvPTX1BlCRbIiHHGOqZkGrbcRDh+ f5xg== 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=JGZYXbrxlbnUkb3qM28UQMtdgol+UfaXov/dJS8wAuE=; fh=mQ65DjksMfpG9wM24PB36rad6dWAmzL2MpuOdHPZPFg=; b=Z7CW7oz4m22w/ftJq7DefO66W6o20q42bFSNZbJQtokgJzjNHQR32soRNu5rAW1T/W s+O8d0NVxx1ru5NYM6olOn5cWeZdzZuI8ZjmpfqSdw9GQLZisC0x9eKkus/7/O3ZAZme alzhU7L0CfiN0+Yw0SMr35TC3CkrmQKc3r/u26kZVfODAsKiSio6wSn+BVlf69P1xMvO q6I4uvYJrcbSGpiyeuNfIuAuw3f/zFKSmx79bGt+7tkX67uyTR8GovhjebHH0xOEWO0d M/eZTC2iWaclCDh5yZQ6EFKswLyQzDda33v+7xpxIlLAmgY9HX4DxS+VQD84qJa+jx5y qpzQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HBg8cTcz; arc=pass (i=1); spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com. [2a00:1450:4864:20::12f]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4856eab6c9asi331665e9.2.2026.03.17.00.23.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Mar 2026 00:23:34 -0700 (PDT) Received-SPF: pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) client-ip=2a00:1450:4864:20::12f; Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-5a1322af04fso6021177e87.2 for ; Tue, 17 Mar 2026 00:23:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773732214; cv=none; d=google.com; s=arc-20240605; b=THZJEKFM/cjbdB5vJ1I+L8Nyv9Wq3jfZt+hazPU5qMAhWCDYs4VM8Fc/mId1X++TQk cNIYHTZLJimgQ/WElHvOWvXtHAskvhe5eyWAnyRqZJbJEp7e3Bix/3dDRwHznLEF4wAZ vk0RO8zgERb9vhdNA2P6E1lq24pWgJRkXddr5EQG6IuVoeR2Kji2Y+d1Zh80ntFfrAVs FSdvPFN05e5eZk5IJZM2Nk6J4YrOmINw0GPtP12aCv+E+5jRESP4VACERRIfnYcLn50M asInL3/uM9hZw+4tw6fsRbB/1hHskOg20cseZfls8EwBi02Ny2DjASV+6+vKd1BbIy89 4l5Q== 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=JGZYXbrxlbnUkb3qM28UQMtdgol+UfaXov/dJS8wAuE=; fh=mQ65DjksMfpG9wM24PB36rad6dWAmzL2MpuOdHPZPFg=; b=YFuysGe/i3OEfWl+4o7sqnIiUFi1S6CpYn8fpWR05ZcdEaXDAMjSJSZHhc7Ut3XnfP SUvMKsSHoOL590CLEaMBXPS5tquf/z6puKKp8uNTZWDTjMKwVvkk2m8gsJ/H/thoHE58 20aR6KouIes5dHRxcWN/CMEOq1dovY7yRYQVBYAeLU8oJDwpCd1JMqc7Sh1CGRsMNhMS 196e9zdKMrlFv5H1CTW4ChWFUpUFFTZzuR326IeWxIRWoCH/3UXkTsdxvZ3cpLcepD6o EqFSmhg5kqgQLkgMlEgYZZBHPvkcQETTnubMzRvO1MULlUyLfVefTs4ATia/z+8d/Fzo qX/g==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: ATEYQzynxN/hQ4BhSXLX0tVipJJ2/I4c92JHfz/Jrj7PKkMVlb1sxlwG/scB7dO2wM3 KwvkxI1R4SpyVyCAOx2yjznXuQ+CAkzK8NxaI+9tkmZij+D6R11Kmu241p1es0o2u1OQxQmdpXp 3YV64Jp0I6MUgTr/ElGCMR35cR6+8cT6t8sjd81GSlp3rExwayj/4mPrqtXEbvdMr5HUYjl3T9f wPGTPDO2heaD5D/BfPSKzN+Kazu45V0RtsF8lYTD7bsr/9PmxlbE7SEJB6ug7/x8DJdkpWOtznY Ko9e7CKUqCGEa8QN X-Received: by 2002:a05:6512:4897:b0:5a1:2e0c:86ee with SMTP id 2adb3069b0e04-5a162b1414amr3840845e87.36.1773732213428; Tue, 17 Mar 2026 00:23:33 -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: Saint Wenhao Date: Tue, 17 Mar 2026 08:23:21 +0100 X-Gm-Features: AaiRm506ryZwn2BqBrf1Qw-bgdHbdIFHmfLNlckOxMB2Qo636ZV68hiNPwsxnGw Message-ID: Subject: Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH) To: sashabeton Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000821707064d333640" X-Original-Sender: saintwenhao@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HBg8cTcz; arc=pass (i=1); spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=saintwenhao@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 (/) --000000000000821707064d333640 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 If you have a DER signature, then it can take from 9 to 73 bytes. In Schnorr signatures, it is set to 64 or 65 bytes. In practice, you can have 71 bytes without grinding, which means, that by using a CPU to grind r-value and s-value, to shrink it by 4 bytes each, you will get 63 bytes in a DER signature. And that won't reveal your private key to anyone else. It would require around 2^33 operations, so it is doable on CPUs. Which means, that if you want to have smaller signatures, and you are willing to put some Proof of Work into that, then you will get better results by just staying with P2WPKH. And, as leading zeroes are not pushed in DER signatures, because of BIP-66, and as computing power is getting better and better, your signatures could be smaller in the future, while in Schnorr signatures, you won't have any way to go below 64 bytes. pon., 16 mar 2026 o 17:12 sashabeton napisa=C5= =82(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 only chang= e > 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 P= 2WPKH, it > relies on secp256k1 and will need to be migrated once post-quantum scheme= s > are deployed in Bitcoin. But until that happens, it serves the same users > as P2WPKH today, just more efficiently. When the time comes, users migrat= e > =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 Taproot= 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" chos= e >> whether to use the key-spend path or the script-spend path. Your solutio= n >> 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 compariso= n >> against Taproot or BIP360. And since we will need quantum upgrade at som= e >> 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 k= ey >>> 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=A1tia= k: >>> >>>> Taproot specifically did not do this for good reasons that are well >>>> documented. I recommend you to read documentation first before attempt= ing >>>> 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 b= ytes >>>>> per input). >>>>> - P2TR uses Schnorr signatures (64-byte witness), but embeds the full >>>>> 32-byte x-only public key directly in the scriptPubKey, making output= s 12 >>>>> bytes larger than 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 as the scriptPubKey (22 bytes, same as >>>>> P2WPKH). Spending requires a single 64-byte Schnorr signature. Verifi= cation >>>>> works by key recovery: given the signature (R, s) and the challenge e= =3D >>>>> TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg), the verifi= er >>>>> 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-v= ersion >>>>> 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 witn= ess =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 i= s 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 P2S= KH. >>>>> 2. Naming =E2=80=94 "P2SKH" follows the established pattern but "P2TR= KH" has >>>>> been suggested to emphasise Schnorr/taproot lineage. Opinions welcome= . >>>>> >>>>> Full draft: >>>>> 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. >>>>> >>>>> -- >>>>> 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, sen= d >>>>> 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 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/ee240078-88c6-4961-8412-489a= 77012038n%40googlegroups.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/= CACgYNOJEDekgg_wA9AS2FHRB%3Dxp%3DwC2BdzD4hHK2rHXWvrZQ%3DA%40mail.gmail.com. --000000000000821707064d333640 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> The goal is giving users who are already happy with t= he P2WPKH model (no script spending, simple single-key payments) the witnes= s efficiency of Schnorr

If you have a DER signature, then it can tak= e from 9 to 73 bytes. In Schnorr signatures, it is set to 64 or 65 bytes.
In practice, you can have 71 bytes without grinding, which means, tha= t by using a CPU to grind r-value and s-value, to shrink it by 4 bytes each= , you will get 63 bytes in a DER signature. And that won't reveal your = private key to anyone else. It would require around 2^33 operations, so it = is doable on CPUs.

Which means, that if you want to have smaller sig= natures, and you are willing to put some Proof of Work into that, then you = will get better results by just staying with P2WPKH. And, as leading zeroes= are not pushed in DER signatures, because of BIP-66, and as computing powe= r is getting better and better, your signatures could be smaller in the fut= ure, while in Schnorr signatures, you won't have any way to go below 64= bytes.

pon., 16 mar 2026 o 17:12=C2=A0sashabeton <= ;sashabeton2007@gmail.com&g= t; napisa=C5=82(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 (comp= act 20-byte hash commitment, no script path, single-key payments), and the = only change is replacing ECDSA with the same Schnorr signature scheme Tapro= ot'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 same 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.<= br>
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.co= m> nap=C3=ADsal(a):
Hi everyone,

I'd like to propos= e 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 e= ach 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 witn= ess (~108 witness bytes per input).
- P2TR uses Schnorr signatures (64-b= yte witness), but embeds 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 ou= tput and a compact witness simultaneously.

=3D=3D The proposal =3D= =3D

P2SKH uses OP_2 <hash160(P.x)> as the scriptPubKey (22 byt= es, same as P2WPKH). Spending requires a single 64-byte Schnorr signature. = Verification works by key recovery: given the signature (R, s) and the chal= lenge 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 commitment.
The result is the smallest combined footprint of any current single-key o= utput type =E2=80=94 a 22-byte output with a 64-byte witness =E2=80=94 whil= e 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 questio= ns =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= P2SKH.
2. Naming =E2=80=94 "P2SKH" follows the established pa= ttern but "P2TRKH" has been suggested to emphasise Schnorr/taproo= t lineage. Opinions welcome.

Full draft: https://github.com/sashabeton= /bips/blob/3cb9e07984b571e9510370ab7e7218620be580dc/p2skh.md
PoC imp= lementation: https://github.com/bitcoin/bitco= in/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-ad6= c-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 https://groups.googl= e.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegrou= ps.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.co= m/d/msgid/bitcoindev/CACgYNOJEDekgg_wA9AS2FHRB%3Dxp%3DwC2BdzD4hHK2rHXWvrZQ%= 3DA%40mail.gmail.com.
--000000000000821707064d333640--