[BIP proposal] Pay to Schnorr Key Hash (P2SKH)

The proposed P2SKH, suggested by Saint Wenhao, combines a 22-byte scriptPubKey similar to P2WPKH with a 64-byte witness using Schnorr signatures, aiming to achieve a smaller footprint without exposing the public key until spending. This approach contrasts with current methods that either do not minimize both the output and witness sizes simultaneously or expose the public key in unspent outputs.

Concerns and suggestions were raised about the proposal's implications for scriptability, upgradeability, and quantum security. Alex pointed out that P2SKH sacrifices scriptability and OP-code upgradeability for compactness, which aligns with its target use case of simple, high-volume payments similar to P2WPKH but does not account for future quantum security needs. Martin Habovštiak discussed the possibility of splitting the signature into r-value and s-value on the stack to potentially reduce the signature size further, a method reminiscent of DER signatures but applicable within the new framework.

Saint Wenhao responded to critiques by emphasizing that P2SKH is an evolution of P2WPKH, substituting ECDSA with Schnorr signatures for efficiency, without tackling quantum resistance, a challenge that extends beyond this proposal to all of Bitcoin’s current output types. Meanwhile, sashabeton introduced a discussion on DER signature grinding as an alternative for efficiency, suggesting that traditional methods might still offer competitive advantages in terms of signature size reduction over time due to advances in computing power.

The conversation also delved into the technical intricacies of Schnorr signatures and their applications within Bitcoin, including considerations related to public key recovery and prefixing, as detailed by AdamISZ/waxwing. This included a correction of misunderstandings regarding the proposal’s compatibility with established Schnorr signature practices, specifically regarding pubkey prefixing.

Ethan Heilman explored the theoretical possibility of exploiting RIPEMD-160 collisions to create "wrapped Taproot" constructions, allowing for different scripts to spend coins from the same address. This speculative discussion highlighted the potential for innovative but computationally intensive solutions to emerge within Bitcoin’s scripting and addressing mechanisms, albeit with significant practical challenges, including the astronomical storage requirements for such operations.

Overall, the dialogue captures a snapshot of ongoing efforts to refine Bitcoin’s infrastructure, balancing efficiency, functionality, and future-proofing against the backdrop of evolving cryptographic standards and computational capabilities.