From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 23 Mar 2026 02:54:31 -0700 Received: from mail-qt1-f191.google.com ([209.85.160.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w4bzR-0004GJ-6I for bitcoindev@gnusha.org; Mon, 23 Mar 2026 02:54:31 -0700 Received: by mail-qt1-f191.google.com with SMTP id d75a77b69052e-50939597b85sf204204701cf.2 for ; Mon, 23 Mar 2026 02:54:28 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1774259662; cv=pass; d=google.com; s=arc-20240605; b=AsYOWRgeQEo/lGF9DmYEnk6/RLW54SFrH4Fb/3vnQXbQ7mos3K9EuSJbsteijfVlxt fnm4TMkydN0pRUoCMg09++EwyHln2SCdh/z3MPJypvBbS1GVmZckeuIJc/DjISj84xY5 wIR1kqkK3PO6IGUg7NbbbK4yQaOOL18DKrOjd6aEUJLVPk0BaOZ5+nRAHWSCBCP40I/P f8b5fY2dvbKin0HgWFp+fOSy87YU792fPhmC/UwNQp3wSKY8cbT2RdRaT3T8exFLXrNl Kv8YwHaAaUB7SJsykX9/T7A8qKMvW/13mI9VeMq/KTQ0Boruhc/J0f7a3OuBtj//VWhj nxcQ== 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=qD/HPltDpZwE1Ot6DKNHyPuRswFQ4SNe8/yRRCaAt7I=; fh=X1E3Kbt3aWM/crAr8Dk7xVoLLolfBpX4FbNXyiMr2ks=; b=lBo9Z330wj/jqm+3ndqd8m7wnGiKrLDo/tT6D50y2KWzFoEIJ1w05DjFV+aTamAsZ9 UWeto/NU0TEAAcyf/HXPlnpjafuQMnfbGRXUhymDpbaxboLQ8WNw+a5Y9RGuR0f2vLnj kLK6WvNWJZPTFwlh9U3YETU0vdTijrZLFvJYSBFNJwcFm90RdntevEB7AsBi4mfE5VSs tSv5C/3y4lUuCHqbKAU7371Goa+SU7IOIhYS+znt8rafkTzqn5Pm7pme+cdxt4O39F5d pF3wQsXYxXTrw+KERzbg1ZTYtfpsZIPNqBjC2EphaS0G8nhJ3oVhZMblDhTAI8ZivdXt IYqA==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=bOpqK0+k; arc=pass (i=1); spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2001:4860:4864:20::30 as permitted sender) smtp.mailfrom=martin.habovstiak@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=1774259662; x=1774864462; 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=qD/HPltDpZwE1Ot6DKNHyPuRswFQ4SNe8/yRRCaAt7I=; b=SatDpdLdIwZ1/BNCHKd4NEiMcBQrEFDHGNWIbcpyHrRniLknUkL4NItl6kFBHertTg BguSPvAIMqTibmqZblOlcTnqDhc6zDxyMQxUj4cH9MNQIhT5Qi3QY6/RDJBWAA2jUrJM Krrh+LQhDdQiWItf/ABjP6/NLK56SAJDg7c39O7jq/7hKDBFgCxbIozWmhFOHggKW5aV bqePK5VH8Wa56XQGHZBu6z3/VYVRyDTjsu0IdzzKn8rGghvBl312NK2omlASOAXVfrs4 rguto1VUz1Bp4Arwc9+CJhdTMtJP+tnfINkovD80OFLTZoOEnmrlvYOEIExI9wu2DmqF 1aog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1774259662; x=1774864462; 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=qD/HPltDpZwE1Ot6DKNHyPuRswFQ4SNe8/yRRCaAt7I=; b=A+pQnZKQeN2B04xixbaECNDVLIhyPdNTzUd+dweVue7+883DU/ynCoQUscgPefF88F edaBhPWmMQ+akSsagquk48thh39wrDBS0n+hD32dIvzC4ZOOYdqf+187hIJhhHUWxTqj 9PZXAuRLfY7VrqoaNMNb013WaBUb1NI50f5tmIJqzDBWvCUIuBSsyj4XHfW7Yvl6aL7L PV6NxFEVM6Je55ltdA6c7gLZCfaLD2tlePDlZPNYaj7Qf+ppHbbLx31/7xmb4ynrSH/u w7PFAr/4DcKAjLfOI7cxooLsfPTT2yyXVp08E0FmpUUAgqNIJKvTscFtXeBjyDFACrsL npGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774259662; x=1774864462; 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=qD/HPltDpZwE1Ot6DKNHyPuRswFQ4SNe8/yRRCaAt7I=; b=dpV4HEZo6s56kkqHdHe0fDNY4JU2vJfKFyrL5qzfLWn4wpBT2ZSgKiHHglm6tKKNDx c7oI+HCIS9DB71fL6xmy+/OZAxu6yi6Q6XhMWWi15vqmgrYNoPSOtggEOy4nZCZIXVcI bb2eeeQSZ5i0zkilKLpvgyyc7+T3aYzSUrp0DHf9XVhdlrtV7gbQwirCI63AW3YsxXT+ tzik/RgWmZgyUEEPyDbIhfIZ0hLoqyxsC/MiSM3VA/X2e2SAh+cIz71cqwpzGP5pbSke lQSoPqD5qpIoEgsKdAzZcDtY8eLsiPGHAmfo0iezGr14FNOnVqJFcxbAvuKu0CW+EYkB 0hzw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCXR6xYwpnSX0bMMiOscpgEZq5v0pZ5j/EsChlgMk6UNrGM660huh/jcPvTg7X0vixzO8k4oNUxyIYfN@gnusha.org X-Gm-Message-State: AOJu0Yx7Nezk/HeitWsuRrx4JdRNHOFYEMILpp/X2JXqAZBVWm7PXl8C 1M/o78xbQA39V8ga4HmX+eJQ4lTsXEG8zu2d9+R56IKQtkDuJ5yTeKab X-Received: by 2002:a05:622a:1444:b0:50b:50bf:5bd0 with SMTP id d75a77b69052e-50b50bf65a6mr88323321cf.8.1774259661899; Mon, 23 Mar 2026 02:54:21 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+Eot7xXOY0XksQucFgjxmiTW3BUCGxo+mrDbtPdE+b4ng==" Received: by 2002:a05:622a:5445:b0:50b:4ad3:a32b with SMTP id d75a77b69052e-50b4ad3d3d3ls22427221cf.0.-pod-prod-01-us; Mon, 23 Mar 2026 02:54:16 -0700 (PDT) X-Received: by 2002:a05:620a:6cc2:b0:8cd:e162:1ea3 with SMTP id af79cd13be357-8cfc80bb013mr1662677485a.58.1774259656744; Mon, 23 Mar 2026 02:54:16 -0700 (PDT) Received: by 2002:a05:6808:618f:b0:467:4299:91ac with SMTP id 5614622812f47-467563f61a3msb6e; Mon, 16 Mar 2026 09:25:50 -0700 (PDT) X-Received: by 2002:a05:6a00:139a:b0:827:4526:517 with SMTP id d2e1a72fcca58-82a19703a3bmr11948943b3a.7.1773678348434; Mon, 16 Mar 2026 09:25:48 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1773678348; cv=pass; d=google.com; s=arc-20240605; b=ffFdt3flLfwTwXUX7slhG7tBUsvdp7+Q/tHn/QQvdb+8L09LjL0J5zzFWEb4jqSzY+ NmD/YYEsehEJn3MkLQ9fzcyunsqEviI9MM63YrMEF4MI6f0dcR+Q8/pHkSYNMqOTM3mr hv4QRj8cI9T5nX4ukI2gkQNZyd1dpJo643HiPSMTzwl90wMp4oIOz8yoErAO3nlKg9kq Ilqdsv65IHa7uq5BIpoVziem3zEE//Tk5n/zOwigYQ70n/9ftGWc0OAlHOxxrIr2B87n xJ9JunByxe6I9C7PzWACMm1JrrBX4+HaNnxpNxX2x5nXwn6AOh9cIg7QM/vj4fhBMVNM uy4g== 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=navE4y88pK4H+YxaRRDiNcAZgqz1CHjTpqB86FlKJeM=; fh=mQ65DjksMfpG9wM24PB36rad6dWAmzL2MpuOdHPZPFg=; b=WeVyb3K1iOr7mCezevkKGV3rrAYLKtZ2rn2M56h80OIyAAXoZLMOuEvkYYk7V0P+ln MoqHb9MfWeICyTNcoEgStoe5D90hMxLZLyxPG1eVKyyZ0tyIjNKPhQuJWu4kwKWpUJAV iaV1PpQR2OSwicTgquKGuvZ6bThwHMYazW/41UySglz7ZFLd9D1KEheE1aev/o5VEbC0 Nu+D5EyxvRW1yxl3+KRUUJIteunW1alvbW3ZReUh9usJ3RbkVpaROvT/rGyXshd/x++L /CsYLeUCEOKUcDcr4nO3VJazVPNhF00TvBVeAH9XYnchMpFZYzLceXRB9js1TInXBPxz iXRQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=bOpqK0+k; arc=pass (i=1); spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2001:4860:4864:20::30 as permitted sender) smtp.mailfrom=martin.habovstiak@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com. [2001:4860:4864:20::30]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-82a073b0ee3si412935b3a.8.2026.03.16.09.25.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Mar 2026 09:25:48 -0700 (PDT) Received-SPF: pass (google.com: domain of martin.habovstiak@gmail.com designates 2001:4860:4864:20::30 as permitted sender) client-ip=2001:4860:4864:20::30; Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-40f387a688dso3679100fac.0 for ; Mon, 16 Mar 2026 09:25:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773678348; cv=none; d=google.com; s=arc-20240605; b=STXv6feBS8o+aZz+EYhL5HH/Wwdeqm/XX0ixQLMwRAf5fQ8dwFH0Ih5dXkCmz3QM0H emzXdZ4mzTvnGA3oKUwfcs5HpUZKXYHDkYG65qdL73Rwv9usnaEYqIJwl73f1qubdQ+3 OBS/VsblxVu8WDkh514/p/YQ8YiUTn8Uqq/NYDnVy0z/MFOA8Dbw4Am3Y79qKD2aZCmF KyJWQ6ed8q5TDrM7MA+7XmeS+zy0sgtRc052u2GIsL8YJklLtYmtcs/qdHddywH7JzvN QVlEHiVAKYWwumsTQC9mtTJ9WM/65OiUIPv8NNnCnTsn9JYliHz8yDMggrNLRm/i+L/U RJ+A== 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=navE4y88pK4H+YxaRRDiNcAZgqz1CHjTpqB86FlKJeM=; fh=mQ65DjksMfpG9wM24PB36rad6dWAmzL2MpuOdHPZPFg=; b=QNE6A/8FPheAK4vf2zQfIA1Xh6eo82O1XxD8XXVGJQbHDYA4PubbNBE3Wl9M1q+nWA fLwSd/IYGXDobAX6pagLMawnsXTb/YCrgiW0RUzRwTrhODDJv7VFdWwgVl8gheGQ0f+R bUgjGzX4H6qTf79bHcmw01rEsPl5U+yBoiVwPzmOAbSa6tnFsGOin07GiKrb7GVtcjTm mNaeSGHvfi5SL43QVG3mNEcQ47GAM6kxwmu/P9XkbcOR/+LHkkMlgxnI2w5AAOprMw/Y OiV0phDrTY+mFgIhnKZjjSGy6398aLRmNF9EbdzC//z3Cc02iebyAVYNS3ihGCQkWWho WqNw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: ATEYQzwSxgxiiECJbLKEhhsnO8Y6FCoTJYclwQls9XXzVi1okMKV7fFLdUDybKyrX1o KkQ4ybdyIOQsqxloR94nkfKgrkvn3o1qaqoTjKEGRkMwhe2z0WDNclm1vYvOaZvUIf8goZQnNlM WjzJKp5DZULa4/KfLd5aQFcVRxr2cmOSE9/R/m/n0lET22loGnj2LYoefqUkMgZzKXne7B0aPrO 3SkL7Fju3Tnm0oltEiO48QVWS+HpLy2LrtUJ/+Jf2LDKCIJg5U5VKDvdKLkGM141Wz2ntzlWUGc tGloMOA= X-Received: by 2002:a05:6820:290d:b0:678:f8f3:d6dd with SMTP id 006d021491bc7-67bda98e367mr8191030eaf.8.1773678347426; Mon, 16 Mar 2026 09:25:47 -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: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= Date: Mon, 16 Mar 2026 17:25:36 +0100 X-Gm-Features: AaiRm50erQjgKYV9rVip5zbw3IEDEhdZ5cegp5KLn_BAy1YfFlDdTjoPtFYFknU 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="000000000000d81da1064d26abb1" X-Original-Sender: martin.habovstiak@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=bOpqK0+k; arc=pass (i=1); spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2001:4860:4864:20::30 as permitted sender) smtp.mailfrom=martin.habovstiak@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 (/) --000000000000d81da1064d26abb1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It doesn't matter because it competes with Taproot and that is the problem. People should be migrating from old schemes to Taproot to maximize 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 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/= CALkkCJaZ8150yWFLGe6NUuBrNE_N5AnekaqrG%3DNcnWy1zWUQHQ%40mail.gmail.com. --000000000000d81da1064d26abb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It doesn't matter because it competes with Tapro= ot and that is the problem. People should be migrating from old schemes to = Taproot to maximize anonset of Taproot, not to $a_new_key_only_scheme or Ta= proot.

Forcing users to = use Taproot even if they don't need scripting is a desirable feature an= d intentional design from the beginning. 12B is justified cost for better p= rivacy.

D=C5=88a po 16. 3. 2026, 17:12 sash= abeton <sashabeton2007@gmail= .com> nap=C3=ADsal(a):
To cl= arify 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-byt= e hash commitment, no script path, single-key payments), and the only chang= e is replacing ECDSA with the same Schnorr signature scheme Taproot's k= ey-path uses. That's it.

The goal is giving users who are alread= y happy with the P2WPKH model (no script spending, simple single-key paymen= ts) the witness efficiency of Schnorr without forcing them onto a 34-byte o= utput type designed for a richer feature set they don't need.

P2= SKH is not quantum-resistant =E2=80=94 I fully acknowledge this. Like P2WPK= H, it relies on secp256k1 and will need to be migrated once post-quantum sc= hemes are deployed in Bitcoin. But until that happens, it serves the same u= sers as P2WPKH today, just more efficiently. When the time comes, users mig= rate =E2=80=94 the same way P2PKH and P2WPKH users will have to.

On Monday, 1= 6 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 by= tes by removing all the scriptability, OP-code upgradeability and basically= locking yourself to a non-quantum-secure key spend path that is only quant= um secure if never spent? Or did I missunderstand?

m=C3=A5ndag 16 mars 2026 k= l. 12:25:57 UTC+1 skrev Martin Habov=C5=A1tiak:
Taproot specifically did not d= o this for good reasons that are well documented. I recommend you to read d= ocumentation first before attempting to make changes.

D=C5=88a po 16. 3. 2= 026, 11:48 sashabeton <sashabe...@gmail.c= om> nap=C3=ADsal(a):
Hi ev= eryone,

I'd like to propose a new native SegWit output type: Pay= to Schnorr Key Hash (P2SKH).

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

The t= wo most relevant output types today each solve half the problem:
- P2WPK= H has a compact 22-byte scriptPubKey, but uses ECDSA and puts the full 33-b= yte compressed public key in the witness (~108 witness bytes per input).- P2TR uses Schnorr signatures (64-byte witness), but embeds the full 32-b= yte x-only public key directly in the scriptPubKey, making outputs 12 bytes= larger than P2WPKH and exposing the key in every unspent output.

Ne= ither type achieves both a compact output and a compact witness simultaneou= sly.

=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: give= n the signature (R, s) and the challenge e =3D TaggedHash("P2SKH/chall= enge", 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 re= uses the BIP341 transaction digest, so cross-version replay is prevented by= the scriptPubKey commitment.

The result is the smallest combined fo= otprint of any current single-key output type =E2=80=94 a 22-byte output wi= th a 64-byte witness =E2=80=94 while keeping the public key off-chain until= spending.

=3D=3D Tradeoffs =3D=3D

The key-recovery step cost= s roughly one extra field inversion and scalar multiplication compared to d= irect Schnorr verification. This is the price of the 12-byte output size re= duction.

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

1. BIP360 also claims w= itness version 2. If both proposals advance, one needs to move. Version 3 s= eems like a natural alternative for P2SKH.
2. Naming =E2=80=94 "P2S= KH" follows the established pattern but "P2TRKH" has been su= ggested to emphasise Schnorr/taproot lineage. Opinions welcome.

Full= draft: https://github.com/sashabeton/bips/blob/3cb9e07984b571e951= 0370ab7e7218620be580dc/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+...@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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CALkkCJaZ8150yWFLGe6NUuBrNE_N5AnekaqrG%3DNcnWy1zWUQHQ%40ma= il.gmail.com.
--000000000000d81da1064d26abb1--