> P2TR uses Schnorr signatures (64-byte witness)

I wonder, what do you think about splitting r-value and s-value on the stack. In this way, grinding the signature could make it smaller, just like it was in DER signatures.

And then, instead of consuming a single signature, you would have r-value and s-value pushed separately. And optionally, the sighash, as the third element, if it is not the default. And then, by simply checking the size of all elements, it would be known, if we have two stack pushes, or three.

Also, if r-value would be handled alone, then it would introduce OP_CHECKSIGFROMSTACK, without any additional opcode, or tricks like OP_CAT. Because then, it could depend on the message being signed.

pon., 16 mar 2026 o 11:48 sashabeton <sashabeton2007@gmail.com> napisał(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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3dcadd5d-702a-4e6c-ad6c-2ddfe68ec73en%40googlegroups.com.