Posted by Jonas Nick
Feb 24, 2025/13:17 UTC
The discussion centers around a potential vulnerability within the Bitcoin Improvement Proposal (BIP) concerning selective disclosure and attestation mechanisms. A key concern is that the current design, which allows for the exclusion of unnecessary public keys by including their hash along with an empty signature in the attestation, could be exploited for arbitrary data storage. This exploitation is made possible through the manipulation of the multisig policy and the structure of the Merkle tree used in transaction verification. Specifically, by setting one leaf of the Merkle tree to arbitrary data and another to the hash of a public key, attackers could potentially post arbitrary data to the blockchain without proper validation, as long as these transactions adhere to the attestation structure required by the protocol.
Further exploration into this issue reveals that breaking the collision resistance of the hash function utilized in the Merkle tree could allow adversaries to engage in more severe attacks, such as coin theft. The cited attack scenario illustrates a broader vulnerability within the BIP's proposed signature scheme, where the construction of the Merkle tree from public keys followed by the application of an ordinary signature scheme does not achieve the intended 256 bits of security. This discrepancy arises because the scheme does not account for scenarios where an adversary can influence any of the leaves, as is the case with multisignatures.
To mitigate such vulnerabilities, it is suggested that utilizing a hash function with a larger output space, such as SHA-512, could offer a solution. However, this suggestion comes with the caveat that merely increasing the hash function's output space might not fully address the underlying security concerns. The original intention behind the BIP was to achieve a certain level of security (NIST strength level V), but due to the outlined vulnerabilities, particularly when adversaries can manipulate certain elements within the transaction process, this level of security is effectively reduced to NIST strength level II, as evidenced by the Bitcoin protocol's reliance on SHA-256's collision resistance. This analysis is part of an ongoing discussion within the Bitcoin Development Mailing List, as indicated by the reference to further details available on Bitcoin Stack Exchange.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback