Takes ton of engineering effort just to undermine the privacy benefits of Taproot we've all been fighting for. Not worth it in my view. If you want to optimize transaction cost, focus on CISA instead. It has much greater potential than to save 12B per key. Just having two inputs in transaction already saves 64B. Dňa po 16. 3. 2026, 16:45 sashabeton napísal(a): > On scriptability and OP-code upgradeability: P2SKH is explicitly a > single-key output type, the same as P2TR key-path spending. If you need > Tapscript or OP-code upgradeability, you use P2TR. P2SKH targets the same > use case as P2WPKH today: simple, high-volume payments where you have one > key and no script conditions. 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. > On quantum security: the broader quantum-resistance question is > legitimate, but it applies equally to all of Bitcoin's current output > types. A proper solution requires a post-quantum signature scheme — a new > cryptographic assumption. Until such a scheme is designed, reviewed, and > adopted by the network (a multi-year process), there is value in keeping > the 20-byte hashed address format that wallets and users already know, > while gaining Schnorr efficiency. P2SKH offers exactly that bridge, without > waiting for a problem the entire ecosystem has yet to solve. > On Monday, 16 March 2026 at 12:57:52 UTC+1 Alex wrote: > >> 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/9e030d1e-0eab-4463-948e-ef3ec3c43b1bn%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/CALkkCJZ0UgVGZ%3Du_Uq24E5L80KyEoysRS7ExphyajFe3oURcyw%40mail.gmail.com.