Bitcoin Proposes P2SKH: Compact Schnorr Signatures with Key Recovery

A new Bitcoin Improvement Proposal submitted on March 15, 2026 introduces Pay to Schnorr Key Hash (P2SKH), an output type that aims to solve a fundamental trade-off in Bitcoin’s current address formats: size versus efficiency.

The proposal, submitted as BIP PR #2123 by developer sashabeton, uses a cryptographic technique called key recovery to enable smaller outputs without sacrificing Schnorr signature benefits. If activated, P2SKH could save 12 bytes per output compared to Taproot, reducing both transaction fees and the UTXO set size that every full node must maintain.

The output type trade-off

Bitcoin’s evolution has always involved choosing what to optimize:

P2WPKH (SegWit v0, introduced 2017):

• 22-byte output script (compact)
• ~108-byte witness with ECDSA signatures (less efficient)
• Addresses starting with bc1q

P2TR (Taproot, activated 2021):

• 34-byte output script (exposes public key)
• 64-byte witness with Schnorr signatures (efficient)
• Addresses starting with bc1p

P2SKH attempts to combine the best of both: the compact 22-byte output of P2WPKH with the efficient 64-byte Schnorr signature of P2TR.

How key recovery works

The innovation that makes this possible is key recovery, a technique that allows reconstructing the signer’s public key directly from the signature itself.

In standard Taproot verification, the public key is stored in the output script (34 bytes) and used to verify the signature. P2SKH instead stores only a 20-byte hash commitment to the public key, then uses mathematical properties of Schnorr signatures to reconstruct the key during verification.

The verification process:

1. Parse the signature components (R, s)
2. Reconstruct the public key: P = e⁻¹ · (s·G − R) (requires modular inversion)
3. Verify the reconstructed key matches the hash commitment: hash160(P.x) == h

This is similar to how Ethereum derives sender addresses from transaction signatures using its ecrecover function. However, P2SKH would be the first time Bitcoin uses key recovery in consensus validation.

Size savings and network impact

The 12-byte scriptPubKey reduction may seem modest, but at scale it adds up:

Per-transaction savings: A typical 2-input, 2-output transaction would save approximately 24 bytes in the base transaction (2 outputs × 12 bytes) plus witness weight reductions, totaling around 12 virtual bytes.

Network-wide impact: According to mempool.space’s UTXO Set Report from July 2025, P2TR outputs comprised 72.86% of new UTXOs (37.3 million outputs). If these were P2SKH instead, the UTXO set would be approximately 448 MB smaller. Every full node maintains this set in memory.

Fee savings: At 100 sat/vB, a 12 vbyte reduction saves 1,200 sats per transaction (roughly $0.60 at $50k BTC). During the 2023-2024 Ordinals-driven fee spikes that reached 500+ sat/vB, the same transaction would have saved $3.

The witness version conflict

P2SKH claims witness version 2 (producing addresses starting with bc1z), but this version is already assigned to BIP360 (Pay-to-Merkle-Root), a quantum-resistant output type that received its BIP number in December 2024.

The BIP PR acknowledges this conflict, noting that if both proposals advance, one must cede its version number. BIP360 has priority by earlier assignment, so P2SKH would likely move to witness version 3 (bc1x addresses) or higher.

Trade-offs and concerns

Computational cost: Key recovery requires a modular inversion operation, adding an estimated 10-20% to verification time compared to direct Schnorr verification. This overhead occurs every time a P2SKH output is spent.

Hash security margin: P2SKH uses hash160 (RIPEMD160(SHA256(·))), providing 80-bit second-preimage resistance. While Bitcoin has relied on this hash function since 2009 without incident, some developers prefer 256-bit hashes for new protocols, especially for outputs that may exist for decades.

Protocol complexity: Every new output type increases Bitcoin’s complexity and testing surface. Wallets must support multiple standards, and nodes must implement additional validation logic.

Adoption friction: Even if the proposal is technically sound, activation requires a soft fork and ecosystem-wide coordination. Exchanges, wallets, and payment processors would all need to add support.

Process and status

After submitting the BIP and implementation PRs directly to GitHub, the author received immediate feedback from Bitcoin Core maintainer Luke-jr about following the proper BIP process: discussion on the Bitcoin development mailing list should precede formal BIP submission.

The author acknowledged this and closed both PRs, indicating they will submit to the mailing list first as a reference for community review. As of March 16, 2026, no mailing list post has appeared.

Both the BIP draft and proof-of-concept implementation remain available for technical review, but no timeline exists for potential activation.

What this means

P2SKH represents an incremental efficiency improvement rather than a fundamental protocol upgrade. The proposal demonstrates:

• Continued innovation in Bitcoin’s UTXO model
• A willingness to borrow proven cryptographic techniques from other systems (Ethereum’s key recovery)
• Ongoing tension between different optimization goals (efficiency vs. quantum resistance vs. simplicity)

Whether the Bitcoin community values 12 bytes of savings enough to justify the added complexity remains an open question. The answer will likely depend on sustained high-fee environments, the resolution of the witness version conflict, and developer appetite for marginal optimizations versus higher-impact features like covenants or scaling improvements.

For now, users should continue using P2TR or P2WPKH. P2SKH, if it activates at all, is years away.

Sources

GitHub BIP Pull Request #2123, Bitcoin Core Implementation PR #34826, BIP360 Specification, Bitcoin Optech Transaction Size Calculator, Bitcoin Optech: Schnorr Signatures, mempool.space UTXO Set Report. Data/status as of March 16, 2026.