WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:18.420 --> 00:00:20.600 Live from Utrecht, this is Bitcoin. 00:00:21.420 --> 00:00:21.860 Explained. 00:00:22.120 --> 00:00:22.440 Hey, Sjors. 00:00:23.060 --> 00:00:23.540 Yo, yo. 00:00:24.340 --> 00:00:25.780 Are you going to do the jingle again? 00:00:26.140 --> 00:00:31.460 I am not, but I know now that you are the best ad reader, so please read the ad. 00:00:33.270 --> 00:00:38.070 Dear listener, are you looking for a hardware wallet? Well, you're in luck, 00:00:38.230 --> 00:00:42.590 because our sponsor, Coinkite, produces hardware wallets. They're called the 00:00:42.590 --> 00:00:46.350 COLDCARD. They also have all kinds of other hardware stuff. Sjors, do you know 00:00:46.350 --> 00:00:50.690 what else they have? They have the OPENDIME. They have the BLOCKCLOCK, I think, right? 00:00:51.150 --> 00:00:51.770 SATSCARD. 00:00:52.130 --> 00:00:56.050 SATSCARD. They got everything you need. What a coincidence. That's our sponsor, 00:00:56.170 --> 00:00:56.610 Coinkite. 00:00:58.340 --> 00:01:02.440 All right, Sjors. That was my read. Hey, that's an improvement compared to last 00:01:02.440 --> 00:01:03.000 week, I think. 00:01:03.140 --> 00:01:03.560 Yeah, probably. 00:01:03.860 --> 00:01:05.080 What do you think? We're getting there. 00:01:06.880 --> 00:01:08.240 So, Aaron, you wrote a book. 00:01:08.420 --> 00:01:09.580 Yeah. Oh, yes, I did. 00:01:09.740 --> 00:01:10.060 Cool. 00:01:10.740 --> 00:01:15.780 Well, at the time of recording, it's almost published. So we're publishing it 00:01:15.780 --> 00:01:21.190 tomorrow, January 3rd. But that's like midnight actually UTC. So it's like our, 00:01:21.350 --> 00:01:26.250 it's one our time. So in a couple of hours, my book will be live. Yeah. So that's 00:01:26.250 --> 00:01:31.860 kind of cool. It is called the Genesis Book, Sjors, and it tells the, the 00:01:31.950 --> 00:01:36.750 prehistory of Bitcoin, the origin story of Bitcoin. It's the story of the people 00:01:36.750 --> 00:01:42.270 and projects that inspired Bitcoin. So Sjors, to celebrate that, 00:01:42.490 --> 00:01:45.530 we're going to discuss some of the topics from my book. 00:01:45.690 --> 00:01:46.210 That's right. 00:01:46.390 --> 00:01:52.310 So it's actually kind of for the first time, I think, not really an episode 00:01:52.310 --> 00:01:54.010 about Bitcoin. Have we done something about... 00:01:54.010 --> 00:01:56.230 Well, we've done an episode about DigiCash. 00:01:57.090 --> 00:02:01.690 Well, hang on. We also did the episode about the Tornado Cash. That was actually 00:02:01.690 --> 00:02:02.810 not about Bitcoin, kind of. 00:02:02.950 --> 00:02:03.270 Exactly. 00:02:03.650 --> 00:02:03.910 Anyways. 00:02:04.880 --> 00:02:07.540 And we'll still cover things that are very relevant to Bitcoin. 00:02:07.800 --> 00:02:11.680 Right. Well, my entire book is very relevant to Bitcoin. Everything in my book is 00:02:11.680 --> 00:02:14.720 relevant to Bitcoin. So, of course, also what we're going to discuss. 00:02:14.960 --> 00:02:15.260 Excellent. 00:02:16.530 --> 00:02:19.990 Did I mention it's called the Genesis Book? And you can find it on the Bitcoin 00:02:19.990 --> 00:02:23.010 magazine store and Amazon and I don't know where else. 00:02:23.430 --> 00:02:23.910 Sounds good. 00:02:24.430 --> 00:02:30.710 I think thegenesisbook.com should be live by the time you listen to this, hopefully. 00:02:31.810 --> 00:02:32.370 All right. 00:02:32.730 --> 00:02:35.730 You want to know anything more about where you can find my book, Sjors? 00:02:35.950 --> 00:02:37.730 No, we will put it in the show notes. 00:02:37.850 --> 00:02:43.310 Okay, we'll go to the episode then. So yeah, we're going to discuss. So, okay. I 00:02:43.310 --> 00:02:48.830 discuss in my book, there are sort of five main digital cash projects that sort 00:02:48.830 --> 00:02:50.790 of precursors to Bitcoin in a way. 00:02:52.130 --> 00:02:56.790 There are more and there's also, there's a lot more in the book, Sjors. There's 00:02:56.790 --> 00:03:00.290 all kinds of background and stories and colors and... 00:03:00.490 --> 00:03:03.350 Yeah, from the parts I've read, you... 00:03:03.350 --> 00:03:04.950 Adventures and... 00:03:05.270 --> 00:03:11.070 Yeah, from what I've been reading, you cover Austrian economic stories and sort 00:03:11.070 --> 00:03:16.890 of alternate the digital money story versus the political story. 00:03:17.070 --> 00:03:20.650 Anyway, enough with the shilling. Let's get to the actual episode. So there's 00:03:20.650 --> 00:03:26.480 five electronic cash projects in the book that sort of 00:03:26.480 --> 00:03:32.000 have a bigger focus than some of the more minor ones. So the first one of that is 00:03:32.000 --> 00:03:36.480 eCash, which was produced by DigiCash. We're not going to talk about that because 00:03:36.480 --> 00:03:41.880 we kind of already did in episode 52, which was about, what was it about? 00:03:42.020 --> 00:03:42.520 Fedimint, right? 00:03:43.040 --> 00:03:48.280 Yeah, in episode 52 of Fedimint, we start all the way back with how David Chaum's 00:03:48.420 --> 00:03:53.600 eCash works, how blinded signatures work. Definitely recommended listening. And 00:03:53.600 --> 00:03:57.300 then we go all the way to how that's now applied to, well. 00:03:58.650 --> 00:04:00.190 Fedimints and Cashu. 00:04:03.010 --> 00:04:07.000 We're going to skip that one. We're not going to talk about that again. Instead, 00:04:07.140 --> 00:04:11.940 this episode will be about Hashcash and bit gold. I think this will be sort of... 00:04:11.940 --> 00:04:15.180 I don't know how we're going to do this format because usually I'm kind of the 00:04:15.180 --> 00:04:19.280 one who asks questions. We just still do that. I don't know. We'll figure it out, 00:04:19.360 --> 00:04:22.240 I think. Actually, I have no idea how to do this now. 00:04:22.700 --> 00:04:27.100 Well, you should tell a little bit of the story, and then we'll get to some of 00:04:27.100 --> 00:04:28.900 the technical juicy bits. 00:04:29.020 --> 00:04:29.540 Yeah, that works. 00:04:29.680 --> 00:04:31.180 Where I might have some opinions, too. 00:04:31.680 --> 00:04:37.500 Okay, cool, yeah. So the first one is Hashcash. So the background here is... 00:04:37.600 --> 00:04:43.480 So in the 90s, the internet was becoming more popular, and also there was the 00:04:43.480 --> 00:04:47.460 Cypherpunks mailing list. And they had... First of all, they had their own 00:04:47.460 --> 00:04:48.920 mailing list where they were discussing... 00:04:50.130 --> 00:04:56.090 privacy technologies, but also more ideological types of posts or how to create 00:04:56.090 --> 00:04:59.990 digital cash, of course, and all these kinds of discussions. And they were also, 00:05:00.150 --> 00:05:03.590 a bunch of the cypherpunks were running remailers. So this was sort of the 00:05:03.590 --> 00:05:08.570 precursor of Tor. So it was a way to send an email anonymously, send an email 00:05:08.570 --> 00:05:12.250 without the recipients knowing where the email came from. 00:05:13.770 --> 00:05:18.010 The problem was that spam was becoming popular around this time as well. 00:05:20.320 --> 00:05:24.180 the Cypherpunk mailing list itself was being spammed. Anyone else who had an 00:05:24.180 --> 00:05:28.720 email address was being spammed. And especially also these remails or remailers 00:05:28.720 --> 00:05:34.640 were starting to be spammed to the extent that it was becoming burdensome to run 00:05:34.640 --> 00:05:37.900 one. So it was potentially an attack on these remailers. 00:05:39.430 --> 00:05:43.370 Either it was a spam attack that remailers were being abused for, or maybe it was 00:05:43.370 --> 00:05:47.590 just an attack on the remailers themselves as sort of a denial of service type of 00:05:47.590 --> 00:05:53.590 situation. So people wanted to create, Cypherpunks specifically wanted to create 00:05:53.590 --> 00:05:54.310 digital cash. 00:05:54.590 --> 00:05:59.170 And I think, well, one step back, I think they also, they wanted to fix the spam 00:05:59.170 --> 00:06:02.330 problem, right? With digital cash maybe in the back of their mind. 00:06:02.490 --> 00:06:06.590 Sorry, I said digital cash. I meant digital postage. And that's what you're getting. 00:06:06.730 --> 00:06:10.250 Yes, digital postage stamps. But it might be interesting, something you also 00:06:10.250 --> 00:06:15.390 mentioned in the book. is that there was a worry that if the cypherpunks didn't 00:06:15.390 --> 00:06:19.050 fix this problem, then governments would step in and they would start dealing 00:06:19.050 --> 00:06:23.710 with spam. And this would be a problem because then you would get... 00:06:23.810 --> 00:06:28.470 If governments have to fight spam, then the way they would probably do that is by 00:06:28.470 --> 00:06:34.430 de-anonymizing everyone and basically KYC-ing email to the extent of where 00:06:34.430 --> 00:06:35.950 if there's a spammer, they know who they are. 00:06:36.370 --> 00:06:40.470 Yeah, plus the government would then have to make a judgment call about what is 00:06:40.470 --> 00:06:43.650 spam and what kind of relevant to Bitcoin these days, actually, with the whole 00:06:43.650 --> 00:06:47.930 ordinal thing. But yeah, then governments have to make a judgment call about what 00:06:47.930 --> 00:06:52.170 is spam. So what actually is legal. And then by the time they can find a spammer, 00:06:52.250 --> 00:06:54.310 yeah, there would have to be some sort of identification. 00:06:54.610 --> 00:06:58.110 And they would have to ban anonymous email, which is, you know, the kind of thing 00:06:58.110 --> 00:06:58.750 they were trying to do. 00:06:59.810 --> 00:07:04.770 Right. So the cypherpunks didn't like this. And specifically, Adam Back didn't 00:07:04.770 --> 00:07:08.430 like this. Adam Back was, of course, one of these cypherpunks. I don't think he 00:07:08.430 --> 00:07:13.920 needs an introduction to anyone who listens to this podcast. So Adam Back wanted 00:07:13.920 --> 00:07:19.040 to come up with digital postage. Maybe should I... 00:07:19.320 --> 00:07:23.660 First, I think we should go back in time, right? Because everybody talks about 00:07:23.660 --> 00:07:27.660 Hashcash and how Adam Back invented that, and he did. But it was not the first 00:07:27.660 --> 00:07:30.020 time it was invented, as often happens in history. 00:07:30.260 --> 00:07:34.020 Yeah, I was also considering if I should talk about the other ways they were 00:07:34.020 --> 00:07:39.120 thinking about digital postage. But I think we should skip that, right? That's 00:07:39.120 --> 00:07:40.200 what you can find in the book. 00:07:40.600 --> 00:07:41.040 Exactly. 00:07:41.360 --> 00:07:45.960 Okay, so yeah. Okay, so shall I hand it to you here? Because yes. So actually, 00:07:46.200 --> 00:07:51.180 Adam Back was not the first person to invent digital postage. 00:07:51.980 --> 00:07:56.260 He did think he was, like he was not aware of the previous proposal, but there 00:07:56.260 --> 00:08:01.240 was actually another proposal that's a bit older and quite similar to Adam Back's 00:08:01.240 --> 00:08:06.200 proposal, which was the names from the top of my head. 00:08:06.640 --> 00:08:07.540 Dwork and Naor. 00:08:07.900 --> 00:08:10.240 Yeah, I was thinking of the first name, but yeah, their last names were 00:08:10.240 --> 00:08:14.450 definitely Dwork and Naor. Moni Naor and Cynthia Dwork I think 00:08:14.450 --> 00:08:19.710 yeah and they did not come from it from a cypherpunk background they came from it 00:08:19.710 --> 00:08:25.390 with a just hey we are people using email and we don't like spam background right 00:08:25.390 --> 00:08:26.330 and so 00:08:26.360 --> 00:08:29.280 well they were for IBM right they were 00:08:31.120 --> 00:08:36.060 Yeah, they weren't random people, but they were not saying, how can we prevent 00:08:36.060 --> 00:08:40.180 the government coming into this email world? It's just like, how do we get rid of spam? 00:08:41.420 --> 00:08:46.370 And so they invented, essentially they came up with the idea of introducing proof 00:08:46.370 --> 00:08:52.000 of work for email, and they came up with three different... work algorithms yeah 00:08:52.000 --> 00:08:55.580 and to be clear the term proof of work didn't exist yet at this time 00:08:55.580 --> 00:09:00.220 I don't know exactly what they call it but something along the lines of like a 00:09:00.220 --> 00:09:06.080 challenge or but basically they picked three algorithms and I 00:09:06.080 --> 00:09:12.070 think one of them boiled down to finding If you take a number and you want to 00:09:12.070 --> 00:09:16.270 figure out which two primes are necessary, can be multiplied to get to the 00:09:16.270 --> 00:09:20.490 number. So let's say you pick the number 100 and you say, tell me which two prime 00:09:20.490 --> 00:09:25.690 numbers multiply to 100. And you would say, I don't know, because it's 10 times 00:09:25.690 --> 00:09:28.370 10. So that's not, those are not prime. 00:09:28.670 --> 00:09:29.570 Kind of a bad example. 00:09:29.870 --> 00:09:33.090 No, it's a fine example, but it shows that as soon as you give me the right 00:09:33.090 --> 00:09:37.710 answer, I can very quickly verify that yes, these two numbers multiply. to this 00:09:37.710 --> 00:09:41.290 total. Actually, I think you didn't have to find prime numbers. It's just modulo 00:09:41.290 --> 00:09:41.850 prime number. 00:09:43.210 --> 00:09:47.930 I think the way it works is you have two very big prime numbers. These are 00:09:47.930 --> 00:09:53.270 factored into another big number. And then the big number is, 00:09:53.410 --> 00:09:56.670 it can only be produced by two specific prime numbers then, right? 00:09:56.810 --> 00:09:58.570 I think that's what, that's RSA. 00:09:58.930 --> 00:09:59.410 Yes. 00:09:59.530 --> 00:10:05.170 But not what this concept. I think this was much simpler. This was something 00:10:05.170 --> 00:10:10.230 called modulo prime number. So if you take a much smaller number, we know the 00:10:10.230 --> 00:10:15.810 number 13 is prime, right? And so you would say, okay, here's the number 10. 00:10:17.410 --> 00:10:22.930 Find me two numbers that you can multiply to get the number 10, but you can 00:10:22.930 --> 00:10:28.640 multiply and then you do modulo 13. So you can say, this is 00:10:28.640 --> 00:10:33.420 not very good in math, but if you do 3 times 4, that's 12, so that's not enough. 00:10:33.600 --> 00:10:38.960 If you do 3 times 5, that's 15, modulo 13 is 2, right? So you can do etc. etc. 00:10:39.080 --> 00:10:42.380 You keep looking for this number that if you go around in circles around this 00:10:42.380 --> 00:10:44.220 prime number gets you the correct result. 00:10:45.280 --> 00:10:49.220 Okay, we're getting very into the weeds now. Let's get back to the main road. So 00:10:49.220 --> 00:10:50.280 they had three ideas. 00:10:50.620 --> 00:10:54.500 Exactly. So this is one of them. And the key part is that it takes a while to 00:10:54.500 --> 00:10:58.960 find these numbers, but it's very quick to check. You just multiply modulo and 00:10:58.960 --> 00:11:04.300 you're done. And they had two other algorithms that I don't want to go into also 00:11:04.300 --> 00:11:08.260 because I don't know them, but they had an interesting property from them is that 00:11:08.260 --> 00:11:13.460 you could build an exception into it. So basically saying, well, if you're the 00:11:13.460 --> 00:11:17.720 mailing list operator, then you can use this special key and you can bypass the 00:11:17.720 --> 00:11:22.700 work. I don't know whether that would be practical or not, but that's sort of 00:11:22.700 --> 00:11:23.300 what they came up with. 00:11:23.780 --> 00:11:24.760 Right, the backdoor function. 00:11:25.480 --> 00:11:25.600 Yeah. 00:11:27.320 --> 00:11:33.020 The points being here, though, so was Naor and Dwork also, the 00:11:33.020 --> 00:11:37.820 idea they came up with is that whatever calculation you have to make, you have to 00:11:37.820 --> 00:11:41.100 make it in combination with some data from the email itself. 00:11:41.560 --> 00:11:45.240 Yes, because you can prove that you did a bunch of work, but if that's unrelated 00:11:45.240 --> 00:11:48.580 to your email, you would just reuse the same work. So you have to make sure that 00:11:48.580 --> 00:11:54.360 the work is always a function of the email itself. And ironically, they 00:11:54.360 --> 00:11:58.120 discovered the use of hash functions for that, or they knew that you needed hash 00:11:58.120 --> 00:12:02.280 functions for that part. So you take the hash of the email, and then you use the 00:12:02.280 --> 00:12:04.840 hash as the starting point of your challenge. 00:12:05.260 --> 00:12:07.500 Oh, they did use the hash for that part? 00:12:07.680 --> 00:12:07.820 Yeah. 00:12:07.940 --> 00:12:09.700 Oh, I didn't know that. That's interesting. 00:12:11.490 --> 00:12:17.390 Because we should maybe spell this out for those who haven't realized this. So 00:12:17.390 --> 00:12:22.170 Naor and Dwork were not using hashes for the proof of work. They were using, 00:12:22.370 --> 00:12:25.090 what's it called? Is there a better term for what they were? 00:12:25.090 --> 00:12:26.250 They were just using math problems. 00:12:26.990 --> 00:12:32.840 Right. Now the idea was still very similar to, I mean, 00:12:33.000 --> 00:12:35.640 I think most people that listen sort of know where proof of work came from. 00:12:35.780 --> 00:12:39.180 That's why we're sort of skipping some parts maybe, but we should actually spell 00:12:39.180 --> 00:12:44.910 it out. So the idea was, If you attach a little bit of proof of work to an email, 00:12:45.270 --> 00:12:50.390 then most people that want to send an email, that's not really a problem. That's 00:12:50.390 --> 00:12:55.010 like a couple of seconds of computing time. However, if you're a spammer that 00:12:55.010 --> 00:12:59.150 wants to send tens of thousands or maybe even millions of emails, which you 00:12:59.150 --> 00:13:03.150 usually have to do to be a profitable spammer, then it becomes so expensive that 00:13:03.150 --> 00:13:06.810 it's not worth it anymore. So that's how it's posted. So it's different in 00:13:06.810 --> 00:13:11.270 postage in the sense that... You're not buying it from anyone. And also whoever 00:13:11.270 --> 00:13:15.130 you're sending the email to is not getting the money or anything like that. It's 00:13:15.130 --> 00:13:20.470 just you're proving that you spend some resources, some energy, and that way it's 00:13:20.470 --> 00:13:23.230 too expensive for a spammer to be a spammer. 00:13:23.410 --> 00:13:24.090 Yes, exactly. 00:13:24.830 --> 00:13:29.490 Okay, so that's what Naor and Dwork essentially came up with. 00:13:30.770 --> 00:13:32.030 This was in 1992. 00:13:33.230 --> 00:13:38.250 But then independently, basically, it was sort of a parallel invention. Not 00:13:38.250 --> 00:13:41.430 exactly parallel, though. You know, some time difference. But Adam Back was not 00:13:41.430 --> 00:13:45.930 aware of this solution. So when they were discussing this problem on the 00:13:45.930 --> 00:13:51.190 Cypherpunks list, they didn't know it was actually kind of a solved problem. But 00:13:51.190 --> 00:13:54.330 then he reinvented something very similar. 00:13:54.570 --> 00:13:58.970 Yes, but then using a hash function. SHA-1 in this case, but that doesn't really matter. 00:14:00.260 --> 00:14:06.150 And that's... The thing is, it's not actually better or worse than 00:14:06.150 --> 00:14:08.330 the design that was made before. 00:14:08.590 --> 00:14:09.610 Can you explain how it works? 00:14:10.010 --> 00:14:15.690 Okay. So you basically take some aspects of the email, as we said before, and 00:14:15.690 --> 00:14:20.230 then you add a nonce to it. A nonce is a number that you pick randomly. It 00:14:20.230 --> 00:14:24.030 doesn't matter what it is. But you have to pick it such that the resulting hash 00:14:24.030 --> 00:14:25.970 starts with a certain number of zeros. 00:14:26.570 --> 00:14:27.090 Right. 00:14:27.390 --> 00:14:31.200 Notice that in Bitcoin Core, the hash... does not only start with a number, 00:14:31.440 --> 00:14:34.940 certain numbers of zeros, but actually has a specific value that it has to stay 00:14:34.940 --> 00:14:36.980 under. But it's roughly the same idea. 00:14:37.380 --> 00:14:42.970 Right. So then, yeah, you would send the email. You include this hash, and then 00:14:42.970 --> 00:14:48.070 the recipient would check if there's actually a valid hash in it. If not, the 00:14:48.070 --> 00:14:48.910 email would just bounce. 00:14:49.410 --> 00:14:49.650 Exactly. 00:14:49.990 --> 00:14:55.790 I guess that was the same with Naor and Dwork's system. I didn't spell that out, 00:14:55.970 --> 00:14:56.910 but same idea, basically. 00:14:57.230 --> 00:15:00.210 Yep, they both had the concept of difficulty, essentially, where you can make the 00:15:00.210 --> 00:15:04.690 hash more or less difficult, depending on what your perceived spam problem is. 00:15:04.910 --> 00:15:09.080 Yeah. So anyways, the recipient would then say, or in the... case of the 00:15:09.080 --> 00:15:13.420 remailers, right, which I mentioned earlier, the remailer would check, does this 00:15:13.420 --> 00:15:18.120 have a valid hash? If not, just reject it. And if so, it's forwarded to whoever 00:15:18.120 --> 00:15:23.540 it needs to be forwarded to. So that's basically the idea of Hashcash, right? 00:15:23.800 --> 00:15:28.320 That we forget about anything? Yeah, so that's Hashcash. 00:15:29.760 --> 00:15:35.640 I think that you, well, I can tell you that it, in 00:15:35.640 --> 00:15:41.640 the early days, there was some adoption of it. So, Apache used... 00:15:41.640 --> 00:15:42.880 Is that how I pronounce it, actually? 00:15:43.020 --> 00:15:44.860 I think Apache SpamAssassin. 00:15:45.100 --> 00:15:50.240 Yeah, they used it in SpamAssassin. And Microsoft recreated something very 00:15:50.240 --> 00:15:53.600 similar. Like, it was incompatible with, you know, different standards, but 00:15:53.600 --> 00:15:54.860 basically the same idea again. 00:15:56.160 --> 00:15:58.600 And then more recently... 00:15:58.600 --> 00:16:02.880 And those two are completely unused right now because [unclear] removed it again 00:16:02.880 --> 00:16:07.920 and the Microsoft thing doesn't exist anymore. More recently, as you were getting 00:16:07.920 --> 00:16:12.960 to, Tor has been using proof of work. So again, it's a completely different 00:16:12.960 --> 00:16:18.180 algorithm. But it is an example of proof-of-work being used outside of a 00:16:18.180 --> 00:16:22.660 cryptocurrency. So where it's not used to produce value, it's simply to prevent 00:16:22.660 --> 00:16:26.260 spam. So this concept is still alive and well. 00:16:27.070 --> 00:16:27.630 Right. 00:16:27.810 --> 00:16:32.170 Now, one interesting aspect I wanted to talk about... 00:16:32.200 --> 00:16:38.020 This is why we're talking about it in a Bitcoin podcast. Why we're focusing on 00:16:38.020 --> 00:16:42.070 Hashcash more than the Naor-Dwork concept, right? Is that where you're getting at? 00:16:42.470 --> 00:16:45.930 Yeah, well, there's an interesting kind of a historical coincidence, I would 00:16:45.930 --> 00:16:51.150 almost say, and this is something you pointed out earlier that I think Adam Back 00:16:51.150 --> 00:16:56.910 was aware of, and he pointed it out, which is to say that there are two 00:16:56.910 --> 00:17:01.430 kinds of, although multiple kinds of works, proof of work, but in particular, two 00:17:01.430 --> 00:17:05.230 different kinds are stochastic and non-stochastic proof of work. And that's a 00:17:05.230 --> 00:17:10.840 distinction I hadn't really thought about. But the idea here is that with 00:17:10.840 --> 00:17:16.500 a hash function, you may or may not get the right result, and statistically it 00:17:16.500 --> 00:17:20.300 will take a certain amount of time before you find a solution, but it's random. 00:17:20.560 --> 00:17:24.460 So sometimes you find the right solution instantly, other times it takes a very 00:17:24.460 --> 00:17:28.940 long time. Whereas with these earlier algorithms... 00:17:31.580 --> 00:17:36.460 there's sort of a guaranteed time of how long it takes to find the square root, 00:17:36.600 --> 00:17:40.320 for example, of two numbers. So I suppose you could maybe make it random, but 00:17:40.390 --> 00:17:44.390 assuming you use a standard algorithm, it'll take a fixed amount of time to find 00:17:44.390 --> 00:17:46.470 a solution. And you might think... 00:17:46.470 --> 00:17:49.670 Yeah, let me give an analogy that I've used, not in the book, actually, I think, 00:17:49.770 --> 00:17:53.770 but in an article I wrote earlier. It's kind of the difference between, let's say 00:17:53.770 --> 00:17:59.690 there's 100 lottery tickets. And one person buys 40 tickets and 00:17:59.690 --> 00:18:05.370 another buys 60. So now the person that has 60 has more chance to win, 60%. But 00:18:05.370 --> 00:18:11.270 the person that bought 40 still has 40% to win as well. While if you take 00:18:11.270 --> 00:18:17.110 two cyclists and one of them can ride his bike 60 miles 00:18:17.110 --> 00:18:22.410 an hour and the other 40 miles. then anytime they do a race, the one that can 00:18:22.410 --> 00:18:24.950 cycle 60 miles an hour will just win, like every time. 00:18:25.270 --> 00:18:25.510 Exactly. 00:18:27.340 --> 00:18:32.680 Every time the same cyclist will win, there's no 40% chance that a 40 mile per 00:18:32.680 --> 00:18:34.840 hour cyclist will ever win. It's just not going to happen. 00:18:35.100 --> 00:18:38.620 And so if you translate that to the context of Bitcoin mining as it is today, 00:18:38.820 --> 00:18:41.560 let's say we had picked a non-stochastic form of proof of work. 00:18:43.160 --> 00:18:47.060 based on that original paper. So basically, if Adam Back had known about the 00:18:47.060 --> 00:18:50.040 original paper and had not bothered to implement something based on a hash 00:18:50.040 --> 00:18:55.140 function, because, you know, there's already a solution out there, then you would 00:18:55.140 --> 00:18:59.680 have the biggest miner, whoever that is, will just always find the next block 00:18:59.680 --> 00:19:02.500 first, because they would always find that big prime number or whatever the 00:19:02.500 --> 00:19:04.340 challenge is. They would always find it first. 00:19:04.560 --> 00:19:08.720 Right. It will be like that 60 mile cyclist rather than like currently Bitcoin 00:19:08.720 --> 00:19:13.160 mining kind of works like this lottery. But if the biggest miner just always 00:19:13.160 --> 00:19:16.220 wins, then you can't have Bitcoin like we have it today. 00:19:16.380 --> 00:19:19.220 And of course, we still have some centralization problems in that sense, but this 00:19:19.220 --> 00:19:23.720 would be centralization on steroids if we did not have hash-based proof of work. 00:19:23.820 --> 00:19:27.200 Yeah, basically Bitcoin wouldn't work, like not as it's designed today. 00:19:27.460 --> 00:19:30.640 Yeah, or maybe we would have figured it out and then changed it, but definitely 00:19:30.640 --> 00:19:31.900 would have been not optimal. 00:19:32.360 --> 00:19:37.720 Yeah, so essentially what you alluded to, like we may have been quite lucky in 00:19:37.720 --> 00:19:42.500 that sense that Adam Back... wasn't aware of the prior proposal, so he invented 00:19:42.500 --> 00:19:44.840 it in a way that's actually useful for Bitcoin. 00:19:45.180 --> 00:19:48.880 Exactly, but it's not something he was aware of at the time. Or at least, he 00:19:48.880 --> 00:19:49.700 didn't put it in the paper. 00:19:50.790 --> 00:19:55.470 As far as I know, and I've discussed it with him, so either my memory is failing 00:19:55.470 --> 00:20:00.490 me, but I'm pretty sure he only realized that after Bitcoin himself. He only 00:20:00.490 --> 00:20:03.970 figured that out, so that actually Hashcash specifically only works for Bitcoin. 00:20:04.390 --> 00:20:09.580 Yeah, no, that was not some sort of pre-planned thing for... Mr. Back. 00:20:09.880 --> 00:20:15.140 Yeah. Now, before we get to the next topic, which is bit gold, we should talk 00:20:15.140 --> 00:20:20.640 about something that the author of bit gold observed about proof of work. That's 00:20:20.640 --> 00:20:23.260 kind of the direction, kind of the bridge I wanted to make. 00:20:23.440 --> 00:20:25.980 Yeah, well, that is also the bridge I make in my book Sjors. 00:20:26.580 --> 00:20:26.980 Excellent. 00:20:27.240 --> 00:20:27.520 Yes. 00:20:28.090 --> 00:20:29.370 It's almost like I read it. 00:20:29.510 --> 00:20:33.510 I mean, I think, at least if we're thinking about the same thing. So yeah, you 00:20:33.510 --> 00:20:38.110 mean, so Hashcash or proof of work essentially for the first time brought 00:20:38.110 --> 00:20:43.400 something akin to digital scarcity, created something. introduce something akin 00:20:43.400 --> 00:20:49.020 to digital scarcity because there is an actual cost a physical cost 00:20:49.020 --> 00:20:54.800 energy in the real world required to produce it yeah so rather than just 00:20:54.800 --> 00:20:59.920 copying numbers you have to actually invest something real resources and that 00:20:59.920 --> 00:21:04.650 sort of creates something that you could see as digital scarcity, right? That's 00:21:04.650 --> 00:21:05.270 what you're getting at. 00:21:05.350 --> 00:21:09.250 That's not where I was getting it, though it is true. What I'm getting at is that 00:21:09.250 --> 00:21:14.790 the question is how do you define proof of work or how do you measure it? How is 00:21:14.790 --> 00:21:16.570 it different from other cryptography? 00:21:17.870 --> 00:21:22.710 This is not a bridge I make in my book, Sjors. Unless I'm completely confused 00:21:22.710 --> 00:21:23.170 where you're going. 00:21:23.230 --> 00:21:28.730 It is a new bridge, but basically Nick Szabo wrote an article about something he 00:21:28.730 --> 00:21:31.070 calls, now I lost a term, that's not smart, 00:21:33.450 --> 00:21:35.510 Oh, you mean secure benchmark functions? 00:21:35.730 --> 00:21:41.130 Yes, secure benchmark functions. So here's the thing. We know that 00:21:41.130 --> 00:21:45.230 with normal public key cryptography, for example, and with hash functions like 00:21:45.230 --> 00:21:50.850 SHA-256, we know that it's easy to verify and easy is then defined as like just 00:21:50.850 --> 00:21:56.160 takes like a very short time on a typical computer. And impossible or like, you 00:21:56.160 --> 00:22:01.840 know, would take forever effectively to hack it, to coincidentally 00:22:01.840 --> 00:22:05.800 go back from the hash to the original, from the public key to the private key, 00:22:06.060 --> 00:22:10.870 which is then called hard. But with proof of work, you're doing something that's 00:22:10.870 --> 00:22:16.850 a little bit in between. It is definitely not easy to go back to find a certain 00:22:16.850 --> 00:22:21.350 number of zeros, for example, in the proof of work, in the hash. But it's also 00:22:21.350 --> 00:22:24.830 not hard in the sense that it will not take forever. In fact, you don't want it 00:22:24.830 --> 00:22:28.530 to take forever because then you cannot, you know, make the proof of work on your 00:22:28.530 --> 00:22:31.940 email if it would take forever to make the proof of work. So then the question 00:22:31.940 --> 00:22:37.620 is, how do you sort of define that? How hard is hard enough, right? 00:22:37.980 --> 00:22:41.320 It should not be too easy, it should not be too hard. And Nick Szabo wrote this 00:22:41.320 --> 00:22:46.400 paper, well, this article about it, basically, the coining a term secure 00:22:46.400 --> 00:22:52.070 benchmark function. Now, if you look at the 1992 paper about proof-of-work, they 00:22:52.070 --> 00:22:56.490 were also informally defining it as something that's not too easy, not too hard, 00:22:57.090 --> 00:23:00.950 somewhere in between. So Szabo put it in slightly more mathy terms. 00:23:02.330 --> 00:23:08.130 And the analogy we could get into, I guess, is the one-way function, or what it's 00:23:08.130 --> 00:23:12.070 comparing it with. So we talked about one-way functions in an earlier episode, 00:23:12.070 --> 00:23:15.990 where you actually were correct, and I was wrong. So. 00:23:16.210 --> 00:23:17.170 I remember that. 00:23:17.430 --> 00:23:20.190 Good. Keep enjoying that feeling. 00:23:20.370 --> 00:23:23.990 Yes. I think everyone heard that, right? Can you repeat it one more time? 00:23:25.320 --> 00:23:29.660 So let's just try and explain it correctly because I don't even remember exactly 00:23:29.660 --> 00:23:30.240 what I was saying. 00:23:30.420 --> 00:23:30.740 Go on. 00:23:31.480 --> 00:23:36.990 A one-way function is a function that is 00:23:37.400 --> 00:23:43.220 very easy to go in one way. Like checking that a 00:23:43.220 --> 00:23:48.200 hash is correct. but very hard to go the other way. which is like trying to 00:23:48.200 --> 00:23:52.060 produce a fake hash, a fake original, basically. 00:23:53.540 --> 00:23:59.520 And there are a bunch of one-way functions out there. One is 00:23:59.520 --> 00:24:04.310 finding the factors in a big number, or these prime factors, as you mentioned, 00:24:04.390 --> 00:24:08.580 with RSA. Another is a discrete logarithm problem, or that's sort of a more 00:24:08.580 --> 00:24:13.670 generic one, but that is used for public and private key cryptography, like the 00:24:13.670 --> 00:24:18.780 elliptic curve. And then there's cryptographic hash functions, like SHA-256, 00:24:18.920 --> 00:24:24.300 which so far has not been broken. The problem is there is no mathematical proof 00:24:24.300 --> 00:24:29.700 that this actually exists. So we think these functions are one way, and 00:24:29.700 --> 00:24:34.740 they better be one way, but it may turn out that some mathematician somewhere 00:24:34.740 --> 00:24:39.310 proves that they're not. And then you get into the whole P is NP stuff that we're 00:24:39.310 --> 00:24:39.990 not going to get into. 00:24:41.410 --> 00:24:45.730 Now, there is a special kind of one-way function called the trapdoor one-way 00:24:45.730 --> 00:24:51.310 function. That is public key, private key cryptography, where it is very hard to 00:24:51.310 --> 00:24:56.470 go back. It is very hard to go from a public key to a private key. In fact, take 00:24:56.470 --> 00:25:02.070 the age of the universe, unless you know the private key. Then it's trivial. 00:25:02.830 --> 00:25:03.290 Yes. 00:25:04.340 --> 00:25:08.000 I think I said it wrong. It's very hard to fake a signature, for example, but if 00:25:08.000 --> 00:25:11.040 you know the private key, then it's trivial to make the signature. And that is 00:25:11.040 --> 00:25:14.600 the trapdoor, the secret passageway through which you can do things. So that was 00:25:14.600 --> 00:25:16.620 the distinction we wanted to make back then. 00:25:17.770 --> 00:25:21.450 There actually is. There's a chapter about this in my book as well. 00:25:21.910 --> 00:25:27.440 Yeah, so then the secure benchmark function has to be less 00:25:27.440 --> 00:25:31.930 strenuous. It can't be a one-way function, because then... you'll never go back. 00:25:32.310 --> 00:25:36.470 So if you go to the Wikipedia article about one-way functions, it defines this 00:25:36.470 --> 00:25:41.930 little thing like, okay, for any blah-blah-blah function that you try 00:25:41.930 --> 00:25:43.610 100,000 times or whatever, 00:25:44.910 --> 00:25:48.010 statistically you should almost never find the correct answer. That's sort of how 00:25:48.010 --> 00:25:52.870 they defined it. And then Szabo basically writes a similar formula, but then 00:25:52.870 --> 00:25:57.130 explaining what this secure benchmark function should look like. 00:25:59.380 --> 00:26:01.920 Sure, so are we still just making a bridge? 00:26:02.200 --> 00:26:02.880 Yes, we are. 00:26:02.940 --> 00:26:04.700 This is a big bridge you're building here. 00:26:04.900 --> 00:26:09.580 I'm almost done with the bridge. One thing that is interesting there is that when 00:26:09.580 --> 00:26:12.500 it comes to these one-way functions, it doesn't matter what hardware you have. 00:26:12.600 --> 00:26:15.520 They just seem like you can have the whole universe and you still cannot crack 00:26:15.520 --> 00:26:19.460 it. You can have a Dyson [unclear] and you can't crack it. But in the secure 00:26:19.460 --> 00:26:23.120 benchmark function, the device that you use, the machine that you do things on, 00:26:23.260 --> 00:26:26.940 actually matters in the math. You cannot just... abstract away the machine you 00:26:26.940 --> 00:26:31.000 have to say okay what is a realistic computer because and then you get back to 00:26:31.000 --> 00:26:36.160 the spam problem if a spammer has an ASIC a modern day ASIC and let's say the 00:26:36.160 --> 00:26:41.520 algorithm was SHA-256 instead of SHA-1 well then you as a consumer trying to send 00:26:41.520 --> 00:26:45.840 an email would have to burn your phone to the ground in order to just send an 00:26:45.840 --> 00:26:51.000