Public key recovery for EC leaves in P2MR (BIP-360)

This technique aims to reduce the witness size associated with EC spends, thereby improving blockchain efficiency without increasing vulnerability to quantum attacks. By introducing a recoverable EC leaf, it becomes possible to eliminate the need to include the EC public key script in the witness. Instead, the public key is derived directly from the signature using a modified Schnorr verification equation. This change allows witness sizes to approach or even slightly improve upon those seen in Pay-to-Witness-Public-Key-Hash (P2WPKH) transactions.

In traditional P2MR structures, omitting the EC public key script would typically inflate the witness size. The optimized method circumvents this by deducing the public key from the signature itself and confirming its validity through a hash comparison with the P2MR Merkle root. The signature challenge references the root hash rather than the public key, mitigating certain cryptographic vulnerabilities like related-key attacks. This approach ensures that the recovered public key aligns with the intended leaf in the Merkle tree, thereby preserving structural integrity and security. To support this change, modifications are required in the parsing and validation logic for witnesses, as the new recoverable EC leaf does not contain a conventional script. Consequently, the witness structure is simplified, comprising essential elements such as the signature and a control block that specifies the leaf version and its position within the tree.

Evaluating the security implications of this scheme reveals notable strengths and trade-offs. Binding the signature challenge to the root + Merkle branch instead of the public key maintains compatibility with BIP340 standards and preserves their security properties. For more complex protocols like MuSig2, however, further security checks would be necessary. Incorporating the Merkle path into the challenge can thwart specific malleation attacks, particularly those involving duplicate public keys across different leaves. Nevertheless, this strategy sacrifices batch validation—a vital feature in BIP 340-342—highlighting a fundamental trade-off between enhanced individual spend efficiency and broader protocol-level optimizations.

Data encoding requirements and transaction efficiency are also carefully considered. When comparing this optimization with Pay-to-Taproot (P2TR) and the standard P2MR configuration, it becomes evident that the proposed method offers a balanced compromise between data size and privacy. Notably, the public key remains undisclosed until essential during key path spending. In practical terms, for a two-leaf output, P2TR requires 64 bytes for a key spend, while P2MR doubles this to 128 bytes. The optimized scheme reduces the key spend requirement to 96 bytes, offsetting some of the 'happy-path' benefits of P2TR, even though batch validation and the simplicity of the signature scheme are compromised.

A critical aspect of the analysis pertains to cryptographic vulnerabilities inherent in tree structures where related EC keys appear in separate leaves. If an adversary knows both the keys and the tweak, they could forge a signature for one key by transforming a legitimate signature from the other, exploiting the fact that the signature challenge does not commit to the control block. This oversight enables the reuse of the challenge across fraudulent contexts, emphasizing the necessity of committing to the complete path in the hash computation to prevent such attacks.

Further exploration delves into the use of hardened EC keys within P2MR constructions. The importance of hardening lies in preventing derivation from extended public keys (xpubs), which, if exposed to quantum-capable attackers, could compromise the security model. Even when xpub-derived keys are used, confidentiality must extend to chaincodes, aligning the security model with that of hardened keys. Avoiding key reuse is strongly recommended to maintain robust security.

Expanding on potential improvements, the use of the public key hash instead of the raw key in the Schnorr challenge is suggested. This adaptation could enhance pubkey recovery not only in P2MR but also in taproot script paths, contingent upon future upgrades such as a new leaf version. While this modification may impact batch validation and computational overhead, it introduces flexibility in balancing CPU and bandwidth usage, especially for nodes not operating in blocksonly mode.

Operational challenges arise when considering migration from BIP32 to new standards compatible with schemes like SHRINCS. Such migration disrupts established wallet paradigms, imposing complexity that may impede user adoption. Retaining BIP39 seeds while adopting a new derivation standard that supports modern cryptography could help ease the transition, preserving familiar workflows while enhancing security. The shift towards storing only public key hashes on-chain represents a significant evolution in privacy and post-quantum security, albeit requiring meticulous safeguards against related-key attacks.

The dialogue also addresses concerns about the pervasive reliance on xpub and public key sharing within the ecosystem, underpinning critical features such as multisig wallets, escrow services, and indexing. These dependencies expose systemic vulnerabilities in a quantum era