Episode 16: Open Timestamps
Ep. 16

Episode 16: Open Timestamps

•

Episode description

In this episode of The Van Wirdum Sjorsnado, Aaron and Sjors discuss Open Timestamps, a Bitcoin-based time stamping project by applied cryptography consultant and former Bitcoin Core contributor Peter Todd. Open Timestamps leverages the security of the Bitcoin blockchain to timestamp any type of data, allowing for irrefutable proof that that data existed at a particular point in time.

Chapters

00:00:00 OpenTimestamps and proof of prior existence
00:03:27 Document hashes and SHA256
00:05:54 Merkle trees and compact blockchain commitments
00:08:45 Calendar servers and collecting timestamp proofs
00:14:06 Verifying proofs with a Bitcoin node
00:15:42 Email signatures and timestamped signing keys
00:18:36 What timestamps cannot prove
00:23:18 Git history, the Genesis block and fraud limits
00:27:15 Haber, Stornetta and the roots of Bitcoin timestamping

Support the Show!
Follow Bitcoin Magazine on Twitter @BitcoinMagazine
Follow Aaron van Wirdum @AaronvanW
Follow Sjors Provoost @provoost

Music:
Song Title: Segwit Sounds
By: The NakamoTones
Album: Citadel Music
Produced by: Bitcoin Audio

Transcript

Download transcript (.vtt)
0:07

Aaron van Wirdum Live from Utrecht, this is the Van Wirdum Sjorsnado.

0:10

Sjors Provoost Hello.

0:11

Aaron van Wirdum Hey, Sjors.

0:11

Sjors Provoost What's up?

0:12

Aaron van Wirdum Sjors, today we are going to discuss at length, in depth, the American political situation.

0:19

Sjors Provoost That's right. We're going to explain everything and we're going to just tell you who to vote for, even though this will be released after the election.

0:26

Aaron van Wirdum This is our election special that's going to be published three days after the election.

0:32

Sjors Provoost Exactly.

0:33

Aaron van Wirdum There was something in the news this week, which is mildly, slightly relevant to Bitcoin. And we thought it would be fun to dedicate an episode to it.

0:43

Sjors Provoost Yep, exactly.

0:44

Aaron van Wirdum We're not actually going to discuss the politics of the situation, I think.

0:48

Sjors Provoost I believe the listeners understand that.

0:50

Aaron van Wirdum What we're going to discuss is Open Timestamps.

0:53

Sjors Provoost Yes.

0:53

Aaron van Wirdum Right? And we'll get to the reason why it's relevant later. Or do you want to get into that now?

0:58

Sjors Provoost Well, we can say that something was timestamped.

1:00

Aaron van Wirdum Okay.

1:00

Sjors Provoost That was, you know, at least... mentioned in the news

1:03

Aaron van Wirdum yeah yeah so it's these emails by Hunter Biden or he received emails that's actually the story yeah through time stamps we can be sure that these emails were in fact sent a couple years ago and they were signed with Google's

1:21

Sjors Provoost Exactly.

1:21

Aaron van Wirdum Keys.

1:22

Sjors Provoost Yeah, they were sent between two Gmail addresses and Google signs email. So we know that Google signed that email and if they don't lie about the timestamps, which I don't think Google does, we know those emails are real. What they mean is a different question, but we know they're real.

1:36

Aaron van Wirdum Yes, and thanks to Open Timestamps, we know that the emails were really sent.

1:40

Sjors Provoost Actually, thanks to Open Timestamps, we know less than that. But we can get into that.

1:45

Aaron van Wirdum Okay, let's get into Open Timestamps then. So Open Timestamps, it's a project by Peter Todd, former Bitcoin Core contributor.

1:52

Sjors Provoost He likes to call himself a former Bitcoin Core contributor.

1:56

Aaron van Wirdum Yes, and Applied Cryptographer Consultant. That's what he calls himself.

2:00

Sjors Provoost Okay.

2:01

Aaron van Wirdum So do you want to explain what it is, Open Timestamps, Sjors?

2:05

Sjors Provoost It's basically a way to prove that a given document exists—existed before a certain time.

2:13

Aaron van Wirdum Yeah, before or at a certain time, I guess.

2:16

Sjors Provoost Yeah, well, if you add one second, then you can make it before.

2:20

Aaron van Wirdum Sure, exactly. Sure, fair enough.

