WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:18.700 --> 00:00:20.580 Live from Utrecht, this is Bitcoin 00:00:20.580 --> 00:00:22.140 Explained. 00:00:22.930 --> 00:00:27.450 Sjors, I just discovered something. I had never actually paid attention to this 00:00:27.450 --> 00:00:32.400 before, but I was scrolling through my own podcast app, and I noticed that 00:00:32.400 --> 00:00:36.940 Bitcoin Explained is getting 4.6 out of 5 stars. 00:00:37.160 --> 00:00:40.960 On your random podcast app. Because every podcast app has its own ratings. 00:00:41.360 --> 00:00:46.460 Is that how it works? Oh, I have Pocket Casts. On Pocket Casts, we get 4.6 stars 00:00:46.460 --> 00:00:51.590 out of... Oh, every single listener has left a review. We have 20 reviews. 00:00:51.750 --> 00:00:55.370 But it's even worse than that. Every podcast app has its own reviews, and then 00:00:55.370 --> 00:00:59.850 some podcast app, like Apple, will split those reviews between countries. So you 00:00:59.850 --> 00:01:04.530 might have somebody in Tanzania leaving a review, but you will never see it 00:01:04.530 --> 00:01:06.290 because we're not in Tanzania. 00:01:07.890 --> 00:01:13.350 Okay, well, I don't know what to make of 4.6. Let's see. What Bitcoin Did with 00:01:13.350 --> 00:01:14.850 Danny has 4.8. 00:01:15.520 --> 00:01:16.000 Nice. 00:01:16.500 --> 00:01:19.940 Well, no. That means Danny is doing better than us, Sjors. 00:01:20.820 --> 00:01:21.400 Oh, okay. 00:01:22.620 --> 00:01:26.180 I still have Junseth's World. Junseth's World has got zero reviews. 00:01:26.480 --> 00:01:26.980 Zero stars. 00:01:27.140 --> 00:01:28.700 Zero stars, but that's what he's going for, right? 00:01:28.700 --> 00:01:29.740 No, they wanted one star. 00:01:31.520 --> 00:01:37.320 Bitcoin Audible, 4.9. Oh, my God. Stephan Livera, 4.9. 00:01:37.560 --> 00:01:41.540 We're the lowest one, Sjors. Other than zero stars. 00:01:43.800 --> 00:01:45.960 Reckless Review got five stars. 00:01:47.490 --> 00:01:48.010 Okay. 00:01:48.090 --> 00:01:52.930 Does anyone remember what Reckless Review is? I'm still subscribed to it, but 00:01:52.930 --> 00:01:55.750 that was our goal. That was our only goal, Sjors. 00:01:55.910 --> 00:01:56.750 To surpass them. 00:01:56.930 --> 00:02:02.270 To be better, to at least meet the lowest of low bars and to be better than 00:02:02.270 --> 00:02:04.310 Reckless Review, but we failed at that even. 00:02:04.710 --> 00:02:05.830 Well, sounds good. 00:02:07.920 --> 00:02:11.860 Let's go for another five-star episode today, Sjors. What do you think? 00:02:12.100 --> 00:02:13.860 Sounds like a good plan. You know what else is annoying? 00:02:14.340 --> 00:02:14.980 What's annoying? 00:02:15.100 --> 00:02:16.280 Smoke alarm batteries. 00:02:16.720 --> 00:02:17.100 Why? 00:02:17.870 --> 00:02:22.670 Well, because the way you find out that your smoke alarm battery is empty is at 3 00:02:22.670 --> 00:02:25.970 o'clock in the night when it starts beeping and doesn't stop until you find a 00:02:25.970 --> 00:02:27.530 ladder and remove the smoke alarm. 00:02:29.590 --> 00:02:31.490 Repeat that. The only... 00:02:31.490 --> 00:02:36.020 The way you find out that your smoke alarm battery is empty is that it starts 00:02:36.020 --> 00:02:40.840 beeping at you in the middle of the night. And then... You buy a new battery and 00:02:40.840 --> 00:02:45.200 the battery says, oh, don't worry, you can keep this battery in its packaging for 00:02:45.200 --> 00:02:50.200 10 years or for five years or whatever. Of course it doesn't. So you don't want 00:02:50.200 --> 00:02:55.960 to buy the battery when the last one runs out. Because by the time you need the 00:02:55.960 --> 00:02:59.120 new battery, the old battery that you kept in your closet is going to be leaking. 00:03:01.630 --> 00:03:04.390 Why are we talking about smoke alarm batteries? 00:03:04.650 --> 00:03:07.970 Because they are the same battery that fits on the little device that is in front of you. 00:03:09.040 --> 00:03:13.340 This beautiful device right here uses the same battery as a smoke alarm. 00:03:13.580 --> 00:03:14.260 That's right. 00:03:14.400 --> 00:03:19.000 What is this device? It's, oh my God, it's like a piece of art that I hold in my 00:03:19.000 --> 00:03:19.780 hands right now. 00:03:20.220 --> 00:03:20.700 Yes. 00:03:20.920 --> 00:03:24.350 It's sublime. Tell me what this is, Sjors. 00:03:24.590 --> 00:03:29.070 That is the COLDCARD Q. Also the BlackBerry. No, it's not a BlackBerry. It looks 00:03:29.070 --> 00:03:29.650 like a BlackBerry. 00:03:29.830 --> 00:03:35.470 The COLDCARD by CoinKite happens to be our amazing sponsors as well. 00:03:35.870 --> 00:03:39.590 Pure coincidence, I'm sure, that it's laying here when you bring that up. 00:03:39.790 --> 00:03:40.250 Yes. 00:03:40.310 --> 00:03:43.410 You just have it here as a piece of art in your living room. 00:03:43.530 --> 00:03:43.870 Exactly. 00:03:44.330 --> 00:03:46.750 For people to admire when they walk in. 00:03:46.890 --> 00:03:47.630 Next to the anvil. 00:03:49.540 --> 00:03:54.200 Seriously, though, COLDCARDs, the hardware wallet that you need to store your 00:03:54.200 --> 00:03:55.600 Bitcoin. Get it today. 00:03:55.860 --> 00:03:57.120 Thanks for sponsoring us. 00:03:57.500 --> 00:04:02.780 Alrighty. Now, Sjors, today we had a very hard time finding a topic to talk 00:04:02.780 --> 00:04:08.200 about. We had to look all over the internet to find anything, something technical 00:04:08.200 --> 00:04:13.790 that people were talking about. Finally, we found this one obscure comment 00:04:13.790 --> 00:04:17.400 somewhere on GitHub about the OP_RETURN limit. 00:04:17.580 --> 00:04:17.980 Yes. 00:04:18.100 --> 00:04:22.380 And how Bitcoin Core developers or some Bitcoin Core developer wants to 00:04:22.380 --> 00:04:26.560 potentially lift it. Is that right? Is the rumor true? 00:04:28.300 --> 00:04:32.670 I can neither confirm nor deny. No, you can see it on GitHub. 00:04:32.910 --> 00:04:37.790 Twitter runs ablaze this week. I'm not on Twitter anymore, which I find 00:04:37.790 --> 00:04:43.210 wonderful. Well, I do have my account, but I really only use it for one-way 00:04:43.210 --> 00:04:45.790 tweets once in a while. I don't spend any time. 00:04:45.870 --> 00:04:50.360 I deleted it, so if you see anybody with my username on Twitter, it's not me. And 00:04:50.360 --> 00:04:51.420 I'm not going to double your coins. 00:04:51.600 --> 00:04:55.300 Yeah, I'm de facto Nostr only. You're really Nostr only. 00:04:55.480 --> 00:04:55.660 Yep. 00:04:56.160 --> 00:05:01.380 Yeah. So honestly, whatever was debated on Twitter on this topic, I don't think 00:05:01.380 --> 00:05:06.340 I've seen it other than indirectly because other people are talking about it or I 00:05:06.340 --> 00:05:07.920 saw screenshots on Nostr. 00:05:08.060 --> 00:05:12.760 Yeah, but they were also debating it on Nostr and more importantly on GitHub and 00:05:12.760 --> 00:05:13.440 on the mailing list. 00:05:14.340 --> 00:05:18.520 Well, they were not discussing it on GitHub, I heard, because the Core developers 00:05:18.520 --> 00:05:20.100 shut that discussion down. 00:05:20.220 --> 00:05:21.440 Well, not effectively enough. 00:05:24.120 --> 00:05:28.900 Anyways, okay, so we're going to make the 37th podcast on the OP_RETURN drama. 00:05:29.240 --> 00:05:32.120 Yes, and for the listeners, we did one before. 00:05:30.980 --> 00:05:35.620 But this is just to say this will be the highest quality one. Because we got our 00:05:35.620 --> 00:05:40.060 very special Sjors. Well, this is not even your first podcast talking about the 00:05:40.060 --> 00:05:41.100 OP_RETURN drama, I think. 00:05:41.340 --> 00:05:43.580 No, we've done episode 61 on it. 00:05:43.760 --> 00:05:49.380 Well, also, and you were on the Bitcoin Optech podcast. But it's your first 00:05:49.380 --> 00:05:54.880 podcast speaking about it with me after the drama happened. 00:05:55.840 --> 00:05:59.080 And indeed, we did other episodes on OP_RETURN as well. 00:05:59.740 --> 00:06:00.180 Yes. 00:06:00.460 --> 00:06:06.340 But let's dig into it. Let's see if we can bring anything new to the table. If not, 00:06:07.960 --> 00:06:13.230 well, maybe you get at least new voices talking about the same thing. So, dear 00:06:13.230 --> 00:06:15.470 listener, I hope you enjoy it at least a little bit. 00:06:16.890 --> 00:06:18.170 Sjors, we're going to start at the beginning. 00:06:20.620 --> 00:06:25.460 And yes, we did a previous episode on it, which these were episode six, very 00:06:25.460 --> 00:06:30.880 early one, and episode 76, and I'm sure it came up in other episodes. 00:06:31.000 --> 00:06:33.100 You mean episode 61, not six. 00:06:34.390 --> 00:06:36.550 I have 76 here, though. 00:06:36.950 --> 00:06:37.570 Yeah, 61. 00:06:37.730 --> 00:06:38.950 Oh, not six. 00:06:39.030 --> 00:06:39.170 Yeah. 00:06:39.370 --> 00:06:45.100 Oh, right. That was one after the six on the next. Next row. Okay, 61 and 00:06:45.100 --> 00:06:50.000 76, probably here and there between as well. But actually, I do want to sort of 00:06:50.000 --> 00:06:55.530 use this episode to kind of give a complete picture. So let's not go 00:06:55.530 --> 00:06:59.530 back to that episode thing and let's just kind of start from the beginning. 00:06:59.690 --> 00:07:03.110 No, but you could listen to it if you think that I randomly changed my mind on 00:07:03.110 --> 00:07:06.170 these topics, which is possible. But we have the earlier episode. 00:07:08.660 --> 00:07:14.300 Sure. Let's start at the beginning. What is OP_RETURN? Let's start there. What is 00:07:14.300 --> 00:07:14.880 OP_RETURN? 00:07:14.980 --> 00:07:18.760 Well, if we really go back to the beginning, it was a way to basically steal 00:07:18.760 --> 00:07:23.020 everybody's coins. Because there was a bug in the original version of it. It 00:07:23.020 --> 00:07:23.860 basically says like... 00:07:23.860 --> 00:07:28.040 Well, okay, first question. Was OP_RETURN in the Bitcoin protocol since day one? 00:07:28.460 --> 00:07:28.940 Yes. 00:07:29.400 --> 00:07:34.560 Okay, but that means, because you mentioned, there was originally a bug in the 00:07:34.560 --> 00:07:38.880 OP_RETURN implementation. So that means, if I understand you correctly... 00:07:39.380 --> 00:07:42.540 It wasn't in the OP_RETURN implementation itself. It was that you can use it 00:07:42.540 --> 00:07:48.280 basically the way, just as a reminder, how do you spend a Bitcoin? You spend an 00:07:48.280 --> 00:07:52.420 output, right? So it's like coins. And the output says, here's a challenge if you 00:07:52.420 --> 00:07:57.180 want to spend me. And then the way you do it in practice is first you provide 00:07:57.180 --> 00:08:01.100 some answers to the blockchain. We now call that the witness. It used to be the 00:08:01.100 --> 00:08:05.080 scriptSig. It doesn't really matter. You start with the answer. And then it's 00:08:05.080 --> 00:08:10.760 followed by the question. It's kind of a riddle-y way, right? So you say, your 00:08:10.760 --> 00:08:14.840 answer might be, here's my signature. And then the question would be, like, give 00:08:14.840 --> 00:08:16.180 me a signature for this public key. 00:08:17.320 --> 00:08:19.900 For the next person that will spend it. 00:08:20.020 --> 00:08:24.480 Yes. Now, the problem is, because of this sequence, if you use OP_RETURN, you 00:08:24.480 --> 00:08:27.800 could say, okay, OP_RETURN, that just says, I'm done now. 00:08:29.360 --> 00:08:31.700 And so you're not going to look at the question. 00:08:32.820 --> 00:08:34.640 This is already skipping ahead too far. 00:08:34.800 --> 00:08:37.120 That was basically how, I believe, how the bug worked. 00:08:37.700 --> 00:08:42.080 Yeah, but people don't understand how the bug works if they don't understand 00:08:42.080 --> 00:08:46.990 OP_RETURN itself, right? So that's why you're skipping ahead too far already. In 00:08:46.990 --> 00:08:50.870 either case, this is not even what we're talking about, the bug. But I guess 00:08:50.870 --> 00:08:53.450 we... What is OP_RETURN? 00:08:53.550 --> 00:08:58.600 It just says, like, you're done now. We're finished evaluating this. whatever 00:08:58.600 --> 00:09:00.180 script it is. It's the end of the script. 00:09:00.320 --> 00:09:00.460 Right. 00:09:00.720 --> 00:09:02.320 Even if it's not actually the end of the script. 00:09:02.340 --> 00:09:08.160 So I'm running a node and my node is looking at a transaction. So in my node, 00:09:08.320 --> 00:09:13.840 my computer is reading these transactions, going line for line, seeing what I'm 00:09:13.840 --> 00:09:18.220 supposed to do here. And then at some point, my node sees OP_RETURN in a 00:09:18.220 --> 00:09:21.120 transaction and then my node says, oh, I'm done reading now. 00:09:21.260 --> 00:09:21.480 Yes. 00:09:21.940 --> 00:09:22.200 Okay. 00:09:22.560 --> 00:09:27.600 And I guess the thing I forgot about the exploit is... When you're done reading, 00:09:27.900 --> 00:09:32.520 the question then is, is this transaction now valid or not? That's the actual 00:09:32.520 --> 00:09:34.280 challenge. Can I spend this coin or not? 00:09:34.400 --> 00:09:34.500 Yeah. 00:09:34.920 --> 00:09:38.360 And whether or not you can spend a coin does not depend on the last thing you 00:09:38.360 --> 00:09:41.740 read. It depends on what's on the stack. And we talked about stacks earlier. Like 00:09:41.740 --> 00:09:45.200 you put something on the stack and you can take things off the stack and you can 00:09:45.200 --> 00:09:47.120 multiply them, whatever. Well, you can multiply them. 00:09:48.430 --> 00:09:53.420 And so what you would do is you put the word true. on the stack and then you 00:09:53.420 --> 00:09:58.000 finish and so the rule is if at the end of a script the last thing on the stack 00:09:58.000 --> 00:10:02.810 is true then you're done so this was kind of the trick you would just put true on 00:10:02.810 --> 00:10:04.930 the stack and you would stop and you wouldn't read the challenge 00:10:04.930 --> 00:10:10.750 okay but I want to ask what is the benefit of this what is the benefit of 00:10:10.750 --> 00:10:12.050 saying stop reading now 00:10:12.050 --> 00:10:16.080 I mean it's used in pretty much every programming language to say okay 00:10:17.310 --> 00:10:20.710 the program is done or yeah usually or the function is done 00:10:20.710 --> 00:10:26.390 well why not just stop writing code after OP_RETURN 00:10:26.390 --> 00:10:30.070 and not include OP_RETURN because then the node is also done reading because 00:10:30.070 --> 00:10:31.530 there's nothing to read like what's the difference 00:10:31.530 --> 00:10:35.230 yeah so this is why you know it's a general thing that you would use in 00:10:35.230 --> 00:10:38.550 programming language it wasn't I don't think there was a specific reason to 00:10:38.550 --> 00:10:43.220 include it Satoshi just added a whole bunch of opcodes to Bitcoin some of which 00:10:43.220 --> 00:10:46.580 were, like, a lot of them were just from, this is kind of how programming 00:10:46.580 --> 00:10:49.620 languages work and we can make smart contracts. I think there wasn't that much 00:10:49.620 --> 00:10:53.400 thinking about which opcodes to include, which is why a lot of them were disabled. 00:10:53.580 --> 00:10:57.520 Okay, the way you're explaining it to me now, and this is the first time I'm 00:10:57.520 --> 00:11:02.060 hearing it explained like this, so let me ask, you explain it like OP_RETURN is 00:11:02.060 --> 00:11:06.040 the equivalent of, like, a dot in regular text. It's like the end of the 00:11:06.040 --> 00:11:08.600 sentence. Is that what it is? 00:11:08.740 --> 00:11:13.060 Pretty much. I mean, in programming language, you can use return just as its own 00:11:13.060 --> 00:11:17.080 statement, which just ends, but you can also put a value after it. So you can 00:11:17.080 --> 00:11:20.920 return something, return a value. That's kind of where it comes from. So you can 00:11:20.920 --> 00:11:25.580 say return five, and then whichever function is calling you gets the number five. 00:11:26.410 --> 00:11:29.710 But this gets too deep in the programming weeds. I think for the purpose of 00:11:29.710 --> 00:11:31.490 Bitcoin, it just means stop where you are. 00:11:31.790 --> 00:11:32.210 Yeah, okay. 00:11:33.800 --> 00:11:38.580 So let me skip ahead a little bit, or not, depending on your answer. The way 00:11:38.580 --> 00:11:44.380 OP_RETURN is used is you put some sort of other kind of data 00:11:44.380 --> 00:11:49.250 in... in OP_RETURN. That's how it's usually explained. Like you have an OP_RETURN 00:11:49.250 --> 00:11:52.930 output and then you put some other kind of data, whether that's a hash or 00:11:52.930 --> 00:11:57.150 something. That's what you use OP_RETURN for. My question then is, was that the 00:11:57.150 --> 00:12:00.690 original intention of OP_RETURN or is that something that was figured out later 00:12:00.690 --> 00:12:03.850 in the sense of, okay, that's what we could use that for? 00:12:03.970 --> 00:12:07.890 I think it was figured out later. I think the original reason was it just stops 00:12:07.890 --> 00:12:10.990 the program. And because you stop the program, you can put whatever you want 00:12:10.990 --> 00:12:12.550 after it because you're not going to check it. 00:12:12.920 --> 00:12:17.380 Okay, I think this is new to me, unless you explained this to me in a previous episode. 00:12:17.500 --> 00:12:18.760 I don't know if I did, but... 00:12:18.760 --> 00:12:19.520 You may have. 00:12:21.200 --> 00:12:25.800 So it was not necessarily the original intention of Satoshi for putting OP_RETURN 00:12:25.800 --> 00:12:31.240 in there, but it did effectively work that way. Because if my node stops 00:12:31.240 --> 00:12:36.120 assessing data, but the data is technically in the transaction, then that means 00:12:36.120 --> 00:12:39.970 that... you know, the data ends up in the blockchain and can be used for other 00:12:39.970 --> 00:12:45.810 purposes, basically. That's how OP_RETURN was effectively used, 00:12:45.830 --> 00:12:46.570 at least later. 00:12:46.810 --> 00:12:51.630 Yeah, I think the first OP_RETURN ever was long after Satoshi left, but I haven't 00:12:51.630 --> 00:12:52.190 checked this. 00:12:53.970 --> 00:12:57.550 I mean, Satoshi himself put a message in the blockchain at the Genesis block, but 00:12:57.550 --> 00:12:58.730 he didn't put it in an OP_RETURN. 00:12:58.870 --> 00:12:59.990 No, he put it in a Coinbase. 00:13:00.130 --> 00:13:00.290 Yeah. 00:13:00.710 --> 00:13:06.100 Okay, you think... double-check us if one of our listeners thinks it's wrong or 00:13:06.100 --> 00:13:10.280 not. We don't actually care. We're not going to read the comments. But you think, 00:13:10.420 --> 00:13:15.860 Sjors, that OP_RETURN was probably only ever used after Satoshi left, in fact. 00:13:16.640 --> 00:13:19.520 I think so. You can easily check this. I don't know for sure. 00:13:20.700 --> 00:13:20.960 Okay. 00:13:23.310 --> 00:13:28.990 So the original thing was just a generic code thing. Stop reading here. 00:13:29.870 --> 00:13:33.630 Yeah, this is one of many opcodes that Satoshi added, and it's kind of standard 00:13:33.630 --> 00:13:35.650 if you know how programming languages work. 00:13:35.810 --> 00:13:38.930 Okay, and now the next step. Now the first time it was used, or maybe not the 00:13:38.930 --> 00:13:43.370 first time, but when it started to be. People started to use OP_RETURN to embed 00:13:43.370 --> 00:13:48.850 other types of data other than transaction data, other than send Bitcoins from 00:13:48.850 --> 00:13:53.850 here to there. Other types of data. in the blockchain and they were used... Okay, 00:13:53.850 --> 00:13:54.920 go on. You go first. 00:13:54.530 --> 00:13:58.850 Here, I'm not sure if they actually did that first. I think what they did first 00:13:58.850 --> 00:14:00.490 was to use fake public keys. 00:14:00.590 --> 00:14:00.710 Right. 00:14:00.890 --> 00:14:04.930 And then somebody told them, hey, don't do that. Use OP_RETURN instead. 00:14:05.210 --> 00:14:05.260 Right. 00:14:06.450 --> 00:14:10.530 So let's assume that this sequence is incorrect. It doesn't really matter for the argument. 00:14:10.850 --> 00:14:11.010 Indeed. 00:14:13.120 --> 00:14:16.240 So, okay. So you want to embed something in the data and you're like, we're in 00:14:16.240 --> 00:14:19.440 the blockchain. The first thing is you would ask yourself is where am I going to 00:14:19.440 --> 00:14:19.920 put this? 00:14:20.950 --> 00:14:25.130 You want to put data in the blockchain that's not sending Bitcoins from A to B. 00:14:25.130 --> 00:14:25.810 Yeah, and at the time... 00:14:25.810 --> 00:14:27.490 Other type of data, for whatever reason. 00:14:27.670 --> 00:14:30.190 Yeah, and so at the time you're like, okay, what is in a transaction? Well, 00:14:30.270 --> 00:14:34.390 there's public keys, there's signatures, all these things. Why don't I just make 00:14:34.390 --> 00:14:38.630 a fake... Well, if you make a fake signature, then the transaction is invalid, so 00:14:38.630 --> 00:14:41.790 it doesn't end up in the blockchain. At least, you know, there's some caveats 00:14:41.790 --> 00:14:46.360 there, but that's a general idea. But a fake public key... Yeah, you can do that. 00:14:46.800 --> 00:14:50.880 Yeah, and by fake public key, what you mean is something that looks like a public 00:14:50.880 --> 00:14:56.740 key, except some parts of the numbers and figures that are in there are 00:14:56.740 --> 00:14:58.880 actually data that you use for something else, right? 00:14:58.880 --> 00:15:01.880 Yes, and the effect of that is that there's not going to be a corresponding 00:15:01.880 --> 00:15:06.820 private key. You can infer that as a human. So one of the first things that are 00:15:06.820 --> 00:15:11.280 in the blockchain, I think, is a picture of Obama, the Bitcoin white paper PDF. 00:15:11.620 --> 00:15:13.780 You can get it out of the blockchain. Yeah. 00:15:15.430 --> 00:15:18.770 And I think a lot of that is done with fake signatures. Some of it might have 00:15:18.770 --> 00:15:19.990 been done later with OP_RETURN. 00:15:20.230 --> 00:15:25.190 Yeah, so what I could do potentially is I could write a message to you that says, 00:15:25.390 --> 00:15:30.080 hey, Sjors, let's explain the new Bitcoin Explained. Let's record a new 00:15:30.080 --> 00:15:35.980 Bitcoin Explained episode today at 6. And then I create a bunch of pubkeys that 00:15:35.980 --> 00:15:41.180 have these exact letters as the last letters of each one of them. Hi, Sjors, you 00:15:41.180 --> 00:15:45.300 can actually read that. And if you run some sort of program that monitors the 00:15:45.300 --> 00:15:49.080 blockchain for that, then at some point you can actually see that message and 00:15:49.080 --> 00:15:52.080 then you can message me back in the same way. And now we've created a bunch of 00:15:52.080 --> 00:15:55.420 pubkeys that cannot actually be spent because I just generated them for the 00:15:55.420 --> 00:15:59.860 message. But they do end up... in the blockchain, and worse, 00:16:00.100 --> 00:16:01.460 they end up in the UTXO set. 00:16:01.520 --> 00:16:02.720 They end up in the UTXO set. 00:16:02.880 --> 00:16:08.070 Yeah, and the UTXO set is this database of coins that exist. And right now this 00:16:08.070 --> 00:16:11.050 database, I think if you put it on your disk, it's like 13 gigabytes. 00:16:11.390 --> 00:16:15.630 To be clear, to be clear. So if I do this, then of course I do indeed need to 00:16:15.630 --> 00:16:19.610 send some coins to each of these addresses, right? One satoshi at least. Or not 00:16:19.610 --> 00:16:20.950 even? Or can I send zero? 00:16:21.090 --> 00:16:24.670 No, there's a dust limit. So you have to send, I think, a couple hundred satoshis 00:16:24.670 --> 00:16:25.070 in practice. 00:16:25.290 --> 00:16:26.210 Well, is that a consensus? 00:16:26.590 --> 00:16:26.950 No. 00:16:27.210 --> 00:16:27.390 Okay. 00:16:27.510 --> 00:16:31.490 No, no, no. Consensus-wise, you can actually spend zero and you can make a 00:16:31.490 --> 00:16:32.690 transaction that spends nothing. 00:16:34.310 --> 00:16:35.790 also doesn't produce any outputs. 00:16:35.930 --> 00:16:38.390 Yeah, I heard that recently on the Bitcoin Explained podcast. 00:16:39.110 --> 00:16:39.470 Interesting. 00:16:39.610 --> 00:16:43.410 Yeah, they were talking about a new Bitcoin Core release and I learned a lot from it. 00:16:43.590 --> 00:16:45.170 Okay, well, it sounds like a nice podcast then. 00:16:46.020 --> 00:16:49.800 But practically speaking, let's say I wanted to send these messages, then yeah, 00:16:49.980 --> 00:16:53.800 probably I would just use the dust limit, which is whatever it is, 400 sats or 00:16:53.800 --> 00:16:54.240 what is it? 00:16:54.320 --> 00:16:54.460 Yeah. 00:16:55.180 --> 00:16:55.980 Whatever it is. 00:16:56.140 --> 00:16:56.360 Whatever. 00:16:56.800 --> 00:17:01.300 Yeah, it's pretty cheap still and then I have this message. The thing is that the 00:17:01.300 --> 00:17:02.380 rest of the world... 00:17:02.380 --> 00:17:04.080 And especially then, it was pretty cheap, right? 00:17:04.520 --> 00:17:09.920 Right. So the rest of the world, I know that I can't spend these coins. You can 00:17:09.920 --> 00:17:12.760 probably also figure out that I can't spend these coins. But for the rest of the 00:17:12.760 --> 00:17:17.140 world, it just looks like spendable coins. Now the rest of the world, everyone 00:17:17.140 --> 00:17:22.720 who runs a node needs to keep track of these coins and their existence. And in 00:17:22.720 --> 00:17:28.100 fact, because they go into the UTXO set, so the database basically of unspent 00:17:28.100 --> 00:17:33.320 coins, that means I think, correct me if I'm wrong, but they end up in the... 00:17:34.830 --> 00:17:38.010 the memory of your computer, which is kind of resource-intensive. 00:17:38.130 --> 00:17:41.270 Yeah, they don't have to be in memory, but it's better if you do. But the most 00:17:41.270 --> 00:17:42.690 important thing is you cannot delete it. 00:17:42.870 --> 00:17:43.230 Yeah. 00:17:43.590 --> 00:17:48.350 Because, I mean, you could bluff, basically. You could say, well, I'm going to 00:17:48.350 --> 00:17:51.870 look at these transactions and I know nobody can spend it, so I know I can delete 00:17:51.870 --> 00:17:54.970 this from my computer and it will never cause a problem. But if you're wrong, 00:17:55.190 --> 00:17:58.370 somebody creates something that looks like a picture, but it's actually, you 00:17:58.370 --> 00:18:02.530 know, it's a real key and they end up spending it. well, you will look at that 00:18:02.530 --> 00:18:05.530 block and think the block is invalid because they're spending a coin that doesn't 00:18:05.530 --> 00:18:09.590 exist because you deleted it. So there's really no objective way to figure out 00:18:09.590 --> 00:18:13.050 which of these coins are real and which of these are fake, other than saying, 00:18:13.190 --> 00:18:17.470 hey, Bitcoin Core, why don't you make a database and tell us all what the real 00:18:17.470 --> 00:18:21.050 coins are and what the spam coins are? But that would be fairly centralizing. 00:18:22.310 --> 00:18:23.410 We don't want that. 00:18:23.690 --> 00:18:23.810 No. 00:18:26.530 --> 00:18:32.360 Okay, so then at some point, Core developers said, This sucks. We don't want 00:18:32.360 --> 00:18:37.940 you guys to upload Obama pictures and white papers and Bitcoin Explained 00:18:37.940 --> 00:18:43.920 scheduling messages into the UTXO set. That sucks. Here 00:18:43.920 --> 00:18:47.020 is actually a better solution, right? That's kind of how it went. 00:18:47.820 --> 00:18:51.740 Yeah, so I guess there were people that said don't embed this kind of stuff 00:18:51.740 --> 00:18:56.420 anywhere. But specifically, don't put it in the UTXO set because it is this thing 00:18:56.420 --> 00:19:00.000 that will grow forever until the end of time. Like, you cannot shrink it. Every 00:19:00.000 --> 00:19:03.940 time you spend a coin, it shrinks. But if you never spend a coin, it never shrinks. 00:19:04.760 --> 00:19:08.260 Yeah, so if you create UTXOs that cannot be spent, then... 00:19:08.540 --> 00:19:10.320 then they will never be spent, exactly. 00:19:11.940 --> 00:19:16.680 So the idea was, okay, how can we, you know, we can't stop people because, again, 00:19:16.900 --> 00:19:21.300 then that would require some weirdness. But you can encourage people to put data 00:19:21.300 --> 00:19:24.660 on the blockchain in a way that does not grow the UTXO set. And that is when 00:19:24.660 --> 00:19:26.540 people realized you can use OP_RETURN for this. 00:19:27.020 --> 00:19:27.160 Right. 00:19:27.320 --> 00:19:30.860 And so then a change was made in the relay rules. We'll need to get to the relay 00:19:30.860 --> 00:19:36.710 rules with basically saying, just put this OP_RETURN code and then after it, put 00:19:36.710 --> 00:19:37.410 your JPEGs. 00:19:37.690 --> 00:19:37.790 Yeah. 00:19:38.170 --> 00:19:40.510 And then the limit was still 80 bytes. 00:19:41.130 --> 00:19:46.610 Well, so let's get to that right now. So the way I understand it, what I 00:19:46.610 --> 00:19:50.350 remember, I think, from our previous episode, is that originally, 00:19:51.660 --> 00:19:57.260 as a consensus rule, as what is valid in a block, there was never a limit on OP_RETURN. 00:19:57.560 --> 00:19:57.820 Yes. 00:19:58.340 --> 00:20:04.170 The block size limit was made one megabyte by Satoshi. I guess 00:20:04.170 --> 00:20:04.890 before that. 00:20:05.010 --> 00:20:07.130 Yeah, the original OP_RETURN limit was 32 megabyte. 00:20:07.890 --> 00:20:11.070 And that was because transactions of... 00:20:11.070 --> 00:20:14.370 Because blocks are 32 megabytes. And I think even that limit... 00:20:14.370 --> 00:20:16.910 Was that even a consensus rule? I think even that was a relay rule. 00:20:19.230 --> 00:20:23.230 Well, I don't know about relay rule, but it was like any network message that was 00:20:23.230 --> 00:20:26.810 larger would be rejected. So it's possible if you got the block on a floppy disk, 00:20:26.930 --> 00:20:30.890 then you could load it. Right. But it's not like what we now would call a policy rule. 00:20:30.990 --> 00:20:33.550 Yeah, policy rule. That's a term I was looking for, actually. 00:20:36.020 --> 00:20:41.840 But at least as a consensus rule, OP_RETURN transactions could be as big as block 00:20:41.840 --> 00:20:47.500 size limits or the message limit that you just mentioned. But at that point, 00:20:47.740 --> 00:20:53.440 I think there was still a relay restriction of no OP_RETURNs at all, 00:20:53.640 --> 00:20:58.100 maybe. Like OP_RETURNs would just not be relayed. Is that correct, or do you not 00:20:58.100 --> 00:20:58.580 know this? 00:20:58.620 --> 00:21:02.720 Yes, so if we go back to relay history in general, without recapping everything, 00:21:03.280 --> 00:21:08.060 in the beginning, Satoshi made a whitelist of things that can be relayed. 00:21:09.400 --> 00:21:14.180 basically between nodes. And those would be the very standard transaction types. 00:21:14.340 --> 00:21:17.220 Like I'm spending from a public key and receiving to a public key. There were 00:21:17.220 --> 00:21:22.630 some limits on, say, multi-signature, how many, I think it was three. in a 00:21:22.630 --> 00:21:27.470 multisig, so no more than three keys in a multisig, etc. So it was a very, very 00:21:27.470 --> 00:21:31.030 small subset of everything that was possible, was allowed, and it was definitely 00:21:31.030 --> 00:21:31.670 a whitelist. 00:21:31.910 --> 00:21:37.630 Yeah, and to re-emphasize this, you now distinguish between what is 00:21:37.630 --> 00:21:42.810 possible and what is allowed. The difference is, there is one set of rules, the 00:21:42.810 --> 00:21:46.810 consensus rules, for what may end up in a block, and other nodes will consider 00:21:46.810 --> 00:21:51.470 valid. And then there's another set of rules. The relay rules or what's the 00:21:51.470 --> 00:21:53.110 actual policy rules? 00:21:53.210 --> 00:21:53.750 Policy rules. 00:21:53.930 --> 00:21:58.210 And that will determine what nodes will accept in their mempool and relay to 00:21:58.210 --> 00:21:58.830 other nodes. 00:21:58.990 --> 00:21:59.370 Yeah. 00:21:59.510 --> 00:22:02.750 Right? That's the difference. Okay, so there's one set of rules for what goes 00:22:02.750 --> 00:22:06.510 into a block, what's allowed, and one set of rules for what a node will tell 00:22:06.510 --> 00:22:11.720 other nodes is happening. Right? So, at first, anything was allowed in a block, 00:22:11.900 --> 00:22:16.920 or at least any OP_RETURN size was allowed in a block, but nodes would not send 00:22:16.920 --> 00:22:20.980 it to other nodes. They would say, OP_RETURN, I'm not going to help spread that. 00:22:21.220 --> 00:22:26.700 But that was then changed. So, at that point, Core developers said, there was a 00:22:26.700 --> 00:22:27.640 debate about this. 00:22:29.520 --> 00:22:33.220 whether it should be 40 or 80, and I think they settled on 80 bytes. 00:22:33.560 --> 00:22:33.920 Yes. 00:22:34.160 --> 00:22:37.860 Yeah, so they said, okay, from now on, with this new Bitcoin Core release, that 00:22:37.860 --> 00:22:41.820 was the Bitcoin Core, whatever, six or whatever it was. I don't know. Do you know this? 00:22:41.880 --> 00:22:42.220 I don't know. 00:22:42.380 --> 00:22:46.220 Yeah, well, it was a long time ago. They said, okay, from now on, we are going to 00:22:46.220 --> 00:22:51.930 relay OP_RETURNs up to 80 bytes. Okay, why was... The limit set 00:22:51.930 --> 00:22:53.090 at 80 bytes. 00:22:53.210 --> 00:22:56.630 Yeah. So for this, we need to introduce another use case of this putting data on 00:22:56.630 --> 00:23:00.630 the blockchain because this 80 bytes is still not enough to relay anything like 00:23:00.630 --> 00:23:04.910 the white paper and JPEGs. I guess they weren't that popular back then, but what 00:23:04.910 --> 00:23:09.610 was starting to get popular was something called Counterparty. And it was more 00:23:09.610 --> 00:23:13.670 about smart contracts that would not put the actual image on the blockchain, but 00:23:13.670 --> 00:23:17.110 put like a hash of the image in the blockchain and you would sell, quote unquote, 00:23:17.510 --> 00:23:17.930 your... 00:23:19.670 --> 00:23:25.140 trading cards, NFTs, as we call them now. And those transactions, I think... 00:23:25.140 --> 00:23:28.340 Yeah, I mean, I think Counterparty was more than just that, but go on, yeah. 00:23:28.780 --> 00:23:30.600 Yeah, but basically those transactions... 00:23:30.600 --> 00:23:33.180 I mean, it was also like meta coins and stuff like that, but go on. 00:23:33.280 --> 00:23:36.420 Yeah, trading cards is one example, but there were other things. Rare Pepe was 00:23:36.420 --> 00:23:37.860 quite famous, I think, back then. 00:23:38.000 --> 00:23:38.100 Yeah. 00:23:39.380 --> 00:23:45.320 So those transactions, I think, were in practice a little bit like 60 bytes or 70 00:23:45.320 --> 00:23:49.480