3 ms·

The article is light on technical detail, but I presume this works by generating a hash value from the page of interest. Then a service such as opentimestamps (

by aazaa 7y ago

The article is light on technical detail, but I presume this works by generating a hash value from the page of interest. Then a service such as opentimestamps (https://opentimestamps.org https://opentimestamps.org) gathers a bunch of these hashes together, publishing the Merkel root as data in an OP_RETURN transaction output. If so, one should be aware of a kinda sneaky attack that might be feasible. Let's say I want to prove my clairvoyance by predicting the winner of the 2020 presidential election. I generate a text file containing the name of my pick. Then I hash the result. Next, I publish the hash value to the block chain using an OP_RETURN output. On November 4, 2020, I publish the transaction ID containing the hash of my predicted winner. I also publish the text file used to generate the hash value. Clearly, I must have known that hash value when the transaction was confirmed, implying that I knew the winner of the election at that time as well. Except I cheated. Instead of making just one transaction, I made two. The second one contained an OP_RETURN output with the hash value of a document containing the name of the opponent. On the day after Election Day, I simply publish the transaction ID I know to contain the winner, and never mention the existence of the other transaction. Depending on how SingleFile works, it may be possible to do a similar attack. Also, you don't exactly get a proof that pinpoints the date. Rather, you get proof that the hash value existed as of the date the Bitcoin transaction gets its first confirmation.

solotronics 7y ago
I don't see this as a real issue because of course this protocol can only prove that a certain website existed as represented at that time. It's impossible to prove something didn't exist anyways. Can you prove I'm not wearing 8 different hats stacked on top of each other right now? No, impossible without a video recording and method of biometric verification both time-stamped showing I wasn't wearing the hats. This only works because there is arguably only one me at a time.
msgilligan 7y ago
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...
maxfan8 7y ago
You can also have more precise time stamps with the Roughtime protocol [1] (Peter Todd has talked about this [2]), although it is easier for the servers in the Roughtime protocol to cooperate and forge time stamps than in Bitcoin. Another way to prevent "double spending"/attacks like these, you can burn Bitcoin with each publishing of the hash, ensuring that it is at least costly for an attacker to preemptively timestamp all of the probability space. Your security analysis looks correct to me. [1]: https://roughtime.googlesource.com/roughtime https://roughtime.googlesource.com/roughtime [2]: https://groups.google.com/a/chromium.org/d/msg/proto-roughtime/jYLxSDKPc4o/AjyUk_BDBAAJ https://groups.google.com/a/chromium.org/d/msg/proto-roughti...
petertodd 7y ago
As the founder of OpenTimestamps I wanted to say you're analysis is absolutely correct. People often don't realize how weak timestamp proofs are - you really need to think carefully about what exactly is being proved by one and take into account the "timestamp all the things" attack. This is particularly true in efficient, scalable, timestamping solutions like OTS where timestamps are essentially free to create: an attacker could write a script to create via brute force literally trillions of alternate variations of a prediction.

by aazaa 7y ago

solotronics 7y ago

I don't see this as a real issue because of course this protocol can only prove that a certain website existed as represented at that time. It's impossible to prove something didn't exist anyways. Can you prove I'm not wearing 8 different hats stacked on top of each other right now? No, impossible without a video recording and method of biometric verification both time-stamped showing I wasn't wearing the hats. This only works because there is arguably only one me at a time.

msgilligan 7y ago

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...

maxfan8 7y ago

You can also have more precise time stamps with the Roughtime protocol [1] (Peter Todd has talked about this [2]), although it is easier for the servers in the Roughtime protocol to cooperate and forge time stamps than in Bitcoin. Another way to prevent "double spending"/attacks like these, you can burn Bitcoin with each publishing of the hash, ensuring that it is at least costly for an attacker to preemptively timestamp all of the probability space. Your security analysis looks correct to me. [1]: https://roughtime.googlesource.com/roughtime https://roughtime.googlesource.com/roughtime [2]: https://groups.google.com/a/chromium.org/d/msg/proto-roughtime/jYLxSDKPc4o/AjyUk_BDBAAJ https://groups.google.com/a/chromium.org/d/msg/proto-roughti...

petertodd 7y ago

As the founder of OpenTimestamps I wanted to say you're analysis is absolutely correct. People often don't realize how weak timestamp proofs are - you really need to think carefully about what exactly is being proved by one and take into account the "timestamp all the things" attack. This is particularly true in efficient, scalable, timestamping solutions like OTS where timestamps are essentially free to create: an attacker could write a script to create via brute force literally trillions of alternate variations of a prediction.