2:21

Sjors Provoost But the idea is you use the Bitcoin blockchain for this because Bitcoin blocks, we know when they were created, roughly, not to the second, but we know roughly when they were created. And so if the Bitcoin blockchain points to a document, and I say points to in quotes, that means that document must have existed before that part of the blockchain was created. And that's kind of what Open Timestamp leverages. Of course, we don't actually put documents in the blockchain. That would be bad. We put timestamps in the documents in the blockchain. And these timestamps are a hash of the document or they are a hash of multiple documents.

2:58

Aaron van Wirdum There are actual documents in the blockchain, aren't there?

3:02

Sjors Provoost That's correct. So that's the worst way you can do this. You can put the actual document in the blockchain and then you can prove that that document existed. you know, very long ago. And some people were doing that back in 2011.

3:16

Aaron van Wirdum Yeah. For example, the Bitcoin white paper, I think, is in the blockchain, right?

3:20

Sjors Provoost It could be.

3:20

Aaron van Wirdum I think so. But anyway, so there's a better way of doing this.

3:24

Sjors Provoost Yes. Because a document can be hashed.

3:27

Aaron van Wirdum Yes. So what's a hash?

3:30

Sjors Provoost Well, a hash...

3:30

Aaron van Wirdum Is that too much for our audience? Do they already understand that you think Sjors?

3:36

Sjors Provoost No, it's good to remind people.

3:37

Aaron van Wirdum Okay, let's get it. What is a hash?

3:39

Sjors Provoost And we can teach them something. So the Dutch word for hash is verhaspeling. Not that anyone would ever use that word. But it is basically a mangled version of it.

3:48

Aaron van Wirdum Why did you mention that?

3:50

Sjors Provoost Because we want to educate our youth.

3:52

Aaron van Wirdum We want to teach them Dutch?

3:53

Sjors Provoost Yes. Verhaspeling.

3:54

Aaron van Wirdum Well, you taught me something. I didn't know that.

3:57

Sjors Provoost Well, yeah, because nobody would use that.

3:59

Aaron van Wirdum Right.

4:00

Sjors Provoost So the idea is that you take any given text and you mangle it in a way that you get just a number. Or, you know, it looks like a bunch of letters, but it's just a big number.

4:11

Aaron van Wirdum Yeah, well, it's a hexadecimal number, right?

4:13

Sjors Provoost Well, a number is a number, but you can write a number as a hexadecimal.

4:17

Aaron van Wirdum Exactly.

4:17

Sjors Provoost So the key there is that if you change one letter in the text, the hash changes. And so a good hash function is something that takes any text and produces a unique number. and does not collide. So you cannot come up with two different texts that produce the same number. Right. Now, that's, of course, impossible to actually prove. But, you know, the Wizards came up with, for example, SHA-256. And so far, it seems to work. And the nice thing is, you know, the Bitcoin blockchain keeps producing blocks. And there's a pretty big incentive to find a duplicate. So if there is a vulnerability in SHA-256 where you could take... you could change the contents of a block and still have the same proof of work. That would be bad, but we'll find out soon enough.

5:03

Aaron van Wirdum Yeah. So I guess the benefits of a hash, I would describe as you can, if you have a hash of a document, and you have the document, then you can prove that the hash of the document is in fact the hash of the document. Because every time you hash the document, the same hash comes out.

5:19

Sjors Provoost That's right.

5:19

Aaron van Wirdum And the other benefit is that a hash is very small compared to the document. Or at least it can be very small. So you can have, I don't know, an entire book, and you produce a hash of it, and you just have one string of numbers.

5:32

Sjors Provoost Exactly.

5:33

Aaron van Wirdum So now you can prove that the book... is the same thing as the hash.

5:38

Sjors Provoost Yeah, and this can be useful for very practical stuff. Like if you have optical character recognition, so you're scanning a book and you want to make sure that the scan is correct, or maybe you have a checksum, which is also a hash.

5:50

Aaron van Wirdum Right, okay, so that's what a hash is.

5:51

Sjors Provoost Yes.

5:52

Aaron van Wirdum Do we cover hashes?

5:53

Sjors Provoost Yeah. I think so.

5:54

Aaron van Wirdum Now, something we discussed last week is a Merkle tree. How about I explain the Merkle tree this time?

6:00

Sjors Provoost Sounds good.

