This analysis is correct and it looks like SingleFile doesn't provide protection from this class of attack. However, there are solutions that can protect again

This analysis is correct and it looks like SingleFile doesn't provide protection from this class of attack. However, there are solutions that can protect against this type of attack. The attack you describe above is similar to what is known as a "double-spend" attack. Using a digital signature you can prove that a particular key (and therefore user) signed a particular transaction, but cryptography alone cannot prove that there was not another competing transaction that spends the same funds. Prior to Bitcoin, digital currencies required a central database to prevent these double-spends. With Bitcoin and subsequent cryptocurrencies this attack is prevented via a distributed database with a consensus algorithm. Peter Todd (and others) have generalized prevention of double-spends to the idea of a "single-use seal" which can be implemented using the Bitcoin blockchain as an implementing decentralized service. [1] The idea is that there is some kind of formal protocol used (a higher layer in the protocol stack) and in the example above, the political prognosticator ties the hash of their single prediction of the winner of the presidential election to a particular Bitcoin UTXO (unspent transaction output) which serves a "single-use seal". The combination of the higher-layer messaging protocol and the "lock" to a single commitment tied to the UTXO limits the prognosticator to a single prediction. They don't have to reveal their prediction at the time it is made, but they do have to publicly (or privately) commit via a higher-level protocol to the single prediction. [1] https://petertodd.org/2016/commitments-and-single-use-seals https://petertodd.org/2016/commitments-and-single-use-seals Update: For the content hash of the (SingleFile) web page, you could have a sequence of these single-use seals each creating a new, linked transaction (UTXO) every time the website content is changed. This would allow users to verify the current content or what the content was at a particular time in history. As long as the root of this chain was somehow published (uniquely) at some start time in the past (in OpenSeals Terminology [2] this is called a "Root Proof". [2] https://github.com/rgb-org/spec/blob/develop/01-OpenSeals.md#definitions https://github.com/rgb-org/spec/blob/develop/01-OpenSeals.md...