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 = P + H(P || merkle_root)·G (as in BIP341) scriptPubKey = OP_2 then the Taproot commitment structure is preserved — 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 AM Martin Habovštiak < 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 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ňa po 16. 3. 2026, 17:12 sashabeton > napísal(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 >>>>> 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 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 >>>>>> >>>>>> . >>>>>> >>>>> -- >> 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-489a77012038n%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 > > . > -- 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/CAEmKuUFxMi4NUMGrJTc-kMEJ0roS%2BrRP_OwyyNvaoFUP1vEzMA%40mail.gmail.com.