6:01

Aaron van Wirdum And then people can tell us who did the better job. All right. Okay, so we're hashing documents. We just explained how we're hashing documents. Now, let's say we have two documents. Each of them we turn into a hash. So now we have two hashes. Now we take the two hashes and we combine these and turn them into a new hash. So now we have one hash again.

6:24

Sjors Provoost Yeah.

6:26

Aaron van Wirdum Now we have two more documents. We hash these documents as well. We have two hashes. These two hashes we hash again. So now, in total, we still have two hashes. We hash these hashes together. And now, once again, we have one hash.

6:40

Sjors Provoost One hash that represents all these four documents.

6:42

Aaron van Wirdum Yes, one hash that includes all four.

6:44

Sjors Provoost And this looks like a pyramid, but we call it a tree.

6:49

Aaron van Wirdum Yeah, it's a reverse tree.

6:51

Sjors Provoost It's a pyramid.

6:51

Aaron van Wirdum Yeah, you're right. So that's what a Merkle tree is.

6:54

Sjors Provoost So why do we care about Merkle trees?

6:55

Aaron van Wirdum So the nice thing about a Merkle tree is that if you have... one of the documents that's included in the Merkle tree, you should be able to prove that it is in the Merkle tree to someone who only has the Merkle hash, which was the last hash we ended up with.

7:14

Sjors Provoost Exactly. And they also don't need to know every document in the Merkle tree. So you can reveal one document in the Merkle tree.

7:21

Aaron van Wirdum Right.

7:22

Sjors Provoost By, you know, revealing the right hashes. Basically one at every level of the tree.

7:26

Aaron van Wirdum Yes, which is called a Merkle root.

7:28

Sjors Provoost Or Merkle proof.

7:29

Aaron van Wirdum Oh, sorry. Merkle proof. So, yeah. Okay.

7:31

Sjors Provoost Okay. So why do we care about this? Instead of putting a whole document inside the blockchain in the transaction, we can put a hash of a document in a transaction.

7:42

Aaron van Wirdum Right, which is much more compact, much smaller, and therefore requires less block space and less fees.

7:47

Sjors Provoost Exactly.

7:47

Aaron van Wirdum So that's better.

7:48

Sjors Provoost And there's a nice way to do that. This is called OP_RETURN, which we discussed, I believe, in a previous episode. It basically tells the node, like, everything after this you can ignore. You don't have to put this in your UTXO set, which we talked about last episode, takes up RAM. So you write OP_RETURN in the destination of your payment and then it's followed by the hash. And then some other software will have to interpret that.

8:10

Aaron van Wirdum Right.

8:10

Sjors Provoost But it's still a bit inefficient, right? And that's why we're talking about this Merkle tree.

8:14

Aaron van Wirdum Yeah. You don't want to have to create a transaction for each document you want to include in the blockchain because there's a better way. And that's including the Merkle root.

8:24

Sjors Provoost That's right.

8:24

Aaron van Wirdum I'm confused about terms. Can you hear?

8:26

Sjors Provoost So the Merkle root is the top of the tree.

8:28

Aaron van Wirdum Yes.

8:29

Sjors Provoost Or the top of the roots or the bottom of the upside down tree, depending on how you want to look at it. And the Merkle proof is a way to say that this given document actually is part of that tree without having to reveal the entire tree, but just bits of the tree. So how do you use this in practice is the question, because you might just have one document that you want to timestamp, but you don't want to create a transaction for that. But what if people could come together and basically have a whole bunch of documents, maybe once a day or once an hour timestamped? And that is where the calendar server comes out. So this is a super centralized solution, but that doesn't really matter. And we'll explain why that doesn't matter.

9:14

Aaron van Wirdum It's a server ran by Peter Todd in this case, right?

9:17

Sjors Provoost It could be, we don't know, but that's what he says.

9:19

Aaron van Wirdum I trust Peter, don't you?

9:21

Sjors Provoost I trust Peter to run this server. We don't have to.

9:26

Aaron van Wirdum Even better.

9:27

Sjors Provoost Yes. Okay, so what this calendar server does is basically everybody keeps sending documents to it, or actually hashes of documents to it, of course, not the actual document. That would be bad. And the server basically... waits one second and then tells you at the end of that second, if you were the only hash or if there were other people who submitted something in that second, and it gives you a hash back. And you then need to call that server again a while later to say, hey, has this thing been included in the block yet? Because every couple of hours, it will take all these hashes and make a Merkle tree out of that and put that on the blockchain inside a transaction.

