WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:07.220 --> 00:00:10.200 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:10.360 --> 00:00:10.540 Hello. 00:00:11.080 --> 00:00:11.480 Hey, Sjors. 00:00:11.700 --> 00:00:12.140 What's up? 00:00:12.420 --> 00:00:18.360 Sjors, today we are going to discuss at length, in depth, the American political 00:00:18.360 --> 00:00:19.180 situation. 00:00:19.460 --> 00:00:23.080 That's right. We're going to explain everything and we're going to just tell you 00:00:23.080 --> 00:00:25.860 who to vote for, even though this will be released after the election. 00:00:26.080 --> 00:00:31.820 This is our election special that's going to be published three days after the election. 00:00:32.060 --> 00:00:32.540 Exactly. 00:00:33.520 --> 00:00:39.140 There was something in the news this week, which is mildly, slightly relevant to 00:00:39.140 --> 00:00:42.840 Bitcoin. And we thought it would be fun to dedicate an episode to it. 00:00:43.240 --> 00:00:43.840 Yep, exactly. 00:00:44.480 --> 00:00:48.040 We're not actually going to discuss the politics of the situation, I think. 00:00:48.220 --> 00:00:50.520 I believe the listeners understand that. 00:00:50.740 --> 00:00:52.960 What we're going to discuss is Open Timestamps. 00:00:53.140 --> 00:00:53.480 Yes. 00:00:53.700 --> 00:00:57.420 Right? And we'll get to the reason why it's relevant later. Or do you want to get 00:00:57.420 --> 00:00:57.960 into that now? 00:00:58.100 --> 00:00:59.980 Well, we can say that something was timestamped. 00:01:00.120 --> 00:01:00.320 Okay. 00:01:00.520 --> 00:01:03.660 That was, you know, at least... mentioned in the news 00:01:03.660 --> 00:01:09.640 yeah yeah so it's these emails by Hunter Biden or he received emails 00:01:09.640 --> 00:01:15.180 that's actually the story yeah through time stamps we can be sure that these 00:01:15.180 --> 00:01:20.260 emails were in fact sent a couple years ago and they were signed with Google's 00:01:21.180 --> 00:01:21.620 Exactly. 00:01:21.740 --> 00:01:22.060 Keys. 00:01:22.480 --> 00:01:27.200 Yeah, they were sent between two Gmail addresses and Google signs email. So we 00:01:27.200 --> 00:01:30.820 know that Google signed that email and if they don't lie about the timestamps, 00:01:30.900 --> 00:01:34.900 which I don't think Google does, we know those emails are real. What they mean is 00:01:34.900 --> 00:01:36.280 a different question, but we know they're real. 00:01:36.620 --> 00:01:40.380 Yes, and thanks to Open Timestamps, we know that the emails were really sent. 00:01:40.720 --> 00:01:44.840 Actually, thanks to Open Timestamps, we know less than that. But we can get into that. 00:01:45.000 --> 00:01:49.940 Okay, let's get into Open Timestamps then. So Open Timestamps, it's a project by 00:01:49.940 --> 00:01:52.460 Peter Todd, former Bitcoin Core contributor. 00:01:52.880 --> 00:01:55.800 He likes to call himself a former Bitcoin Core contributor. 00:01:56.160 --> 00:02:00.500 Yes, and Applied Cryptographer Consultant. That's what he calls himself. 00:02:00.780 --> 00:02:00.980 Okay. 00:02:01.320 --> 00:02:04.460 So do you want to explain what it is, Open Timestamps, Sjors? 00:02:05.060 --> 00:02:10.120 It's basically a way to prove that a given document exists—existed 00:02:10.120 --> 00:02:12.640 before a certain time. 00:02:13.050 --> 00:02:16.090 Yeah, before or at a certain time, I guess. 00:02:16.760 --> 00:02:20.100 Yeah, well, if you add one second, then you can make it before. 00:02:20.120 --> 00:02:21.480 Sure, exactly. Sure, fair enough. 00:02:21.600 --> 00:02:26.540 But the idea is you use the Bitcoin blockchain for this because Bitcoin blocks, 00:02:26.660 --> 00:02:30.620 we know when they were created, roughly, not to the second, but we know roughly 00:02:30.620 --> 00:02:36.440 when they were created. And so if the Bitcoin blockchain points to a document, 00:02:36.580 --> 00:02:41.260 and I say points to in quotes, that means that document must have existed before 00:02:41.260 --> 00:02:45.510 that part of the blockchain was created. And that's kind of what Open Timestamp 00:02:45.510 --> 00:02:50.010 leverages. Of course, we don't actually put documents in the blockchain. That 00:02:50.010 --> 00:02:54.750 would be bad. We put timestamps in the documents in the blockchain. And these 00:02:54.750 --> 00:02:58.730 timestamps are a hash of the document or they are a hash of multiple documents. 00:02:58.990 --> 00:03:01.990 There are actual documents in the blockchain, aren't there? 00:03:02.190 --> 00:03:07.330 That's correct. So that's the worst way you can do this. You can put the actual 00:03:07.330 --> 00:03:13.160 document in the blockchain and then you can prove that that document existed. you 00:03:13.160 --> 00:03:16.360 know, very long ago. And some people were doing that back in 2011. 00:03:16.720 --> 00:03:19.700 Yeah. For example, the Bitcoin white paper, I think, is in the blockchain, right? 00:03:20.140 --> 00:03:20.720 It could be. 00:03:20.920 --> 00:03:23.660 I think so. But anyway, so there's a better way of doing this. 00:03:24.510 --> 00:03:27.550 Yes. Because a document can be hashed. 00:03:27.830 --> 00:03:29.050 Yes. So what's a hash? 00:03:30.130 --> 00:03:30.890 Well, a hash... 00:03:30.570 --> 00:03:35.990 Is that too much for our audience? Do they already understand that you think Sjors? 00:03:36.170 --> 00:03:37.750 No, it's good to remind people. 00:03:37.870 --> 00:03:39.330 Okay, let's get it. What is a hash? 00:03:39.470 --> 00:03:42.910 And we can teach them something. So the Dutch word for hash is verhaspeling. Not 00:03:42.910 --> 00:03:48.470 that anyone would ever use that word. But it is basically a mangled version of it. 00:03:48.510 --> 00:03:49.570 Why did you mention that? 00:03:50.130 --> 00:03:51.990 Because we want to educate our youth. 00:03:52.070 --> 00:03:53.170 We want to teach them Dutch? 00:03:53.390 --> 00:03:54.810 Yes. Verhaspeling. 00:03:54.910 --> 00:03:56.490 Well, you taught me something. I didn't know that. 00:03:57.230 --> 00:03:59.130 Well, yeah, because nobody would use that. 00:03:59.290 --> 00:03:59.470 Right. 00:04:00.090 --> 00:04:05.970 So the idea is that you take any given text and you mangle it in a way 00:04:05.970 --> 00:04:09.910 that you get just a number. Or, you know, it looks like a bunch of letters, but 00:04:09.910 --> 00:04:10.830 it's just a big number. 00:04:11.090 --> 00:04:13.250 Yeah, well, it's a hexadecimal number, right? 00:04:13.840 --> 00:04:16.880 Well, a number is a number, but you can write a number as a hexadecimal. 00:04:17.080 --> 00:04:17.380 Exactly. 00:04:17.840 --> 00:04:22.820 So the key there is that if you change one letter in the text, the hash changes. 00:04:23.280 --> 00:04:28.040 And so a good hash function is something that takes any text and produces a 00:04:28.040 --> 00:04:32.660 unique number. and does not collide. So you cannot come up with two different 00:04:32.660 --> 00:04:36.220 texts that produce the same number. Right. Now, that's, of course, impossible to 00:04:36.220 --> 00:04:41.360 actually prove. But, you know, the Wizards came up with, for example, 00:04:41.500 --> 00:04:45.920 SHA-256. And so far, it seems to work. And the nice thing is, you know, the 00:04:45.920 --> 00:04:50.250 Bitcoin blockchain keeps producing blocks. And there's a pretty big incentive to 00:04:50.250 --> 00:04:55.290 find a duplicate. So if there is a vulnerability in SHA-256 where you could 00:04:55.290 --> 00:04:59.960 take... you could change the contents of a block and still have the same proof of 00:04:59.960 --> 00:05:03.140 work. That would be bad, but we'll find out soon enough. 00:05:03.680 --> 00:05:08.540 Yeah. So I guess the benefits of a hash, I would describe as you can, if you have 00:05:08.540 --> 00:05:14.040 a hash of a document, and you have the document, then you can prove that the hash 00:05:14.040 --> 00:05:17.300 of the document is in fact the hash of the document. Because every time you hash 00:05:17.300 --> 00:05:18.980 the document, the same hash comes out. 00:05:19.180 --> 00:05:19.660 That's right. 00:05:19.900 --> 00:05:24.620 And the other benefit is that a hash is very small compared to the document. Or 00:05:24.620 --> 00:05:29.400 at least it can be very small. So you can have, I don't know, an entire book, and 00:05:29.400 --> 00:05:32.120 you produce a hash of it, and you just have one string of numbers. 00:05:32.700 --> 00:05:33.100 Exactly. 00:05:33.420 --> 00:05:37.660 So now you can prove that the book... is the same thing as the hash. 00:05:38.020 --> 00:05:42.020 Yeah, and this can be useful for very practical stuff. Like if you have optical 00:05:42.020 --> 00:05:46.340 character recognition, so you're scanning a book and you want to make sure that 00:05:46.340 --> 00:05:49.860 the scan is correct, or maybe you have a checksum, which is also a hash. 00:05:50.200 --> 00:05:51.680 Right, okay, so that's what a hash is. 00:05:51.900 --> 00:05:52.260 Yes. 00:05:52.480 --> 00:05:53.360 Do we cover hashes? 00:05:53.580 --> 00:05:54.700 Yeah. I think so. 00:05:54.960 --> 00:05:59.840 Now, something we discussed last week is a Merkle tree. How about I explain the 00:05:59.840 --> 00:06:00.740 Merkle tree this time? 00:06:00.920 --> 00:06:01.420 Sounds good. 00:06:01.540 --> 00:06:06.340 And then people can tell us who did the better job. All right. Okay, so we're 00:06:06.340 --> 00:06:10.980 hashing documents. We just explained how we're hashing documents. Now, let's say 00:06:10.980 --> 00:06:15.820 we have two documents. Each of them we turn into a hash. So now we have two 00:06:15.820 --> 00:06:21.780 hashes. Now we take the two hashes and we combine these and turn them 00:06:21.780 --> 00:06:24.400 into a new hash. So now we have one hash again. 00:06:24.660 --> 00:06:24.880 Yeah. 00:06:26.070 --> 00:06:29.750 Now we have two more documents. We hash these documents as well. We have two 00:06:29.750 --> 00:06:35.570 hashes. These two hashes we hash again. So now, in total, we still have two 00:06:35.570 --> 00:06:40.190 hashes. We hash these hashes together. And now, once again, we have one hash. 00:06:40.410 --> 00:06:42.830 One hash that represents all these four documents. 00:06:42.910 --> 00:06:44.650 Yes, one hash that includes all four. 00:06:44.810 --> 00:06:48.210 And this looks like a pyramid, but we call it a tree. 00:06:49.400 --> 00:06:50.900 Yeah, it's a reverse tree. 00:06:51.060 --> 00:06:51.440 It's a pyramid. 00:06:51.600 --> 00:06:53.900 Yeah, you're right. So that's what a Merkle tree is. 00:06:54.040 --> 00:06:55.480 So why do we care about Merkle trees? 00:06:55.780 --> 00:07:01.370 So the nice thing about a Merkle tree is that if you have... one of the 00:07:01.370 --> 00:07:06.550 documents that's included in the Merkle tree, you should be able to prove that it 00:07:06.550 --> 00:07:12.350 is in the Merkle tree to someone who only has the Merkle hash, which was the 00:07:12.350 --> 00:07:13.750 last hash we ended up with. 00:07:14.190 --> 00:07:18.950 Exactly. And they also don't need to know every document in the Merkle tree. So 00:07:18.950 --> 00:07:21.190 you can reveal one document in the Merkle tree. 00:07:21.370 --> 00:07:21.710 Right. 00:07:22.170 --> 00:07:26.390 By, you know, revealing the right hashes. Basically one at every level of the tree. 00:07:26.590 --> 00:07:28.170 Yes, which is called a Merkle root. 00:07:28.310 --> 00:07:28.870 Or Merkle proof. 00:07:29.050 --> 00:07:31.230 Oh, sorry. Merkle proof. So, yeah. Okay. 00:07:31.550 --> 00:07:36.610 Okay. So why do we care about this? Instead of putting a whole document inside 00:07:36.610 --> 00:07:41.270 the blockchain in the transaction, we can put a hash of a document in a 00:07:41.270 --> 00:07:41.730 transaction. 00:07:42.010 --> 00:07:45.730 Right, which is much more compact, much smaller, and therefore requires less 00:07:45.730 --> 00:07:46.830 block space and less fees. 00:07:47.030 --> 00:07:47.250 Exactly. 00:07:47.270 --> 00:07:47.850 So that's better. 00:07:48.010 --> 00:07:51.430 And there's a nice way to do that. This is called OP_RETURN, which we discussed, 00:07:51.450 --> 00:07:55.250 I believe, in a previous episode. It basically tells the node, like, everything 00:07:55.250 --> 00:07:59.410 after this you can ignore. You don't have to put this in your UTXO set, which we 00:07:59.410 --> 00:08:03.700 talked about last episode, takes up RAM. So you write OP_RETURN in the 00:08:03.700 --> 00:08:08.260 destination of your payment and then it's followed by the hash. And then some 00:08:08.260 --> 00:08:09.680 other software will have to interpret that. 00:08:10.020 --> 00:08:10.260 Right. 00:08:10.460 --> 00:08:13.360 But it's still a bit inefficient, right? And that's why we're talking about this 00:08:13.360 --> 00:08:13.800 Merkle tree. 00:08:14.040 --> 00:08:17.720 Yeah. You don't want to have to create a transaction for each document you want 00:08:17.720 --> 00:08:19.940 to include in the blockchain because there's a better way. 00:08:21.910 --> 00:08:24.030 And that's including the Merkle root. 00:08:24.270 --> 00:08:24.730 That's right. 00:08:24.890 --> 00:08:26.330 I'm confused about terms. Can you hear? 00:08:26.550 --> 00:08:28.570 So the Merkle root is the top of the tree. 00:08:28.750 --> 00:08:28.970 Yes. 00:08:29.270 --> 00:08:32.450 Or the top of the roots or the bottom of the upside down tree, depending on how 00:08:32.450 --> 00:08:33.050 you want to look at it. 00:08:34.500 --> 00:08:39.240 And the Merkle proof is a way to say that this given document actually is part of 00:08:39.240 --> 00:08:43.940 that tree without having to reveal the entire tree, but just bits of the tree. 00:08:45.100 --> 00:08:49.640 So how do you use this in practice is the question, because you might just have 00:08:49.640 --> 00:08:53.100 one document that you want to timestamp, but you don't want to create a 00:08:53.100 --> 00:08:58.660 transaction for that. But what if people could come together and basically have a 00:08:58.660 --> 00:09:04.450 whole bunch of documents, maybe once a day or once an hour timestamped? And that 00:09:04.450 --> 00:09:09.910 is where the calendar server comes out. So this is a super centralized solution, 00:09:09.910 --> 00:09:14.190 but that doesn't really matter. And we'll explain why that doesn't matter. 00:09:14.410 --> 00:09:16.890 It's a server ran by Peter Todd in this case, right? 00:09:17.310 --> 00:09:19.550 It could be, we don't know, but that's what he says. 00:09:19.770 --> 00:09:21.070 I trust Peter, don't you? 00:09:21.730 --> 00:09:25.610 I trust Peter to run this server. We don't have to. 00:09:26.220 --> 00:09:27.040 Even better. 00:09:27.440 --> 00:09:32.560 Yes. Okay, so what this calendar server does is basically everybody keeps sending 00:09:32.560 --> 00:09:35.860 documents to it, or actually hashes of documents to it, of course, not the actual 00:09:35.860 --> 00:09:41.610 document. That would be bad. And the server basically... waits one 00:09:41.610 --> 00:09:46.570 second and then tells you at the end of that second, if you were the only hash or 00:09:46.570 --> 00:09:50.370 if there were other people who submitted something in that second, and it gives 00:09:50.370 --> 00:09:55.450 you a hash back. And you then need to call that server again a while later to 00:09:55.450 --> 00:09:59.280 say, hey, has this thing been included in the block yet? Because every couple of 00:09:59.280 --> 00:10:02.680 hours, it will take all these hashes and make a Merkle tree out of that and put 00:10:02.680 --> 00:10:05.220 that on the blockchain inside a transaction. 00:10:05.640 --> 00:10:09.760 So what the server is returning to you immediately is a hash of the document 00:10:09.760 --> 00:10:10.180 itself. 00:10:10.650 --> 00:10:15.750 I think the server immediately returns either a timestamp or maybe the hash of 00:10:15.750 --> 00:10:19.410 every other document it received. No, probably, I guess a timestamp. I haven't 00:10:19.410 --> 00:10:21.930 looked at the implementation, but the idea is that it groups everybody into 00:10:21.930 --> 00:10:27.300 seconds. So you never have to wait for more than a second. And then at some 00:10:27.300 --> 00:10:32.260 point, multiple seconds worth of transactions or multiple seconds worth of 00:10:32.260 --> 00:10:37.510 documents are put into a single transaction, which is confirmed in a chain. And 00:10:37.510 --> 00:10:41.870 then the server will actually give you The whole chain of evidence you need to go 00:10:41.870 --> 00:10:45.090 from the document you submitted to that transaction and the block. 00:10:45.350 --> 00:10:49.150 Okay, so that last part doesn't happen immediately. That last part telling you 00:10:49.150 --> 00:10:53.170 where to find it in the tree, that only happens when it's included in a transaction. 00:10:53.410 --> 00:10:58.130 Well, it has to, right? And included in a block. Because you don't know what 00:10:58.130 --> 00:11:01.010 block it's going to be in when you make the transaction. But you don't even know 00:11:01.010 --> 00:11:02.450 what the transaction is going to look like. 00:11:03.940 --> 00:11:07.560 because there's more documents coming in, so the hash keeps changing. The hash 00:11:07.560 --> 00:11:10.980 that goes into the transaction keeps changing as new documents go to this 00:11:10.980 --> 00:11:11.620 calendar server. 00:11:13.160 --> 00:11:17.080 But eventually, at some point, everything it's got so far goes into a 00:11:17.080 --> 00:11:21.280 transaction, it gets confirmed, and now it has that proof. So this is where 00:11:21.280 --> 00:11:27.240 you temporarily have to trust it. But you can 00:11:27.240 --> 00:11:30.140 see if it's not doing what it's supposed to do. It could just decide to throw 00:11:30.140 --> 00:11:34.930 away your document. and never include it. But once it has done that, you don't 00:11:34.930 --> 00:11:38.460 need it anymore because you get all the evidence yourself and you can keep it. 00:11:38.600 --> 00:11:42.300 And if they somehow censor you, then you just run your own server. 00:11:42.780 --> 00:11:47.440 Okay, so if I understand correctly, everyone's sending in documents they want to 00:11:47.440 --> 00:11:49.420 have hashed or do they send in the hashes themselves? 00:11:49.640 --> 00:11:50.440 They send in the hashes. 00:11:50.600 --> 00:11:54.320 Okay, so everyone sends in hashes of documents they want to have timestamped. 00:11:54.860 --> 00:12:00.050 Once a second, Peter Todd returns or, well, the... calendar server whoever 00:12:00.050 --> 00:12:05.310 operates it returns either a hash of the document if there was only one document 00:12:05.310 --> 00:12:09.650 that second well no in that case what do you get back because you're already 00:12:09.650 --> 00:12:10.410 sending in a hash 00:12:10.960 --> 00:12:15.040 I guess it'll just give you the hash back. I haven't read the exact code, but 00:12:15.040 --> 00:12:16.800 this is probably how it roughly works. 00:12:16.940 --> 00:12:20.960 Yeah, it's a bit of an implementation detail anyway. So you send in the hash of 00:12:20.960 --> 00:12:26.320 the document you want to have timestamped. Once a second, a hash is returned, 00:12:26.540 --> 00:12:31.540 which is either then, I guess, that hash, or if multiple people send in documents 00:12:31.540 --> 00:12:36.720 or if there were multiple hashes of documents sent in in the same second, then a 00:12:36.720 --> 00:12:42.720 Merkle root is returned plus a Merkle path which lets you 00:12:42.720 --> 00:12:48.100 find your hash in the tree. It's like a miniature tree for once a second. 00:12:48.380 --> 00:12:51.260 Every second, there's like a miniature tree. 00:12:51.360 --> 00:12:56.040 And this just prevents you from flooding the server with millions of hashes and 00:12:56.040 --> 00:13:00.440 it having to hold on to that for years. Now, whatever you throw at it in one 00:13:00.440 --> 00:13:02.480 second, it can forget after one second. 00:13:02.720 --> 00:13:07.440 Right. Now, all of these miniature trees, to call them that, these are all sort 00:13:07.440 --> 00:13:13.260 of accumulated. entered into a new Merkle tree, and the Merkle root of 00:13:13.260 --> 00:13:18.440 that tree is once a while included in a Bitcoin transaction. Right. At that 00:13:18.440 --> 00:13:22.300 point, all of the documents are basically timestamped in the Bitcoin blockchain. 00:13:22.660 --> 00:13:24.100 Yes, but you still don't have the proof. 00:13:24.380 --> 00:13:27.460 Yes, and that proof is also sent to you by the server. 00:13:27.700 --> 00:13:31.320 No, no, no. The server, you know, it's not don't call us, we call you. It's the opposite. 00:13:31.600 --> 00:13:32.020 Oh, it is? 00:13:32.060 --> 00:13:32.880 You have to call the server. 00:13:33.100 --> 00:13:34.980 Okay. So you basically... 00:13:35.540 --> 00:13:39.580 Every now and then, I think there's a way that you can just wait for it if you 00:13:39.580 --> 00:13:43.720 have a patient computer, but you can also pull it later and say, hey, do you have 00:13:43.720 --> 00:13:47.220 the full proof for me now? And at that point, it will give you everything you need. 00:13:47.620 --> 00:13:48.060 Right, okay. 00:13:48.340 --> 00:13:52.960 So which to go back is basically you started your document that you gave, the 00:13:52.960 --> 00:13:58.530 hash, and then the whatever hashes of all the documents in that one second, 00:13:58.530 --> 00:14:04.090 and then whatever transaction it comes in, and then where that is in the block. 00:14:04.690 --> 00:14:05.130 Right. 00:14:05.290 --> 00:14:06.170 That's pretty much the proof. 00:14:06.570 --> 00:14:11.190 All right. So now we've included a document or the hash of a document in the 00:14:11.190 --> 00:14:15.350 Bitcoin blockchain through this Merkle trick. Now we want to prove to someone 00:14:15.350 --> 00:14:19.950 later on, it's a year later, we want to prove to someone that a year ago we 00:14:19.950 --> 00:14:24.230 included this hash into the Bitcoin blockchain. How do we do that? How do we prove it? 00:14:24.430 --> 00:14:28.790 Right. So first you give that person the actual document and then you give them 00:14:28.790 --> 00:14:34.290 this OTS file, which contains the proof. basically all these Merkle proofs 00:14:34.290 --> 00:14:35.690 that we stored before. 00:14:36.170 --> 00:14:38.430 Right. And then what does that person do with that? 00:14:38.790 --> 00:14:43.630 They run a command called OTS verify, which basically checks the proof. So it 00:14:43.630 --> 00:14:47.110 checks whether all the hashes are what they say they should be. And then it 00:14:47.110 --> 00:14:52.220 checks against your own node, whether the transaction... is included in the blockchain. 00:14:52.420 --> 00:14:55.740 So that requires them to have the Open Timestamp software, right? 00:14:56.140 --> 00:14:56.600 That's right. 00:14:56.760 --> 00:15:00.360 And the Open Timestamp software uses the Bitcoin blockchain that you have on your 00:15:00.360 --> 00:15:01.980 node to check if it's really in there. 00:15:02.140 --> 00:15:05.500 Exactly. And so it does not need any of these calendar services. So these are 00:15:05.500 --> 00:15:09.680 just necessary to store proof, but they can disappear off the face of the earth 00:15:09.680 --> 00:15:11.880 as long as you keep the file with the proof. 00:15:12.140 --> 00:15:16.700 Right. So now in recent weeks, we discussed all sorts of pruning tricks, these 00:15:16.700 --> 00:15:21.050 kinds of things. What if you're running a pruned node? Can you still check the 00:15:21.050 --> 00:15:22.030 blockchain somehow? 00:15:22.490 --> 00:15:26.290 Yes, because the nice thing is that you can prove that a transaction exists in a 00:15:26.290 --> 00:15:30.710 block without keeping the whole block. You can just basically provide a Merkle 00:15:30.710 --> 00:15:33.270 proof that the transaction actually occurs in the block. 00:15:33.570 --> 00:15:33.690 Right. 00:15:34.050 --> 00:15:37.970 And therefore, the only thing you need is the block header. And yeah, you still 00:15:37.970 --> 00:15:40.350 have that. If you prune everything, you don't prune the headers. 00:15:40.690 --> 00:15:40.990 Nice. 00:15:41.330 --> 00:15:42.650 So you have a nice chain of evidence. 00:15:42.890 --> 00:15:45.610 Okay, so let's get to the reason why we're discussing all of this Sjors. 00:15:45.990 --> 00:15:51.370 Exactly. So basically there was an email. Let's say Alice was asking Bob for 00:15:51.370 --> 00:15:51.810 coffee. 00:15:52.910 --> 00:15:56.830 You don't want to trigger anyone. So we're just going to use Alice and Bob. 00:15:57.030 --> 00:16:00.910 I also don't know the name of the sender. Let's say Alice was asking Bob for a 00:16:00.910 --> 00:16:06.250 coffee back in 2015. And an email circulates on the internet. But you just see an 00:16:06.250 --> 00:16:09.950 email. So you might rightfully ask, okay, maybe this email is completely fake. 00:16:10.560 --> 00:16:12.760 Right? But the nice thing is that... 00:16:12.760 --> 00:16:15.680 You can never trust Alice and Bob not to lie about coffee. 00:16:17.300 --> 00:16:20.700 Well, you're not even trusting Alice or Bob because this email just comes out of 00:16:20.700 --> 00:16:23.120 nowhere. It wasn't given to you by Alice or by Bob. 00:16:23.640 --> 00:16:27.540 Yeah, I'm just saying I don't trust Alice and Bob's words for whether or not they 00:16:27.540 --> 00:16:28.380 had coffee together. 00:16:29.000 --> 00:16:29.760 That's true. 00:16:29.880 --> 00:16:32.800 I want cryptographic proof about them drinking coffee or not, sure. 00:16:33.200 --> 00:16:36.940 Well, it doesn't prove whether they actually drank coffee, right? It just proves 00:16:36.940 --> 00:16:38.380 that Alice asked Bob for coffee. 00:16:38.960 --> 00:16:40.180 I'll settle for that. 00:16:40.640 --> 00:16:46.190 Okay, so the nice thing is we have this problem called spam. And phishing, you 00:16:46.190 --> 00:16:51.490 know, basically fake emails pretending to be somebody else. And the way that is 00:16:51.490 --> 00:16:56.770 partially solved is that mail servers can sign emails for you. So you don't have 00:16:56.770 --> 00:17:00.590 to use PGP yourself, although of course you should. But the mail server will say, 00:17:00.690 --> 00:17:05.060 okay, this email goes to this person and here's the signature. basically 00:17:05.060 --> 00:17:08.040 testifying to that and Gmail does that standard right 00:17:08.040 --> 00:17:09.920 so they have a special key to do that 00:17:09.920 --> 00:17:10.920 yeah exactly 00:17:10.920 --> 00:17:15.400 so it's so it's basically in that case google saying yep this is the real email 00:17:15.400 --> 00:17:20.120 this was the real sender this was the real recipient it was really alice and bob 00:17:20.120 --> 00:17:23.740 and yes they were really discussing getting a cup of coffee together 00:17:23.740 --> 00:17:28.860 exactly and and that of course might be enough but you know because you 00:17:29.250 --> 00:17:33.570 Depends on how much you trust Google, of course. Google signs a couple of fields, 00:17:33.870 --> 00:17:37.870 which is the sender, the recipient, the time, and the contents of the message, so 00:17:37.870 --> 00:17:43.750 you know that. But, you know, we're Bitcoiners, so we want to have more. And so 00:17:43.750 --> 00:17:49.350 the thing is that there is actually another email out there, which we can talk 00:17:49.350 --> 00:17:54.650 about, which is Greg Maxwell sending Peter Todd a message randomly about some 00:17:54.650 --> 00:17:59.230 Bitcoin thing. And it happens that Peter Todd timestamped that message back in 00:17:59.230 --> 00:18:03.470 2016. And that message is using the Google's key. 00:18:03.770 --> 00:18:04.410 The same key. 00:18:04.590 --> 00:18:10.450 The same key. So now we have proof that not only did Google sign this thing, they 00:18:10.450 --> 00:18:15.230 used the key that already existed back in those days. Because we know that key 00:18:15.230 --> 00:18:15.650 existed. 00:18:15.930 --> 00:18:18.830 Right. Because it was timestamped on the Bitcoin blockchain. 00:18:18.970 --> 00:18:19.250 Exactly. 00:18:19.370 --> 00:18:20.030 Back in those days. 00:18:20.250 --> 00:18:25.440 Yeah. Now that doesn't really matter that this key existed. 00:18:26.060 --> 00:18:29.520 Because we already know Google signed it. If you assume Google lied about the 00:18:29.520 --> 00:18:30.520 timestamps, that'd be weird. 00:18:30.900 --> 00:18:31.400 Still nice. 00:18:31.640 --> 00:18:32.580 Yes, exactly. 00:18:33.120 --> 00:18:35.340 That's a bit of a downer to end the podcast on. 00:18:35.560 --> 00:18:36.560 Oh, we're not ending the podcast. 00:18:36.860 --> 00:18:40.080 Let's give some better examples than why Open Timestamps is great. 00:18:40.300 --> 00:18:44.760 Yeah, well, so the caveat is always people get really excited about timestamps 00:18:44.760 --> 00:18:48.980 and they are quite useful, but they are not magic bullets and there's a lot of 00:18:48.980 --> 00:18:49.660 things they can't do. 00:18:50.980 --> 00:18:52.840 So don't assign magic to them. 00:18:53.080 --> 00:18:53.520 Okay. 00:18:53.680 --> 00:18:55.020 There's a couple of things you cannot prove. 00:18:55.140 --> 00:18:58.020 So there wasn't enough of a downer. Now you're going to list more things you 00:18:58.020 --> 00:18:59.240 cannot do with timestamps. 00:18:59.280 --> 00:18:59.840 That's correct. 00:19:00.220 --> 00:19:01.060 Okay, let's have it. 00:19:01.260 --> 00:19:05.000 The things you cannot prove. You cannot prove, and sorry for all the double 00:19:05.000 --> 00:19:09.080 negatives, but you cannot prove that a document does not exist. And what this 00:19:09.080 --> 00:19:15.050 means is you can say, hey, I said X back in 2015. You can prove 00:19:15.050 --> 00:19:19.170 that. But you cannot prove that you didn't say X in 2015. 00:19:19.490 --> 00:19:22.810 You cannot say that you didn't say X in 2015. 00:19:23.110 --> 00:19:28.450 Right. If I say, I never said blah in 2015, there's no way for me to prove that. 00:19:30.070 --> 00:19:32.030 Unless I have like 24-hour footage. 00:19:32.370 --> 00:19:33.770 Right. Of yourself. 00:19:34.030 --> 00:19:35.050 Yeah. For the whole year. 00:19:34.970 --> 00:19:35.850 and timestamp that. 00:19:35.850 --> 00:19:37.450 Sure. But other than that, you can't. 00:19:37.710 --> 00:19:37.910 Okay. 00:19:38.430 --> 00:19:40.010 The other thing you can do is... 00:19:40.010 --> 00:19:44.160 But someone else might be able to. For example, with this email example. 00:19:44.560 --> 00:19:48.320 Well, they can prove what I did say, but not what I didn't say. So the other 00:19:48.320 --> 00:19:52.820 thing you can't say is that there's only one thing that I said. So I might have 00:19:52.820 --> 00:19:57.960 said in 2015, Bitcoin is going to go to 100. And then I would say Bitcoin is 00:19:57.960 --> 00:20:01.500 going to go to 1000. And I would say Bitcoin is going to go to 10,000. And then, 00:20:01.600 --> 00:20:06.380 you know, today I released the proof that I said the right price. But you have no 00:20:06.380 --> 00:20:08.000 idea how many other prices I timestamped. 00:20:08.340 --> 00:20:08.500 Right. 00:20:09.290 --> 00:20:12.710 So that's important to keep in mind when people use timestamps in magic tricks. 00:20:13.670 --> 00:20:19.350 You might have just timestamped every single possible price for 2020 and then 00:20:19.350 --> 00:20:24.700 come out as a visionary in 2020 because you're only revealing the one you got right. 00:20:25.480 --> 00:20:29.700 Exactly. I also can't prove that something is older than the timestamp. 00:20:29.940 --> 00:20:35.520 Basically, if I timestamp something now, then I have no 00:20:35.520 --> 00:20:40.460 way of proving that maybe it was 10 years ago. Yeah. Right? So if you have some 00:20:40.460 --> 00:20:45.230 sort of magical anti-aging medicine, You can say, oh, look at how I looked in 00:20:45.230 --> 00:20:49.240 2016, but actually that was me in 1981 or something. 00:20:49.540 --> 00:20:49.780 Sure. 00:20:50.220 --> 00:20:51.300 Some more disappointments. 00:20:51.740 --> 00:20:53.080 Yeah, I want another one. 00:20:53.280 --> 00:20:58.740 If you lose the proof or if you lose the original document, well, then you're 00:20:58.740 --> 00:21:02.140 screwed, right? Because if you have the hash, you cannot reconstruct the document. 00:21:02.420 --> 00:21:02.760 Right. 00:21:02.920 --> 00:21:06.780 And if you just have the hash, I don't think you can still figure out how to 00:21:06.780 --> 00:21:09.180 connect that to the thing in the blockchain. You need all these intermediate 00:21:09.180 --> 00:21:09.980 steps of the tree. 00:21:10.700 --> 00:21:15.460 Yeah, you need the document in order to prove that the hash matches the document 00:21:15.460 --> 00:21:21.040 by just hashing the document again. Plus you need all sorts of extra info to find 00:21:21.040 --> 00:21:21.680 it in the blockchain. 00:21:21.900 --> 00:21:24.480 Sure, yeah. Yeah, that's what you downloaded and hopefully saved in a file. 00:21:24.720 --> 00:21:25.260 Yeah, okay. 00:21:25.480 --> 00:21:30.030 And the last thing, that's kind of a bummer. You can't really prove that a 00:21:30.030 --> 00:21:35.670 website is real in general. It's very difficult. So if, let's say there's a tweet 00:21:35.670 --> 00:21:41.470 and the tweet has a URL and... If I give that to you, 00:21:41.730 --> 00:21:46.390 you have no way of, like, I cannot prove to you that that URL really contains 00:21:46.390 --> 00:21:50.260 that tweet. I mean, you can go to it yourself, but that's the only way you can 00:21:50.260 --> 00:21:54.780 find out. And so that's a problem if 10 years from now I want to prove that a 00:21:54.780 --> 00:21:59.660 certain tweet was real. If it's still there, then I can prove that it existed. So 00:21:59.660 --> 00:22:04.140 I can make a timestamp of basically the website as the document looks. And then, 00:22:04.240 --> 00:22:09.020 you know, today you look at it again and you can see, well, I'm seeing the same text. 00:22:09.700 --> 00:22:12.100 So how would you fake that a website existed then? 00:22:12.930 --> 00:22:17.570 I can just edit some HTML and make a different tweet, right? I can make a tweet. 00:22:17.790 --> 00:22:21.270 I can make a website that shows a tweet. But the tweet could be complete 00:22:21.270 --> 00:22:25.990 nonsense. So I have no way to prove that. But if the tweet didn't change, then I 00:22:25.990 --> 00:22:30.490 can prove it. Right. But the problem is, of course, you can delete tweets. So 00:22:30.490 --> 00:22:34.530 that's why you have things like the web archive. So you can make a timestamp of a 00:22:34.530 --> 00:22:39.840 tweet on the web archive. And if the web archive is still out there, when you 00:22:39.840 --> 00:22:44.730 check the evidence, then you can prove that the tweet existed. But if the tweeter 00:22:44.730 --> 00:22:48.630 deletes that tweet and gets rid of the web archive, then you're screwed. 00:22:49.050 --> 00:22:51.470