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

In a recent discussion on the Bitcoin Development Mailing List, a detailed analysis of different cryptographic designs was presented, which helped clarify some confusions arising from previous descriptions by Tim and Adam. The conversation brought to light the importance of domain separation in hashing functions within these cryptographic schemes. Specifically, the use of a single hash function (denoted as h) for both hashing a public key alone and in combination with a transaction ID (txid) was scrutinized. The critique pointed out a potential flaw in using the same hash function for both purposes due to the risk of length extension attacks. Such attacks could theoretically allow an attacker to generate a hash of the public key and a modified transaction ID without needing to know the actual public key.

To mitigate this vulnerability, it was suggested that a different hash function or at least a variation (referred to as h2) should be employed for the sake of security. This could involve either using a completely different hash function or altering the prefix used in the hashing process. Another recommendation was to reverse the order in which the transaction ID and public key are hashed together (i.e., h(txid, pubkey)) as a precautionary measure. The discussion emphasized that choosing hash functions resistant to length extension attacks is crucial, especially within the context of Bitcoin's security framework. This exchange underscores the ongoing efforts by developers to identify and address potential security weaknesses in cryptographic designs used in blockchain technology.