10:05

Aaron van Wirdum So what the server is returning to you immediately is a hash of the document itself.

10:10

Sjors Provoost I think the server immediately returns either a timestamp or maybe the hash of every other document it received. No, probably, I guess a timestamp. I haven't looked at the implementation, but the idea is that it groups everybody into seconds. So you never have to wait for more than a second. And then at some point, multiple seconds worth of transactions or multiple seconds worth of documents are put into a single transaction, which is confirmed in a chain. And then the server will actually give you The whole chain of evidence you need to go from the document you submitted to that transaction and the block.

10:45

Aaron van Wirdum Okay, so that last part doesn't happen immediately. That last part telling you where to find it in the tree, that only happens when it's included in a transaction.

10:53

Sjors Provoost Well, it has to, right? And included in a block. Because you don't know what block it's going to be in when you make the transaction. But you don't even know what the transaction is going to look like. because there's more documents coming in, so the hash keeps changing. The hash that goes into the transaction keeps changing as new documents go to this calendar server. But eventually, at some point, everything it's got so far goes into a transaction, it gets confirmed, and now it has that proof. So this is where you temporarily have to trust it. But you can see if it's not doing what it's supposed to do. It could just decide to throw away your document. and never include it. But once it has done that, you don't need it anymore because you get all the evidence yourself and you can keep it. And if they somehow censor you, then you just run your own server.

11:42

Aaron van Wirdum Okay, so if I understand correctly, everyone's sending in documents they want to have hashed or do they send in the hashes themselves?

11:49

Sjors Provoost They send in the hashes.

11:50

Aaron van Wirdum Okay, so everyone sends in hashes of documents they want to have timestamped. Once a second, Peter Todd returns or, well, the... calendar server whoever operates it returns either a hash of the document if there was only one document that second well no in that case what do you get back because you're already sending in a hash

12:10

Sjors Provoost I guess it'll just give you the hash back. I haven't read the exact code, but this is probably how it roughly works.

12:16

Aaron van Wirdum Yeah, it's a bit of an implementation detail anyway. So you send in the hash of the document you want to have timestamped. Once a second, a hash is returned, which is either then, I guess, that hash, or if multiple people send in documents or if there were multiple hashes of documents sent in in the same second, then a Merkle root is returned plus a Merkle path which lets you find your hash in the tree. It's like a miniature tree for once a second. Every second, there's like a miniature tree.

12:51

Sjors Provoost And this just prevents you from flooding the server with millions of hashes and it having to hold on to that for years. Now, whatever you throw at it in one second, it can forget after one second.

13:02

Aaron van Wirdum Right. Now, all of these miniature trees, to call them that, these are all sort of accumulated. entered into a new Merkle tree, and the Merkle root of that tree is once a while included in a Bitcoin transaction. Right. At that point, all of the documents are basically timestamped in the Bitcoin blockchain.

13:22

Sjors Provoost Yes, but you still don't have the proof.

13:24

Aaron van Wirdum Yes, and that proof is also sent to you by the server.

13:27

Sjors Provoost No, no, no. The server, you know, it's not don't call us, we call you. It's the opposite.

13:31

Aaron van Wirdum Oh, it is?

13:32

Sjors Provoost You have to call the server.

13:33

Aaron van Wirdum Okay. So you basically...

13:35

Sjors Provoost Every now and then, I think there's a way that you can just wait for it if you have a patient computer, but you can also pull it later and say, hey, do you have the full proof for me now? And at that point, it will give you everything you need.

13:47

Aaron van Wirdum Right, okay.

13:48

Sjors Provoost So which to go back is basically you started your document that you gave, the hash, and then the whatever hashes of all the documents in that one second, and then whatever transaction it comes in, and then where that is in the block.

14:04

Aaron van Wirdum Right.

14:05

Sjors Provoost That's pretty much the proof.

14:06

Aaron van Wirdum All right. So now we've included a document or the hash of a document in the Bitcoin blockchain through this Merkle trick. Now we want to prove to someone later on, it's a year later, we want to prove to someone that a year ago we included this hash into the Bitcoin blockchain. How do we do that? How do we prove it?

14:24

