1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
---
title: "Future-Proof Digital Timestamping"
date: 2021-11-13T00:00:00
draft: false
---
# Synthetic Media
The internet will soon face a huge problem. AI-generated media, aka synthetic media, is becoming harder to distinguish from human-generated media. Synthetic articles shared on social media have topped the charts with readers entirely unaware what they're reading is synthetic. The amount of synthetic media posted online keeps increasing every year. Even big tech platforms and DARPA have ramped up their deepfake detection efforts.
What will be the outcome of this? Well it will definitely be a cat-and-mouse game for a while. Big tech and governments will spend millions to detect fakes. But they're only delaying the inevitable. Any deepfake detection scheme can be used to train a better AI to fool it. It will eventually be practically impossible to detect fakes. It's only a matter of time.
For online content that isn't widely witnessed, like my online journal, it'll be impossible for future viewers to be sure that a human being created it. Since AI will be able to generate unlimited convincing fake media, that will diminish the value of any media that can't be verified as human in origin.
So I decided I wanted to give future readers and internet historians a way to verify definitively that this journal was written by a human. That way it doesn't blend into the background of all the convincing synthetic media that will surely populate the internet soon enough.
# OpenTimestamps
It occurred to me that because today's AI couldn't possibly generate my journal articles, if I timestamped my journal, that would prove to future readers that it's human-made. So I started looking for software that could do that.
I didn't want to use some centralized service to perform the timestamping because of 2 reasons:
* It could go offline.
* It would have to be trusted.
Then I found OpenTimestamps.[1] It's based on Bitcoin, which I don't like. I've encouraged people to avoid using proof-of-waste cryptocurrencies before.[2] I don't feel great about using software that relies on a planet-roasting cryptocurrency, but there's just no other way I know of to create trustless, decentralized, verifiable timestamps.
Also, OpenTimestamps has an extremely efficient design compared to other Bitcoin timestamping schemes. Thanks to OpenTimestamps' clever use of merkle trees[3], it can timestamp unlimited data using only 1 transaction. Other Bitcoin timestamping software uses 1 transaction per timestamp, an extremely wasteful, inefficient design. At least OpenTimestamps isn't that bad.
So anyway, I created a timestamped Git commit and tagged it timestamp-1[4]. I wrote the concatenated commit data of the timestamped commit to a file[5] in case you're interested to see what it looks like. The software works in a very elegant fashion. It even maintains compatibility with non-OpenTimestamps Git clients, so GnuPG can still verify the commit signature.
The base64-encoded timestamp appended to the commit data includes all the necessary hashes to build the merkle path from the tagged commit to the merkle root included in the Bitcoin transaction. Using './ots --git-extract <filename>' on any file in the nicksphere-gmi repo present at the timestamped commit, you can extract an ots proof file which you can then verify with './ots --verify <filename>'.
Thus future readers of my journal and historians will be able to verify that each entry was written by a human with no major external dependency other than the widely witnessed Bitcoin ledger. There are caveats to that, but luckily I thought up ways around all of them.
# Caveats
## SHAttered
If you're familiar with Git's crypto, you know it still uses SHA-1, which is SHAttered.[6] Since OpenTimestamps uses the Git commit data for timestamping commits, it also uses SHA-1. Unless you've enabled experimental SHA-2 support, which no code hosting platforms support, then SHA-1 is the best OpenTimestamps can do for Git repos.
As it turns out, SHA-1 is still good enough for OpenTimestamps.[7] Since there's no preimage attack against SHA-1, OpenTimestamps is unaffected. Meaning the timestamp I created for this journal still has meaning. Nonetheless I'll eventually redo the timestamp when Git supports SHA-2, just to future-proof it.
## Bitcoin Falling Out of Favor
There's actually another problem with OpenTimestamps: It depends on Bitcoin. Bitcoin was the first cryptocurrency. Don't get me wrong, it was great for its time. But by today's standards, it has several severe design flaws:
* Not anonymous - blockchain is transparent.
* Environmentally destructive - uses proof of work.
* The mining is undemocratic - ASICs required.
* Value isn't backed by an asset or service - no smart contracts.
With all these design flaws, Bitcoin should've fallen out of favor years ago. Supposing people come to their senses and it does fall out of favor, it will lose its value. Then miners will quit mining. There will be nothing to secure the blockchain and it will be possible to rewrite blockchain history. Thus the timestamps won't be secure.
Luckily, there's a clever way to preserve the timestamps, even after Bitcoin is no longer secured by miners. It's a technique I call 'timestamp chaining'. The idea is simple. Before the blockchain becomes insecure due to lack of mining, digitally timestamp the whole ledger. Then embed that timestamp inside its successor ledger.
Just as timestamping my journal before AI could've generated it proves it was written by a human, timestamping the Bitcoin blockchain before it becomes insecure proves which blocks were really included. If Bitcoin's successor falls out of favor, the process can simply be repeated. This creates a secure chain of timestamps from the most recent distributed ledger all the way back to the timestamp embedded in today's Bitcoin ledger.
All this assumes distributed ledgers stick around. If there's any gap in the timestamp chain where there's no distributed ledger to put the latest timestamp in, then the entire chain is invalidated. This would be bad because Bitcoin timestamps are used to carbon date much of the internet (archive.org)[8]. The timestamps will be extremely useful to future internet historians.
In order to verify the timestamp chain, you need to know roughly around what time each ledger in the chain stopped being secure. That way you can check that it was timestamped before that date. As long as you stick to widely witnessed ledgers, this shouldn't pose a problem. This whole process can be automated. But it's not yet necessary as Bitcoin still hasn't fallen from grace.
## Quantum Computing
But what about quantum computers? Won't they invalidate the timestamps? No. Timestamp chaining is also quantum-secure, given quantum-resistant ledgers are in use before quantum computing becomes practical. Research on quantum-resistant distributed ledgers has been underway for years[9], so I estimate a very high probability it will be ready.
It doesn't even matter if all the underlying cryptographic primitives of the ledgers in the timestamp chain are broken by quantum computers. As long as the most recent ledger used in the timestamp chain is quantum-secure and there are no gaps in the timestamp chain, timestamps going all the way back to Bitcoin will be verifiable. SHA-256 is the only primitive relied upon for timestamping and it's thought to be quantum-secure already.
# Conclusion
This journal's timestamp is not yet future-proof because it still uses SHA-1. When Git supports SHA-2, I plan on creating a new timestamp. I don't think SHA-2 preimage resistance will be broken any time soon and I think distributed ledgers will still be popular for years to come. So if you want to create a trustless, future-proof, unforgeable digital timestamp, timestamp chaining seems like the way to go.
Future internet historians will have many methods of verifying when some digital media was created. They probably won't be limited to verifying timestamp chains. While timestamps offer the strongest assurance that media isn't synthetic, it's not like your digital work will necessarily be indistiguishable from synthetic media just because you didn't timestamp it.
I just decided to timestamp my journal to create that extra assurance that it's not synthetic. That was the primary reason. The synthetic internet might arrive in 10 years or 50 years. Since I have no way to know, it seemed best to create a verifiable timestamp now, before GPT-4 gets released.
Link(s):
[1: OpenTimestamps](https://opentimestamps.org/)
[2: Avoid Using Cryptocurrency](../../../../2021/07/18/avoid-using-cryptocurrency/)
[3: OpenTimestamps Merkle Trees](https://petertodd.org/2016/opentimestamps-announcement#merkle-trees)
[4: Timestamp Tag](https://git.nicksphere.ch/nicksphere-gmi/tag/?h=timestamp-1)
[5: Timestamp Commit Data](../../../../resource/timestamp-1.txt)
[6: SHAttered](https://shattered.io/)
[7: SHA1 Is Broken, But It's Still Good Enough for OpenTimestamps](https://petertodd.org/2017/sha1-and-opentimestamps-proofs)
[8: How OpenTimestamps 'Carbon Dated' (almost) The Entire Internet With One Bitcoin Transaction](https://petertodd.org/2017/carbon-dating-the-internet-archive-with-opentimestamps)
[9: Post-Quantum Monero](https://github.com/insight-decentralized-consensus-lab/post-quantum-monero)
|
