P2QRH / BIP-360 Update

The discussion begins with an analysis of the feasibility of including arbitrary data within the hashes used to resolve a Merkle tree, particularly in the context of Bitcoin's multisignature schemes. The complexity and impracticality of generating a hash collision through elliptic curve public key generation are highlighted. This process would require an excessive amount of computation for relatively little payoff—specifically, the insertion of 352 bytes of arbitrary data by exploiting the deepest key in a 1/1024 multisig setup. The necessity for both a valid public key and signature pair further complicates this approach, rendering it impractical.

There's an acknowledgment of the security provided by a 256-bit hash, which is deemed sufficient despite opinions that such a level of security might be excessive. However, concerns are raised regarding the potential misuse of unopened public key commitments for arbitrary data storage, even after addressing selective disclosure vulnerabilities. This misuse could occur within the structure of Bitcoin Improvement Proposals (BIPs), specifically when committing to multisig semantics in outputs. An example is provided where arbitrary data is stored by manipulating leaf hashes within a Merkle tree, illustrating a method to bypass intended security mechanisms.

Further discussion points to the inherent risks associated with breaking the collision resistance of hash functions used in the Merkle tree, a crucial element for the security of Bitcoin transactions. A referenced Bitcoin Stack Exchange answer elaborates on a similar attack vector in the context of Pay to Script Hash (P2SH) versus Pay to Witness Script Hash (P2WSH), suggesting that these risks could be mitigated by employing hash functions with larger output spaces, such as SHA-512. However, this is not proposed as the solution. Instead, the focus shifts to the actual level of security achieved by the BIP’s proposed signature scheme, arguing that despite aiming for 256 bits of security through NIST strength level V parameters, the real-world applicability falls short, especially when adversaries can influence any part of the multisignature setup. The reliance of the Bitcoin protocol on the collision-resistance of SHA-256, defined as NIST strength level II, underscores the ongoing challenges in ensuring cryptographic security against evolving threats, as detailed on the NIST Post-Quantum Cryptography Standardization page.