Sjors Provoost Right. So first you give that person the actual document and then you give them this OTS file, which contains the proof. basically all these Merkle proofs that we stored before.

14:36

Aaron van Wirdum Right. And then what does that person do with that?

14:38

Sjors Provoost They run a command called OTS verify, which basically checks the proof. So it checks whether all the hashes are what they say they should be. And then it checks against your own node, whether the transaction... is included in the blockchain.

14:52

Aaron van Wirdum So that requires them to have the Open Timestamp software, right?

14:56

Sjors Provoost That's right.

14:56

Aaron van Wirdum And the Open Timestamp software uses the Bitcoin blockchain that you have on your node to check if it's really in there.

15:02

Sjors Provoost Exactly. And so it does not need any of these calendar services. So these are just necessary to store proof, but they can disappear off the face of the earth as long as you keep the file with the proof.

15:12

Aaron van Wirdum Right. So now in recent weeks, we discussed all sorts of pruning tricks, these kinds of things. What if you're running a pruned node? Can you still check the blockchain somehow?

15:22

Sjors Provoost Yes, because the nice thing is that you can prove that a transaction exists in a block without keeping the whole block. You can just basically provide a Merkle proof that the transaction actually occurs in the block.

15:33

Aaron van Wirdum Right.

15:34

Sjors Provoost And therefore, the only thing you need is the block header. And yeah, you still have that. If you prune everything, you don't prune the headers.

15:40

Aaron van Wirdum Nice.

15:41

Sjors Provoost So you have a nice chain of evidence.

15:42

Aaron van Wirdum Okay, so let's get to the reason why we're discussing all of this Sjors.

15:45

Sjors Provoost Exactly. So basically there was an email. Let's say Alice was asking Bob for coffee.

15:52

Aaron van Wirdum You don't want to trigger anyone. So we're just going to use Alice and Bob.

15:57

Sjors Provoost I also don't know the name of the sender. Let's say Alice was asking Bob for a coffee back in 2015. And an email circulates on the internet. But you just see an email. So you might rightfully ask, okay, maybe this email is completely fake. Right? But the nice thing is that...

16:12

Aaron van Wirdum You can never trust Alice and Bob not to lie about coffee.

16:17

Sjors Provoost Well, you're not even trusting Alice or Bob because this email just comes out of nowhere. It wasn't given to you by Alice or by Bob.

16:23

Aaron van Wirdum Yeah, I'm just saying I don't trust Alice and Bob's words for whether or not they had coffee together.

16:29

Sjors Provoost That's true.

16:29

Aaron van Wirdum I want cryptographic proof about them drinking coffee or not, sure.

16:33

Sjors Provoost Well, it doesn't prove whether they actually drank coffee, right? It just proves that Alice asked Bob for coffee.

16:38

Aaron van Wirdum I'll settle for that.

16:40

Sjors Provoost Okay, so the nice thing is we have this problem called spam. And phishing, you know, basically fake emails pretending to be somebody else. And the way that is partially solved is that mail servers can sign emails for you. So you don't have to use PGP yourself, although of course you should. But the mail server will say, okay, this email goes to this person and here's the signature. basically testifying to that and Gmail does that standard right

17:08

Aaron van Wirdum so they have a special key to do that

17:09

Sjors Provoost yeah exactly

17:10

Aaron van Wirdum so it's so it's basically in that case google saying yep this is the real email this was the real sender this was the real recipient it was really alice and bob and yes they were really discussing getting a cup of coffee together

17:23

Sjors Provoost exactly and and that of course might be enough but you know because you Depends on how much you trust Google, of course. Google signs a couple of fields, which is the sender, the recipient, the time, and the contents of the message, so you know that. But, you know, we're Bitcoiners, so we want to have more. And so the thing is that there is actually another email out there, which we can talk about, which is Greg Maxwell sending Peter Todd a message randomly about some Bitcoin thing. And it happens that Peter Todd timestamped that message back in 2016. And that message is using the Google's key.

18:03

Aaron van Wirdum The same key.

18:04

Sjors Provoost The same key. So now we have proof that not only did Google sign this thing, they used the key that already existed back in those days. Because we know that key existed.

18:15

Aaron van Wirdum Right. Because it was timestamped on the Bitcoin blockchain.

18:18

Sjors Provoost Exactly.

18:19

Aaron van Wirdum Back in those days.

18:20

Sjors Provoost Yeah. Now that doesn't really matter that this key existed. Because we already know Google signed it. If you assume Google lied about the timestamps, that'd be weird.

18:30

Aaron van Wirdum Still nice.

18:31

Sjors Provoost Yes, exactly.

18:33

Aaron van Wirdum That's a bit of a downer to end the podcast on.

18:35

Sjors Provoost Oh, we're not ending the podcast.

18:36

Aaron van Wirdum Let's give some better examples than why Open Timestamps is great.

18:40

Sjors Provoost Yeah, well, so the caveat is always people get really excited about timestamps and they are quite useful, but they are not magic bullets and there's a lot of things they can't do. So don't assign magic to them.

18:53

Aaron van Wirdum Okay.

18:53

Sjors Provoost There's a couple of things you cannot prove.

18:55

Aaron van Wirdum So there wasn't enough of a downer. Now you're going to list more things you cannot do with timestamps.

18:59

Sjors Provoost That's correct.

19:00

Aaron van Wirdum Okay, let's have it.

19:01

Sjors Provoost The things you cannot prove. You cannot prove, and sorry for all the double negatives, but you cannot prove that a document does not exist. And what this means is you can say, hey, I said X back in 2015. You can prove that. But you cannot prove that you didn't say X in 2015.

19:19

Aaron van Wirdum You cannot say that you didn't say X in 2015.

19:23

Sjors Provoost Right. If I say, I never said blah in 2015, there's no way for me to prove that. Unless I have like 24-hour footage.

19:32

Aaron van Wirdum Right. Of yourself.

19:34

Sjors Provoost Yeah. For the whole year.

19:34

Aaron van Wirdum and timestamp that.

19:35

Sjors Provoost Sure. But other than that, you can't.

19:37

Aaron van Wirdum Okay.

19:38

Sjors Provoost The other thing you can do is...

19:40

Aaron van Wirdum But someone else might be able to. For example, with this email example.

19:44

Sjors Provoost Well, they can prove what I did say, but not what I didn't say. So the other thing you can't say is that there's only one thing that I said. So I might have said in 2015, Bitcoin is going to go to 100. And then I would say Bitcoin is going to go to 1000. And I would say Bitcoin is going to go to 10,000. And then, you know, today I released the proof that I said the right price. But you have no idea how many other prices I timestamped.

20:08

Aaron van Wirdum Right.

20:09

Sjors Provoost So that's important to keep in mind when people use timestamps in magic tricks.

20:13

Aaron van Wirdum You might have just timestamped every single possible price for 2020 and then come out as a visionary in 2020 because you're only revealing the one you got right.

20:25

Sjors Provoost Exactly. I also can't prove that something is older than the timestamp. Basically, if I timestamp something now, then I have no way of proving that maybe it was 10 years ago. Yeah. Right? So if you have some sort of magical anti-aging medicine, You can say, oh, look at how I looked in 2016, but actually that was me in 1981 or something.

20:49

Aaron van Wirdum Sure.

20:50

Sjors Provoost Some more disappointments.

20:51

Aaron van Wirdum Yeah, I want another one.

20:53

Sjors Provoost If you lose the proof or if you lose the original document, well, then you're screwed, right? Because if you have the hash, you cannot reconstruct the document.

21:02

Aaron van Wirdum Right.

21:02

Sjors Provoost And if you just have the hash, I don't think you can still figure out how to connect that to the thing in the blockchain. You need all these intermediate steps of the tree.

21:10

Aaron van Wirdum Yeah, you need the document in order to prove that the hash matches the document by just hashing the document again. Plus you need all sorts of extra info to find it in the blockchain.

21:21

Sjors Provoost Sure, yeah. Yeah, that's what you downloaded and hopefully saved in a file.

21:24

Aaron van Wirdum Yeah, okay.

21:25

Sjors Provoost And the last thing, that's kind of a bummer. You can't really prove that a website is real in general. It's very difficult. So if, let's say there's a tweet and the tweet has a URL and... If I give that to you, you have no way of, like, I cannot prove to you that that URL really contains that tweet. I mean, you can go to it yourself, but that's the only way you can find out. And so that's a problem if 10 years from now I want to prove that a certain tweet was real. If it's still there, then I can prove that it existed. So I can make a timestamp of basically the website as the document looks. And then, you know, today you look at it again and you can see, well, I'm seeing the same text.

