Post-Quantum commit / reveal Fawkescoin variant as a soft fork

In a recent discussion on the Bitcoin Development Mailing List, an interesting point was raised regarding the future integration of QR signing algorithms into a new segwit version that might resemble Taproot's structure. This new addition aims to address keypath spending in a manner that secures funds against potential post-quantum threats. It was suggested that alongside this, an opcode for QR signing could be introduced to tapscript. However, there's an emphasis on ensuring that such an address type can manage EC opcodes if they continue to be part of tapscript. The complexity of developing this hypothetical address type was acknowledged, suggesting that its deployment would need careful consideration before or alongside the proposed scheme.

A significant concern highlighted was the necessity of preventing anyone from replicating a user's commitment. An identified potential attack involved creating a Merkle tree over an original Merkle root, which could allow an attacker to embed the legitimate tree as a subtree and produce a malicious proof by learning the EC pubkey and the path from the pubkey to the root. This scenario underscores the importance of retaining properties in future taproot-like addresses that prevent such extensions—specifically, the use of a tagged hash function (h_tapTweak) that hashes the internal pubkey and Merkle root together to produce the final public key, a feature of current Taproot that helps mitigate this vulnerability.

Furthermore, the discussion ventured into hardening the security assumptions of the scheme. By considering a hypothetical situation where an attacker knows which EC address corresponds with a specific QR output from the start, it challenges the scheme to prove its resilience under these conditions. The goal is to ensure that even with complete knowledge, an attacker cannot succeed, thereby establishing security even under less favorable conditions for the attacker.

The conversation also touched upon the comparison between Pedersen commitments and the proposed scheme regarding their hiding properties. While Pedersen commitments offer perfect hiding, making the committed value statistically independent of the commitment itself, the proposed scheme relies on hash-based hiding, which is only computationally secure. This distinction is crucial in the context of quantum computing advancements, as hash function resistance to quantum attacks is uncertain. Despite Pedersen commitments' stronger hiding property, their binding property is vulnerable to quantum attacks due to reliance on the discrete logarithm problem, making them unsuitable for this scheme during the reveal phase.

This exchange of ideas on the mailing list reflects deep engagement with the technical challenges of enhancing Bitcoin's security in anticipation of quantum computing developments. The participants are keenly aware of the need to balance innovation with the imperative of safeguarding against both known and speculative future vulnerabilities.