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

The discussion revolves around the cryptographic implications of substituting the public key with a root + Merkle branch in the challenge, particularly in the context of BIP340 and related script signatures. This approach seems feasible and retains the security properties of the mentioned standards; however, for more intricate systems like MuSig2, additional security verifications would be necessary. The inclusion of the Merkle path in the challenge, while not essential, could prevent certain types of malleation attacks, such as those involving a tree with duplicate public keys across different leaves. Nonetheless, this method relinquishes the capability for batch validation, a pivotal component in the design of BIP 340-342.

The potential trade-offs of this new scheme were also quantified in terms of data encoding and efficiency. Compared to the existing Pay-to-Taproot (P2TR) and proposed Pay-to-Merkle-root (P2MR) schemes, this new configuration offers a balanced compromise between data size and privacy. Specifically, it enables non-disclosure of the public key until necessary during the key path spend phase. For a hypothetical two-leaf output scenario, the data requirements are outlined succinctly: P2TR requires 64 bytes for a key spend and an additional 32 bytes plus script and inputs for a script spend; P2MR doubles the requirement for a key spend to 128 bytes, maintaining the same cost for script spends; the new scheme demands 96 bytes for a key spend while keeping the script spend costs unchanged. Thus, this approach manages to recover half of the 'happy-path' benefits of P2TR, though it sacrifices batch validation and straightforward usage of the signature scheme.