22:09

Aaron van Wirdum So how would you fake that a website existed then?

22:12

Sjors Provoost I can just edit some HTML and make a different tweet, right? I can make a tweet. I can make a website that shows a tweet. But the tweet could be complete nonsense. So I have no way to prove that. But if the tweet didn't change, then I can prove it. Right. But the problem is, of course, you can delete tweets. So that's why you have things like the web archive. So you can make a timestamp of a tweet on the web archive. And if the web archive is still out there, when you check the evidence, then you can prove that the tweet existed. But if the tweeter deletes that tweet and gets rid of the web archive, then you're screwed.

22:49

Aaron van Wirdum Yeah, couldn't you make a backup of the web archive yourself?

22:51

Sjors Provoost But then how do you prove that that's the real web archive?

22:54

Aaron van Wirdum I don't know. If you timestamp the web archive and keep a backup of the web archive, then...

23:00

Sjors Provoost Well, it depends on when you made it. So then the question is, when you made that backup? Did you have reason? Did you already know what things you needed to fake? Or was it impossible for you to know what things you needed to fake? So there's still things you can do if you carefully think about what you have and what you don't have. But it's not magic.

23:18

Aaron van Wirdum It's not magic. So what is great about it?

23:22

Sjors Provoost Well, that's why we have a list of called cool things.

23:25

Aaron van Wirdum Nice.

23:26

Sjors Provoost So one of the cool things you can do is you can timestamp Git commits. And Bitcoin Core is doing that, which is nice.

23:34

Aaron van Wirdum So every time there's a new commit to the Bitcoin Core source code, that is timestamped.

23:39

Sjors Provoost Exactly.

23:40

Aaron van Wirdum Right. Interesting.

23:41

Sjors Provoost And we know that all these commits that go into Bitcoin Core are signed by the maintainers too. So there's two things. We now, we have these timestamps and assuming somebody, you know, stores the evidence, multiple people store that evidence and the signatures are real. You can go back in time, look at these timestamps and see that the history is indeed. what GitHub says it is

24:04

Aaron van Wirdum right you can trace the entire history or at least up to a point of what the bitcoin Core source code looked like yeah now if someone if somehow there would be another version of history timestamped in there then it's either not signed by the maintainers. So it's obvious that's the fake one. Or I guess in a worst case scenario, if it is signed by the maintainers.

24:29

Sjors Provoost Then we know that that particular maintainer has been signing two versions of history.

24:33

Aaron van Wirdum So we know there's a problem at least.

24:35

Sjors Provoost Yeah, you might not still not know which is the real one, but you know, there's a very serious problem.

24:39

Aaron van Wirdum Yeah. Interesting. Okay. More cool stuff.

24:42

Sjors Provoost Another cool thing is actually the opposite. The Genesis block timestamps the Times.

24:48

Aaron van Wirdum Yeah, the newspaper, sure.

24:49

Sjors Provoost But actually, it's in practice more like the other way around, right? The fact that the Times occurs in the Bitcoin blockchain, that Times article on January 3rd, 2009, the fact that that occurs in the blockchain means that the blockchain must be more recent than that.

25:06

Aaron van Wirdum Yes, well, the Genesis block at least, yes.

25:08

Sjors Provoost Well, so I guess the whole blockchain, sure. Yes, because everything else came after.

25:12

Aaron van Wirdum Yes.

25:12

Sjors Provoost So that's a nice example of how timestamps in the real world... can prove what's going on in Bitcoin. So I guess you can use some of that magic to triangulate stuff. If people put newspaper articles in the blockchain, then you have some extra assurance that this thing is really not older than you think it is.

25:30

Aaron van Wirdum Okay, more cool stuff.

25:31

Sjors Provoost Well, the last thing is, I guess, more of a general claim is that you can limit the scope of fraud. I believe that's how Peter Todd phrased it. So you cannot necessarily prevent all forms of fraud. As we discussed, there could be really funky things going on. But there's more limited things you can do because these timestamps exist. You have to be more careful. You cannot, for example, like say, hey, this Google key was recently created by a Russian hacker. No, we know it was out there in 2016. So there's certain things you can no longer claim based on these timestamps. And as we described with the example of the hypothetical evil Bitcoin Core maintainer that changes history, you can then prove that there are two versions of history, and that is something they would have to think about.

26:16

Aaron van Wirdum Yeah, so what I really like about this idea, so for, I think, timestamps and these kinds of timestamps and Open Timestamps, it is, I think, the most interesting and the most important. non-monetary use of Bitcoin. I think it's a big deal being able to timestamp documents in such a very viable way.

26:37

Sjors Provoost Okay, yeah, it's definitely very cool and very useful.

26:39

Aaron van Wirdum You know, I've studied history and it's a huge part of a historian's job to find out if documents, if evidence is really as old as it's supposed to be. A nice example is, I'm sure you've seen these photos of Joseph Stalin, where people are just photoshopped out before Photoshop was a thing.

26:59

Sjors Provoost Yeah, exactly. Nowadays, everybody does that.

27:01

Aaron van Wirdum Yeah, back in those days, that was a bit more original. But these are the kinds of things, like you can imagine how these kinds of trickeries could be prevented with something like Open Timestamps somehow, or at least be made more obvious, or it could be a very useful tool for historians, I think. The other cool thing, Sjors, I'm going to tell you one more cool thing before we end this podcast.

27:24

Sjors Provoost All right, tell me.

27:24

Aaron van Wirdum Is that I think one of the nice things about Open Timestamps is that it's actually, it resembles the idea that is mentioned in the white paper, in the Bitcoin white paper, the Scott Stornetta and Stuart Haber, if I'm recalling these names correctly. They had their own idea for timestamping back in the, I think it was either the late 80s or the early 90s. And back then, Stornetta's idea, his concern was that as long as we have paper documents, then forging paper documents, you know, is at least kind of difficult. It's at least sort of like it leaves traces or you can sort of tell that something has been doctored with or messed with or it's at least sort of possible while if we're moving...

28:12

Sjors Provoost And you know how old paper is.

28:13

Aaron van Wirdum Yeah, you can even tell how old paper is in many cases. or at least roughly and if we're moving to a digital world that kind of stuff becomes completely impossible and every document can be altered in ways that are just you know unseeable so he he wanted to solve that problem and he and Haber they tried to solve this problem and they kind of couldn't they couldn't figure out how to solve this problem because every solution they come up with relied on some kind of third party to vouch that a document existed at a certain point in time and maybe that third party would be checked by another by fourth party or but there was always sort of some trust involved and that's what i want to get rid of

28:59

Sjors Provoost right and that sounds you know pretty problematic in the stalin example you just mentioned

29:03

Aaron van Wirdum exactly yes so the ultimately even they thought they didn't They thought they were not going to be able to solve this problem, and then they wanted to at least prove that this was an unsolvable problem. But then while trying to prove that it was unsolvable, they came to the realization that, wait a minute, this is actually solvable if everyone in the world... is party of the timestamping process. So everyone in the world submits their hashes and everyone in the world receives the combined hashes in return. That way, if you want to forge history, you would have to corrupt everyone or it would be obvious to everyone like no one's going to go along with that. So that was kind of their solution and this solution, I think, sort of evolved and ultimately they came up with this idea of... including the Merkle root into newspapers. So then there was like a Merkle root in the New York Times of May 22nd, 1996. So you knew that documents existed back then. And ultimately this idea, their ideas were inspiration for Satoshi Nakamoto. It was implemented. It was included in the Bitcoin white paper. And that's interesting because now Peter Todd came up with a solution to actually implement a very similar solution into Bitcoin. So we've sort of gone full circle.

30:26

Sjors Provoost Yeah, it's great because everybody wants the Bitcoin blockchain. It's very redundant.

30:31

Aaron van Wirdum What?

30:32

Sjors Provoost It's very redundant. Basically, everybody has a copy of the Bitcoin blockchain. So just like that newspaper.

30:38

Aaron van Wirdum Right, pretty much. Okay.

30:40

Sjors Provoost And they have a financial incentive to have this copy. It's one thing to say everybody in the world must participate and have this hash. It's another to say, well, if you want to use money, you need to keep track of a hash. And by the way, it also fixes this timestamping problem.

30:54

Aaron van Wirdum Right.

30:55

Sjors Provoost I think, I guess that's all we've got.

30:57

Aaron van Wirdum I think so too, Sjors.

30:58

Sjors Provoost So thank you for listening to the Van Wirdum Sjorsnado.

31:01

Aaron van Wirdum There you go.