From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP proposal] Pay to Schnorr Key Hash (P2SKH)
Date: Tue, 17 Mar 2026 11:00:05 -0700 (PDT) [thread overview]
Message-ID: <171b3d0e-e694-4ebc-9eeb-bb1917a9da69n@googlegroups.com> (raw)
In-Reply-To: <967d68e7-ba38-4e28-bc36-bf256a8c85a9n@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 11023 bytes --]
Hi sashabeton,
> Honestly, this idea might have had better timing a few years ago.
No I don't think so; it was discussed at the time (specifically, pubkey
recovery). I remember bringing it up in the taproot review sessions on IRC.
I'm sure others, including the taproot designers, discussed this issue well
before I thought about it :)
Perhaps this clarifies it for other mailing list readers:
BIP340 Schnorr signatures are the form of Schnorr signature which has what
is commonly termed "pubkey prefixing"; the challenge hash is e = H(R, P, m)
with P the public key. This makes a pubkey recovery algorithm of the type
that we have in our legacy ECDSA signatures, impossible. It's a point of
not-only-historical interest that the original Schnorr signature design was
H(R, m) not H(R, P, m) and that even around the time when ECDSA was being
designed to avoid the Schnorr patent, and later, it was a point of
considerable contention amongst various system designers, whether pubkey
prefixing was needed or not.
Pubkey prefixing makes all of the security reductions much more meaningful,
since it can make the concept of "resistant to forgery" much more
wide-ranging and powerful (in short, imagine the idea that you can make up
a schnorr signature for some arbitrary key that wasn't used before .. this
is sorta kinda true for non-pubkey-prefixed Schnorr). And that has big
implications for perhaps the biggest application of Schnorr in Bitcoin,
which is aggregation; aggregation in a bitcoin context means *aggregating
arbitrary, new, ephemeral keys*, not keys previously recorded in some
certificate registry or whatever. You're not going to get sensible versions
of MuSig without pubkey prefixing, because you couldn't stop adversaries
making up malicious keys that they don't have to commit to.
Without that kind of aggregation scheme (and see e.g. DahLIAS and CISA, if
you don't actually care about multisig for whatever reason; it could end up
being very important for Bitcoin scaling anyway), Schnorr is a lot less of
an upgrade to our signing algorithm (though to be fair, still not nothing,
it's on sounder theoretical foundations).
Cheers,
AdamISZ/waxwing
On Tuesday, March 17, 2026 at 6:32:12 AM UTC-3 sashabeton wrote:
> Hi everyone,
>
> After reading all the feedback, I think it's time to accept that this
> proposal has no realistic path forward.
>
> For it to make sense, the new address type would need to be adopted by the
> entire ecosystem almost instantly — which is simply not going to happen.
>
> Honestly, this idea might have had better timing a few years ago. Today,
> the landscape has moved on, and I don't think pushing this further would be
> a good use of anyone's time.
>
> I want to thank everyone who took the time to read, review, and respond.
>
> On Tuesday, 17 March 2026 at 08:32:06 UTC+1 Saint Wenhao wrote:
>
>> > 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 <sashabe...@gmail.com> napisał(a):
>>
>>> To clarify the design intent: P2SKH is not a stripped-down Taproot — 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
>>> 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 — 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 — 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 — 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" chose
>>>> whether to use the key-spend path or the script-spend path. Your solution
>>>> 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 comparison
>>>> against Taproot or BIP360. 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 will eventually break.
>>>>
>>>> Do you have any plan on how one could quantum secure the funds in P2SKH?
>>>> måndag 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åndag 16 mars 2026 kl. 12:25:57 UTC+1 skrev Martin Habovštiak:
>>>>>
>>>>>> Taproot specifically did not do this for good reasons that are well
>>>>>> documented. I recommend you to read documentation first before attempting
>>>>>> to make changes.
>>>>>>
>>>>>> Dňa po 16. 3. 2026, 11:48 sashabeton <sashabe...@gmail.com>
>>>>>> napísal(a):
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I'd like to propose a new native SegWit output type: Pay to Schnorr
>>>>>>> Key Hash (P2SKH).
>>>>>>>
>>>>>>> == The problem ==
>>>>>>>
>>>>>>> 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
>>>>>>> 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 compact witness
>>>>>>> simultaneously.
>>>>>>>
>>>>>>> == The proposal ==
>>>>>>>
>>>>>>> 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: given the signature (R, s) and the
>>>>>>> challenge e = TaggedHash("P2SKH/challenge", R.x || hash160(P.x) || msg),
>>>>>>> the verifier recovers P = 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 — a 22-byte output with a 64-byte witness — while
>>>>>>> keeping the public key off-chain until spending.
>>>>>>>
>>>>>>> == Tradeoffs ==
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> == Open questions ==
>>>>>>>
>>>>>>> 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 — "P2SKH" follows the established pattern but "P2TRKH" has
>>>>>>> been suggested to emphasise Schnorr/taproot lineage. Opinions 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 "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
>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>> --
>>> 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/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/bitcoindev/ee240078-88c6-4961-8412-489a77012038n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
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/171b3d0e-e694-4ebc-9eeb-bb1917a9da69n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 14367 bytes --]
next prev parent reply other threads:[~2026-03-17 18:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-16 8:51 sashabeton
2026-03-16 11:12 ` Martin Habovštiak
2026-03-16 11:43 ` Alex
2026-03-16 14:36 ` sashabeton
2026-03-16 15:57 ` Martin Habovštiak
2026-03-16 15:43 ` Alex
2026-03-16 16:00 ` sashabeton
2026-03-16 16:25 ` Martin Habovštiak
2026-03-24 6:02 ` aaron.recompile
2026-03-16 19:29 ` Alex
2026-03-17 7:23 ` Saint Wenhao
2026-03-17 7:40 ` sashabeton
2026-03-17 18:00 ` waxwing/ AdamISZ [this message]
2026-03-17 18:30 ` waxwing/ AdamISZ
2026-03-18 5:24 ` Saint Wenhao
2026-03-18 15:50 ` "wrapped Taproot" from RIPEMD-160 collisions, Was: " Ethan Heilman
2026-03-16 11:38 ` Saint Wenhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=171b3d0e-e694-4ebc-9eeb-bb1917a9da69n@googlegroups.com \
--to=ekaggata@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox