WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.020 --> 00:00:22.100 Live from Utrecht, this is Bitcoin. 00:00:22.720 --> 00:00:23.240 Explained. 00:00:23.860 --> 00:00:27.280 Sjors, we're going to lean into some Twitter controversy today. 00:00:27.800 --> 00:00:33.540 Exactly. We have to jump on the bandwagon and make sure that we talk about what 00:00:33.540 --> 00:00:34.400 other people talk about. 00:00:34.580 --> 00:00:40.150 Love it. Yeah, actually, I got this request from a colleague of mine, Brendan 00:00:40.150 --> 00:00:45.630 Green. And since I am his humble servant, I had no other choice but to make an 00:00:45.630 --> 00:00:51.050 episode about this topic, which is inscriptions and maybe also 00:00:51.050 --> 00:00:54.950 ordinals to some extent. But yeah, as you mentioned, everyone's talking about it 00:00:54.950 --> 00:01:00.130 now, which kind of I think for both of us was more of a demotivating factor 00:01:00.130 --> 00:01:04.820 because everything that can be said about it has been said by now, maybe. But 00:01:04.820 --> 00:01:08.200 we're going to try to at least explain what it is, I guess, Sjors. 00:01:08.420 --> 00:01:11.420 Yeah, and this may be nice for our listeners who have not caught up on it. 00:01:11.840 --> 00:01:16.920 Okay, but first, first of all, Sjors, you want to read some boosts. 00:01:16.980 --> 00:01:21.350 Some boostograms. And if you don't know what that is, Google it. First one is 00:01:21.350 --> 00:01:27.190 nice and short. From @Vake. 2,500 sats. Second best podcast 00:01:27.190 --> 00:01:29.870 ever behind the Van Wirdum Sjorsnado. 00:01:30.590 --> 00:01:31.970 Love the Van Wirdum Sjorsnado. 00:01:32.550 --> 00:01:35.810 Excellent. And the other one from Mr. Mister. 00:01:36.740 --> 00:01:42.730 5,674 sats. Excellent topic and explanations. As 00:01:42.730 --> 00:01:47.390 for topics for the future show, I need some technical explanation. Perhaps you 00:01:47.390 --> 00:01:51.770 could be of assistance because I thought I knew how my Lightning channel closed, 00:01:51.850 --> 00:01:57.810 but my node died and BlueWallet sees the on-chain stuff. Yay. And I 00:01:57.810 --> 00:02:02.040 contacted the other node operator and they closed the channel out. Yay. But my 00:02:02.040 --> 00:02:05.300 share of closing Lightning balance didn't go on chain. Thanks. 00:02:06.750 --> 00:02:09.670 Is this a question? Did you just... 00:02:10.090 --> 00:02:14.450 Well, I think his question is to please explain how Lightning works to the point 00:02:14.450 --> 00:02:18.230 that I can fix, I get my money back. But basically, this reminds me of something 00:02:18.230 --> 00:02:22.470 that happened to me a few years ago, which is I had an LND node and a C-Lightning 00:02:22.470 --> 00:02:28.350 node, and I had a channel between them, and then I nuked my LND node. And I lost 00:02:28.350 --> 00:02:32.750 the money that was in the channel. But after only two days of puzzling and going 00:02:32.750 --> 00:02:36.870 to hackathons and talking to Christian Decker and roasbeef and writing some 00:02:36.870 --> 00:02:42.330 custom tools, I was able to get my 100 euros back. But the exact way to do that 00:02:42.330 --> 00:02:47.810 is quite hard and depends on which pieces of software you're using. In this case, 00:02:47.810 --> 00:02:49.150 I wouldn't know. 00:02:49.830 --> 00:02:51.450 Sorry for your loss, Mr. Mister. 00:02:51.730 --> 00:02:55.130 In general, our Lightning expertise is not that. There are some episodes where we 00:02:55.130 --> 00:02:59.710 struggle to explain certain aspects of Lightning. I think we did publish them. 00:02:59.970 --> 00:03:02.870 I mean, we've also had Lightning guests on, right? 00:03:03.750 --> 00:03:03.830 True. 00:03:03.950 --> 00:03:07.630 I think that's sort of what we like to do. If we do a Lightning episode, we'll 00:03:07.630 --> 00:03:10.810 get someone on board that actually knows more about Lightning than we do. 00:03:11.150 --> 00:03:15.850 Yeah, but there's basically, as a general rule, if you have a Lightning wallet, 00:03:15.930 --> 00:03:19.950 then your funds are already on-chain. Those funds should be fine if you have to 00:03:19.950 --> 00:03:23.210 recover from a backup. But anything that's in a channel requires some 00:03:23.210 --> 00:03:27.320 sophistication to correctly backup. And maybe hard or impossible to recover. 00:03:28.770 --> 00:03:34.270 Okay. Sjors, Back to inscriptions. The topic du jour. The new 00:03:34.270 --> 00:03:35.970 war on Bitcoin. 00:03:37.520 --> 00:03:38.120 Yes. 00:03:38.280 --> 00:03:42.860 The controversy is brewing and we're going to lean into it with everything we 00:03:42.860 --> 00:03:47.480 have. Sjors, Inscriptions. Okay. First, before we actually get to inscriptions, I 00:03:47.480 --> 00:03:53.250 do want to mention a lot of this ties in with 00:03:53.250 --> 00:03:58.710 OP_RETURN and we made an episode episode on OP_RETURN on the OP_RETURN wars 00:03:58.710 --> 00:04:04.670 as it was referred to which was episode 61 and we'll recap some of that 00:04:04.670 --> 00:04:09.730 here but maybe not all of it so if you really don't know and I'm 00:04:09.730 --> 00:04:14.350 addressing you my dear listener our dear listener if you don't know what 00:04:14.350 --> 00:04:20.090 OP_RETURN is then you might want to go back to episode 61 first to 00:04:20.090 --> 00:04:25.910 sort of get an idea of what the history there is. That said, we will recap 00:04:25.910 --> 00:04:31.110 it real quick. Yeah, Sjors, I'll just leave this to you. OP_RETURN, what do we 00:04:31.110 --> 00:04:32.690 need to know before we get to inscriptions? 00:04:33.590 --> 00:04:37.890 Yeah, so OP_RETURN was a solution to a problem. And the problem was that, well, 00:04:38.910 --> 00:04:42.530 the problem wasn't so much that people were putting stuff on the blockchain that 00:04:42.530 --> 00:04:46.080 wasn't money. They were putting pictures, et cetera, on the blockchain. That 00:04:46.080 --> 00:04:49.680 wasn't necessarily the problem, but the problem was in how they were doing it. 00:04:49.900 --> 00:04:52.020 They were using weird mechanisms. 00:04:52.540 --> 00:04:55.940 I'll stop you right there. That's debatable, right? Like some people will say 00:04:55.940 --> 00:04:57.420 that's in itself a problem. 00:04:57.780 --> 00:05:01.520 Yeah, some people would, but there was a bigger problem. And that was in the way 00:05:01.520 --> 00:05:05.950 that we're doing it. And the way that we're doing it was causing the so-called 00:05:05.950 --> 00:05:11.910 UTXO set to grow a lot. And the UTXO set is basically the set of coins that exist 00:05:11.910 --> 00:05:16.310 in the world. And that could be spent by somebody at any time. Like, you don't 00:05:16.310 --> 00:05:19.910 know when it's going to be spent. So you tend to keep it in RAM so that whenever 00:05:19.910 --> 00:05:23.050 a new block comes in, you can very quickly check whether the new block is 00:05:23.050 --> 00:05:28.110 spending coins that actually exist or not. And the problem with the way they were 00:05:28.110 --> 00:05:31.230 putting data on the blockchain is they were basically making it look like there 00:05:31.230 --> 00:05:35.470 were real coins out there that could be spent with public keys and all, but they 00:05:35.470 --> 00:05:41.300 could never be spent because there was no private key because of the 00:05:41.300 --> 00:05:46.570 way the images were encoded. And so OP_RETURN was a sort of a mitigation of that 00:05:46.570 --> 00:05:50.350 by saying, okay, please use this mechanism called OP_RETURN and we'll explain how 00:05:50.350 --> 00:05:52.870 that works so that we don't have this problem with RAM. 00:05:52.870 --> 00:05:56.390 I don't think we will. People will have to go back to episode 61, sure. 00:05:56.630 --> 00:06:01.430 All right, fine. We won't explain it. Or we might get back to it. Anyway, so 00:06:01.430 --> 00:06:05.810 people could use OP_RETURN. They could put up to 80 bytes on the blockchain this 00:06:05.810 --> 00:06:09.790 way in a way that doesn't waste people's RAM. Still takes space in the 00:06:09.790 --> 00:06:12.750 blockchain, but it doesn't waste people's RAM and RAM is much more precious. 00:06:13.290 --> 00:06:18.730 Yeah, so the even shorter version is people were using Bitcoin for 00:06:18.730 --> 00:06:24.130 other reasons than transacting money. They were uploading images on the 00:06:24.130 --> 00:06:28.130 blockchain or whatever. And then developers said, all right, look, if you're 00:06:28.130 --> 00:06:33.850 going to do that anyways, then please do it in this way because that reduces the 00:06:33.850 --> 00:06:38.390 cost for everyone else. That's sort of the super short version, right? But then 00:06:38.390 --> 00:06:40.190 developers also said... 00:06:42.350 --> 00:06:47.390 Please don't do too much data at once. So they set a limit of 80 kilobytes, 00:06:47.490 --> 00:06:48.130 essentially, right? 00:06:48.350 --> 00:06:48.950 80 bytes. 00:06:49.530 --> 00:06:50.250 80 bytes. 00:06:50.390 --> 00:06:53.950 Per transaction, which means in practice, you know, in order to do a lot of data, 00:06:54.110 --> 00:06:57.230 you need not just to have this 80 bytes, but you need to make a whole transaction 00:06:57.740 --> 00:07:01.760 which has a bunch of overhead for every 80 bytes that you're trying to publish. 00:07:02.080 --> 00:07:05.660 Right. So developers said, if you're going to upload data on the blockchain, 00:07:06.000 --> 00:07:10.720 please use this. But then they did put a limit on the amount of data that you 00:07:10.720 --> 00:07:11.280 could upload. 00:07:11.460 --> 00:07:14.840 Yeah. And if I remember correctly, that limit was basically such that it was 00:07:14.840 --> 00:07:18.580 slightly more attractive to use OP_RETURN than to use the bad methods that we 00:07:18.580 --> 00:07:21.340 used before, but not unnecessarily attractive. 00:07:22.280 --> 00:07:28.020 Right. Okay, I think that's sort of the context that you need 00:07:28.020 --> 00:07:33.880 for the rest of this episode to get into inscriptions. I think, right? 00:07:34.160 --> 00:07:34.700 Yeah, I think so. 00:07:34.960 --> 00:07:40.500 Okay, so inscriptions then... I guess my one sentence summary 00:07:40.500 --> 00:07:46.320 would be inscriptions are a way to do the same thing, to do kind 00:07:46.320 --> 00:07:52.040 of what OP_RETURN does, but without the limit. Is that a fair one sentence summary? 00:07:52.260 --> 00:07:53.920 Well, it has a 400 kilobyte limit. 00:07:54.060 --> 00:07:58.960 Someone found a way around the limit. That someone is Casey Rodarmor. 00:07:59.240 --> 00:08:03.920 Yeah, so instead of an 80 byte limit, he found a way to have a 400 kilobyte limit 00:08:03.920 --> 00:08:09.920 and to get a 4x discount on fees. And in fact, probably a bigger discount in 00:08:09.920 --> 00:08:13.440 fees because the overhead of the transaction itself would be lower if you're 00:08:13.440 --> 00:08:15.520 doing very large pieces of text or image. 00:08:15.820 --> 00:08:21.580 Okay. So then the one sentence summary is someone found a way to do something 00:08:21.580 --> 00:08:27.320 very similar to OP_RETURN, but with a much bigger limit and 00:08:27.320 --> 00:08:32.990 with that cheaper at least cheaper per byte fee 00:08:32.990 --> 00:08:37.790 wise, yeah that's a very ugly sentence but I still think that counts as one 00:08:37.790 --> 00:08:43.740 sentence, whatever okay so that's what it does 00:08:43.740 --> 00:08:49.400 and… And then there was this other thing. I forgot what it was called. We're not 00:08:49.400 --> 00:08:51.580 going to talk about it too much in this episode. 00:08:51.780 --> 00:08:52.420 The ordinals. 00:08:52.620 --> 00:08:53.880 Yeah, right. So ordinals. 00:08:54.000 --> 00:08:56.840 It's part of the ordinals system, which is something completely different, kind 00:08:56.840 --> 00:09:02.040 of a way to do NFTs on the Bitcoin blockchain, I guess. And part of that could be 00:09:02.040 --> 00:09:05.040 that you want to upload the picture of your NFT right onto the Bitcoin 00:09:05.040 --> 00:09:08.680 blockchain. That's one use case. But this mechanism well… 00:09:08.680 --> 00:09:12.540 That's still inscriptions right like the uploading the actual picture? Exactly 00:09:12.540 --> 00:09:16.920 that would be the inscription. And then the ordinal that would be kind of like a 00:09:16.920 --> 00:09:22.880 colored coin essentially that refers to the inscription so then you can quote 00:09:22.880 --> 00:09:28.280 unquote own the inscription in the same way that you can quote unquote 00:09:28.280 --> 00:09:30.620 own an NFT? 00:09:30.620 --> 00:09:34.900 Yeah pretty much but it doesn't really matter because the way that you put data 00:09:34.900 --> 00:09:37.480 on the chain is the same like could be used for other things. 00:09:37.480 --> 00:09:41.820 Yeah right so so that's what the inscriptions are. Inscriptions are uploading 00:09:41.820 --> 00:09:46.620 data into the Bitcoin blockchain and that's probably it seems like that's sort of 00:09:46.620 --> 00:09:51.800 what most of the controversy like the Twitter shitstorm is about and that's also 00:09:51.800 --> 00:09:55.300 what we're gonna address mostly in this episode I don't think we're gonna get 00:09:55.300 --> 00:09:58.580 into ordinals too much although we met well we've already mentioned it. 00:09:59.590 --> 00:10:02.940 So Sjors, what are… How does it work? 00:10:03.000 --> 00:10:06.660 What, what, how did Casey get around this limit, 00:10:07.320 --> 00:10:09.320 this OP_RETURN limit? Well, what’s the… 00:10:09.640 --> 00:10:13.840 Yeah, so basically the way OP_RETURN works is you're creating an output, 00:10:14.040 --> 00:10:19.940 basically. And when you create an output, you basically have to tell the nodes 00:10:19.940 --> 00:10:23.280 or the blockchain what way this output can be spent. 00:10:25.390 --> 00:10:29.210 That's fine you you basically say OP_RETURN and then followed by a bunch of 00:10:29.210 --> 00:10:32.270 gibberish doesn't matter what it is because as soon as the blockchain is reading 00:10:32.270 --> 00:10:36.850 OP_RETURN it stops it says okay it's valid and in fact I'm going to forget it 00:10:36.850 --> 00:10:42.090 because it is unspendable. That's why it's a nice mechanism. And because it's an 00:10:42.090 --> 00:10:46.070 output, you're not getting any SegWit discount. You're paying the normal price if 00:10:46.070 --> 00:10:49.810 you want to get into weight units, four weight units per byte of data. But don't 00:10:49.810 --> 00:10:51.130 worry about weight units, I guess. 00:10:51.370 --> 00:10:56.630 And maybe you're also sort of skipping ahead, which makes it more 00:10:56.630 --> 00:11:02.020 confusing. Anyways, I guess just carry on. So you just explained how OP_RETURN 00:11:02.020 --> 00:11:04.860 works, which is also explained in depth in episode 61. 00:11:05.160 --> 00:11:05.560 Exactly. 00:11:05.780 --> 00:11:07.820 So my question is about inscriptions. 00:11:08.160 --> 00:11:13.090 Exactly. And these are not using outputs, they're using inputs. And an input, 00:11:13.330 --> 00:11:17.590 basically, the goal of an input is to say, okay, here's an output. You just point 00:11:17.590 --> 00:11:22.480 to a transaction hash and an index in the transaction. And here is the piece of 00:11:22.480 --> 00:11:27.940 script, the witness, that you need to spend that output. Now this witness gets a 00:11:27.940 --> 00:11:33.210 4x discount. And so what this new scheme does is it basically puts all the 00:11:33.210 --> 00:11:38.270 OP_RETURN-like data in the witness instead of in the output. 00:11:39.370 --> 00:11:43.530 And now we can get into the way it puts it into the witness. It doesn't really 00:11:43.530 --> 00:11:47.930 matter. But the idea is you need to eventually, when you're spending your own 00:11:47.930 --> 00:11:52.010 coins, you need to provide a signature. But you don't have to do that right away. 00:11:52.270 --> 00:11:56.490 You can do a bunch of nonsense and then provide a signature. Or you can provide a 00:11:56.490 --> 00:12:01.470 signature. And then continue the script, do a bunch of nonsense, and then return. 00:12:01.710 --> 00:12:04.850 And that's basically what you're doing. So either before or after you provide 00:12:04.850 --> 00:12:10.830 your signature, you write on the blockchain OP_FALSE. And what 00:12:10.830 --> 00:12:14.490 that does is it, we talked about Bitcoin scripts all the way, I think in episode 00:12:14.490 --> 00:12:18.870 two, but it basically puts something on the stack called false. Now stack is like 00:12:18.870 --> 00:12:23.250 a pile of plates. So you have a pile of plates, which is exactly one high. The 00:12:23.250 --> 00:12:28.820 word false is on that plate. And then there's the next code is called OP_IF. And 00:12:28.820 --> 00:12:33.200 this OP_IF statement looks at what's the top plate. Well, false. And then it 00:12:33.200 --> 00:12:38.940 says, okay, I'm going to skip until either I see an else or I see an ENDIF. And 00:12:38.940 --> 00:12:42.440 so there is an ENDIF in this particular script. And it turns out that between 00:12:42.440 --> 00:12:47.920 this if statement and the ENDIF statement is where you have all this data that 00:12:47.920 --> 00:12:51.800 you're trying to upload into the blockchain. And as we just described, the OP_IF 00:12:51.800 --> 00:12:55.100 statement means that we're not executing all that data, we're just skipping past 00:12:55.100 --> 00:12:58.270 it. So you're able to do whatever you want because it's not evaluated. 00:12:59.560 --> 00:13:04.940 Okay. That was a very technical explanation and I'm going to try to dumb it down 00:13:04.940 --> 00:13:10.180 a bit. And then if I dumb it down so much that it becomes inaccurate, you should stop me. 00:13:12.430 --> 00:13:17.920 So I think I would sort of explain it in that, you know, a 00:13:17.920 --> 00:13:23.460 transaction includes different kinds of data. So most notably, it includes data 00:13:23.460 --> 00:13:29.200 that says coins are being spent from here. And then other piece of data says it's 00:13:29.200 --> 00:13:34.880 being spent too here. But then to prove that the rightful owner is spending it, 00:13:35.240 --> 00:13:40.820 a signature needs to be added. And the signature is included in yet another part 00:13:40.820 --> 00:13:42.860 of the transaction, which we call the witness. 00:13:43.200 --> 00:13:43.620 Yes. 00:13:43.900 --> 00:13:49.410 And this witness part of the transaction can also include 00:13:49.410 --> 00:13:54.620 other data. And that's where we're putting this data. So we're putting this data, 00:13:54.860 --> 00:14:00.060 these images or whatever it is we're uploading, we're putting it in the witness 00:14:00.060 --> 00:14:05.980 in a way that it's kind of irrelevant for the transaction, but it's still there, 00:14:06.260 --> 00:14:09.060 right? That's kind of the summary, right? 00:14:09.340 --> 00:14:12.200 Yeah. The witness is providing the signature and it's doing a bunch of blah, 00:14:12.280 --> 00:14:13.700 blah, blah that is completely ignored. 00:14:14.120 --> 00:14:19.730 Right. So if my... Bitcoin node sees one of these 00:14:19.730 --> 00:14:25.270 transactions as it has by now because these transactions now exist they just 00:14:25.270 --> 00:14:31.030 see basically a valid transaction and then they see a bunch my node sees a bunch 00:14:31.030 --> 00:14:33.190 of data in the witness but it just 00:14:34.680 --> 00:14:36.860 figures that data is completely irrelevant. 00:14:37.280 --> 00:14:39.680 Yeah, because it's between an if and an ENDIF statement. 00:14:39.880 --> 00:14:44.220 And I'm not even going to remember it because my node is a pruned node. So it 00:14:44.220 --> 00:14:49.580 forgets blocks older than a couple of days. And it's also not in my UTXO set. 00:14:49.900 --> 00:14:53.780 So my node after a couple of days, it doesn't even remember that it was there. 00:14:53.960 --> 00:14:57.600 So if you have a full archival node, so one that keeps all the history, you will 00:14:57.600 --> 00:15:01.000 remember all this stuff and you have to download it once. But if you have a 00:15:01.000 --> 00:15:04.460 pruned node, yeah, you're going to toss it. As you would with OP_RETURN, by the 00:15:04.460 --> 00:15:09.220 way. There's no difference there. And it's not using up any of your RAM. Because 00:15:09.220 --> 00:15:12.520 RAM is only consumed when you create an output. And in this case, you're not 00:15:12.520 --> 00:15:15.920 creating an output. You're spending an output. So the second the output is spent, 00:15:15.980 --> 00:15:19.720 you can forget that output ever existed. And the witness never has to be in RAM 00:15:19.720 --> 00:15:21.540 anyway. Well, except the moment you're checking it. 00:15:22.610 --> 00:15:26.910 Right. So for my node specifically, I think the only cost really was that I had 00:15:26.910 --> 00:15:30.030 to download it once and then maybe upload it to other. 00:15:30.330 --> 00:15:31.190 Yeah, exactly. 00:15:31.510 --> 00:15:34.070 That's sort of the cost for me, but that's sort of it, I think. 00:15:34.290 --> 00:15:34.510 Exactly. 00:15:34.830 --> 00:15:40.330 Okay. But then if you run like a special Bitcoin node, like a inscriptions. 00:15:41.700 --> 00:15:44.540 Yeah, it's not even a node. You just run a piece of software that talks to your 00:15:44.540 --> 00:15:48.320 node and that is able to get the inscriptions out of the blockchain. 00:15:48.540 --> 00:15:53.220 Yeah, so that software will see the same data, but it will say, hey, I know what 00:15:53.220 --> 00:15:55.660 that means. That means... 00:15:56.300 --> 00:15:58.280 Yeah, so that software is looking... 00:15:57.440 --> 00:16:03.320 This is an image or this is whatever and then… Then it is able to subtract an 00:16:03.320 --> 00:16:04.220 image from the blockchain. 00:16:04.440 --> 00:16:08.380 Yeah, so that script will basically ask, probably ask for every transaction in 00:16:08.380 --> 00:16:12.800 the blockchain, one by one, and then it will inspect the transaction and look for 00:16:12.800 --> 00:16:17.040 a certain pattern. And I guess in this case would be looking for an opcode called 00:16:17.040 --> 00:16:22.300 push, followed by the data ord or something like that. And then it processes 00:16:22.300 --> 00:16:24.220 whatever comes after that as a file. 00:16:25.530 --> 00:16:28.570 Right. Okay, so... 00:16:28.570 --> 00:16:32.470 Which, you know, these kind of tools have existed before for image upload using 00:16:32.470 --> 00:16:36.010 OP_RETURN and using all these other mechanisms. There were also scripts that 00:16:36.010 --> 00:16:41.100 would basically work in the same way. In fact, in my book, now that I'm shilling 00:16:41.100 --> 00:16:46.020 that, there's an appendix. I think it's appendix C, which contains the Bitcoin 00:16:46.020 --> 00:16:49.520 white paper, but it also contains instructions of how you can get the Bitcoin 00:16:49.520 --> 00:16:55.080 white paper PDF out of the Bitcoin blockchain with just one very complicated command. 00:16:56.420 --> 00:17:02.280 Right. Okay, so I think we've now explained... So OP_RETURN 00:17:02.280 --> 00:17:08.040 had this limit of how much data you can upload. So I think 00:17:08.040 --> 00:17:13.200 we've now explained how Casey essentially got around this limit to 00:17:13.200 --> 00:17:16.280 otherwise accomplish something very similar. 00:17:16.660 --> 00:17:20.000 Yeah, though you might wonder why there's no such limit in The Witness, right? 00:17:20.060 --> 00:17:20.540 That could have been. 00:17:21.740 --> 00:17:22.540 Sure, yeah. 00:17:22.840 --> 00:17:26.400 But there isn't. And in fact, with SegWit, there were some limits. 00:17:26.540 --> 00:17:26.740 Right. 00:17:27.000 --> 00:17:30.880 And with Taproot to the witness size, so it was still much bigger than what you 00:17:30.880 --> 00:17:34.900 could do with OP_RETURN. But with Taproot, these limits were lifted even more. 00:17:35.100 --> 00:17:40.720 And the main reason for that is to make it simpler to interpret a script Things 00:17:40.720 --> 00:17:43.320 like Miniscript that we've talked about in earlier episodes, when you see a 00:17:43.320 --> 00:17:47.430 script you want to reason about it. Like what kind of properties does it have? 00:17:47.590 --> 00:17:50.790 Can I spend it? Like you might be part of a very complicated multisig and you 00:17:50.790 --> 00:17:54.530 want to make sure that yes, I can provide one signature. And if somebody else 00:17:54.530 --> 00:17:58.350 also provides a signature, it can be spent and the coins are not lost. And this 00:17:58.350 --> 00:18:03.550 type of analysis is easier when there are fewer limits in place. So there were 00:18:03.550 --> 00:18:06.870 good reasons to remove all these limits, but it does mean that you can make a 400 00:18:06.870 --> 00:18:08.670 kilobyte image this way. 00:18:09.050 --> 00:18:11.570 So that's the new limit, 400 kilobytes? 00:18:11.830 --> 00:18:16.450 In practice, yes. And this has to do with standardness. So standardness means 00:18:16.450 --> 00:18:20.750 that this is what nodes will relay by default. But you can take your node and you 00:18:20.750 --> 00:18:25.730 can edit the software and change that particular limit so that you'll gossip even 00:18:25.730 --> 00:18:29.020 transactions with a megabyte. Or four megabytes, actually. 00:18:29.180 --> 00:18:29.520 Four, right? Yeah. 00:18:29.640 --> 00:18:35.120 Yeah. So the real limit is what can be mined. If you contact a miner directly or 00:18:35.120 --> 00:18:40.600 you go Peter Todd style, create an alternative client that does not care about 00:18:40.600 --> 00:18:43.880 this limit and promote this alternative client and then hope that miners will 00:18:43.880 --> 00:18:49.540 actually just look for it with a big enough bounty, then you can actually produce 00:18:49.540 --> 00:18:54.570 a full block, 400 megabyte block. With just a giant movie or whatever it is 00:18:54.570 --> 00:18:58.890 inside of it and I wonder who will be the first person to do that I guess burak 00:19:00.140 --> 00:19:05.990 You could yeah so you could have you could have a block that consists of 00:19:05.990 --> 00:19:11.330 one I guess almost four megabytes transaction that is actually, like you said. 00:19:11.510 --> 00:19:14.490 Yeah, you have to leave a little bit of space because the block has to have a 00:19:14.490 --> 00:19:17.830 header and has to have the coinbase transaction for the miner. And your 00:19:17.830 --> 00:19:22.250 transaction itself has to have a bunch of overhead. It has to probably send the 00:19:22.250 --> 00:19:25.970 money somewhere. So don't make it exactly four megabytes, four million bytes, a 00:19:25.970 --> 00:19:27.870 little bit less. But yeah, you can make it pretty big. 00:19:29.500 --> 00:19:32.900 But you can do the same with OP_RETURN, but then you can only make it one 00:19:32.900 --> 00:19:37.620 megabyte. So in that sense, it's four times cheaper. So with OP_RETURN, if you 00:19:37.620 --> 00:19:41.000 provided it directly to a miner, there's no limit. You can make, as far as I 00:19:41.000 --> 00:19:45.180 know, a one megabyte or slightly less OP_RETURN transaction. But for the same 00:19:45.180 --> 00:19:47.500 cost, you can make a four megabyte inscription. 00:19:48.140 --> 00:19:52.280 Yeah, well, that was going to be my next question or the next point I was going 00:19:52.280 --> 00:19:58.070 to bring up. So we've explained how to get around the OP_RETURN 00:19:58.070 --> 00:20:03.940 limit, so to say. And then the other thing is that how 00:20:03.940 --> 00:20:09.940 inscriptions make use of this SegWit discount. So we 00:20:10.930 --> 00:20:15.170 may have explained this in a previous episode. We probably have or maybe not. I'm 00:20:15.170 --> 00:20:18.630 not sure, but what does this actually mean? Can you explain what the SegWit 00:20:18.630 --> 00:20:23.350 discount is or why people call it that or what is actually, what are we talking about? 00:20:23.450 --> 00:20:27.310 So blocks, as far as old nodes are concerned, pre-SegWit nodes are concerned, are 00:20:27.310 --> 00:20:33.100 one megabyte. And then the question was, how can we, well, two things were 00:20:33.100 --> 00:20:36.440 achieved with SegWit. One was to allow all these new features that SegWit allows, 00:20:36.460 --> 00:20:39.940 and we did an episode about that. But the other was also a block size increase. 00:20:40.930 --> 00:20:46.190 And the way to increase the block size is to put all this witness data in a 00:20:46.190 --> 00:20:50.970 special place that old nodes don't see. And so there's three megabytes worth of 00:20:50.970 --> 00:20:54.790 data in places that old nodes don't see. It's called the witness, or up to three 00:20:54.790 --> 00:20:57.830 megabytes that old nodes don't see. That's the witness data. 00:20:58.760 --> 00:21:00.240 No, it can be up to four, right? 00:21:01.060 --> 00:21:06.480 The entire block can be up to four. Yeah, I guess you're right. The witness data 00:21:06.480 --> 00:21:10.640 can be up to four, but then the main data has to be less because the total has to 00:21:10.640 --> 00:21:13.630 be less than four. The witness plus the non-witness data. 00:21:13.930 --> 00:21:19.060 Yeah. Well, I mean, in this case, that's plausible, right? That's what we talked 00:21:19.060 --> 00:21:19.920 about, the one transaction. 00:21:20.260 --> 00:21:22.260 Yeah, so that's where these weight units come in. If you're creating a 00:21:22.260 --> 00:21:28.240 transaction, a block has to be a maximum of four million weight units. And if 00:21:28.240 --> 00:21:31.800 you're using the non-witness part of a transaction, so the outputs, whatever, 00:21:32.420 --> 00:21:37.990 each unit counts as, I believe, four weight units. Yeah. So 00:21:37.990 --> 00:21:42.690 basically, if you don't use any witness data, your block size is 1 million times 00:21:42.690 --> 00:21:47.010 4. So you're back to one megabyte block for the old nodes. 00:21:48.660 --> 00:21:52.860 And if you use lots of witness data, then you can have a four megabyte block, 00:21:53.410 --> 00:21:55.110 which is what you would do here. 00:21:55.550 --> 00:21:55.770 Yeah. 00:21:57.640 --> 00:22:03.040 It was basically introduced as a way to get around the block size limit without 00:22:03.040 --> 00:22:08.000 requiring a hard fork. So to increase blocks without requiring a hard fork. 00:22:08.260 --> 00:22:12.340 Exactly. And also as an incentive to use SegWit because SegWit is solving some 00:22:12.340 --> 00:22:17.380 other problems that are very expensive in terms of resources for the computer. So 00:22:17.380 --> 00:22:21.000 I guess it's a nice way to say, just use SegWit rather than not SegWit. 00:22:21.100 --> 00:22:26.520 Is that also directly UTXO set related? Isn't that the sort of main thing? 00:22:26.700 --> 00:22:32.180 Because whatever gets into the... Witness will not end up in the UTXO set. Am I 00:22:32.180 --> 00:22:32.700 saying that's right? 00:22:32.780 --> 00:22:36.260 No, it does. The UTXO set contains, well, no, the UTXO set doesn't contain any 00:22:36.260 --> 00:22:36.800 witness data. 00:22:36.980 --> 00:22:37.360 Exactly. 00:22:37.560 --> 00:22:40.000 That's true. But I don't think that's the reason. It has to do with like, if 00:22:40.000 --> 00:22:43.640 transactions get very large, you have certain things that get quadratically more 00:22:43.640 --> 00:22:49.500 expensive to evaluate. And I think SegWit removed those limitations or like made 00:22:49.500 --> 00:22:53.400 it more efficient so that certain transactions when you use SegWit will be less 00:22:53.400 --> 00:22:55.300 bad on your CPU or for example, or 00:22:55.880 --> 00:23:01.480 Right. I definitely remember that it was at least one of the arguments where it 00:23:01.480 --> 00:23:07.360 was claimed that the discount also better aligned incentives. 00:23:07.640 --> 00:23:09.080 I guess I'm just a bit rusty. 00:23:09.380 --> 00:23:14.340 I think what you mean there is that it becomes cheaper to spend coins than to 00:23:14.340 --> 00:23:20.290 create coins. I think it used to be the case that it was cheaper for you 00:23:20.290 --> 00:23:24.520 to... Create lots and lots of change and never really spend your original coins 00:23:24.520 --> 00:23:28.270 unless you were desperate, never combine your coins. And with SegWit, because 00:23:28.270 --> 00:23:32.650 it's much cheaper now to spend coins, you have some extra incentive to spend your 00:23:32.650 --> 00:23:36.510 coins. And by spending your coins, you're reducing the UTXO set size, which means 00:23:36.510 --> 00:23:40.290 you're reducing the amount of RAM used by other people. So in that sense, yes, it 00:23:40.290 --> 00:23:42.050 creates an incentive to start spending coins. 00:23:42.270 --> 00:23:42.650 Right. 00:23:42.910 --> 00:23:44.090 To start combining coins. 00:23:44.830 --> 00:23:50.730 Okay. Well, in any case, I think the point is that through the witness, blocks 00:23:50.730 --> 00:23:56.010 can be bigger so there's a bit more block space and then if a fee market develops 00:23:56.010 --> 00:24:00.930 so if not all transactions fit into blocks then transactions will have to outbid 00:24:00.930 --> 00:24:06.930 each other and if you're using more of the part of the block that's less 00:24:06.930 --> 00:24:12.870 scarce then miners are more inclined to include it because they can include 00:24:12.870 --> 00:24:18.760 more of them right that's how the incentives work and that's why there's a 00:24:18.760 --> 00:24:24.240 quote-unquote discount on using witness data so that's why using 00:24:24.240 --> 00:24:30.120 inscriptions is basically cheaper per byte than using OP_RETURN 00:24:30.120 --> 00:24:35.280 yeah right am I saying it right I think I'm saying it right okay so then 00:24:35.280 --> 00:24:41.040 I I think we've now kind of explained what inscriptions are 00:24:41.040 --> 00:24:46.140 and how they work and maybe we should get a little bit into 00:24:46.940 --> 00:24:52.720 why it is controversial or why are some people angry about this and 00:24:52.720 --> 00:24:53.860 or so 00:24:53.860 --> 00:24:58.840 Yeah well I'm not a psychologist but you could you could argue that bitcoin's 00:24:58.840 --> 00:25:03.660 primary purpose is to make money basically is a censorship resistant system for 00:25:03.660 --> 00:25:09.180 money transfer and if you start doing other things with it that other use case 00:25:09.180 --> 00:25:13.620 might at some point push out the money use case now hopefully 00:25:14.800 --> 00:25:19.140 the fee structure that exists in Bitcoin is enough to make sure that the money 00:25:19.140 --> 00:25:23.260 use case is always going to be basically able to pay for itself and always 00:25:23.260 --> 00:25:27.580 out-compete any other system because it is hopefully in the long term insanely 00:25:27.580 --> 00:25:30.580 expensive to store data on the blockchain. And you have to compete, you know, if 00:25:30.580 --> 00:25:33.220 you want to put your JPEG on the blockchain, that's fine, but you're competing 00:25:33.220 --> 00:25:36.780 with Michael Saylor that wants to spend a billion dollars and is probably able to 00:25:36.780 --> 00:25:40.860 pay a much higher fee on that. So that's the hope. But because this mechanism 00:25:40.860 --> 00:25:46.820 gives you a 4x discount compared to using OP_RETURN, the dynamics just change 00:25:46.820 --> 00:25:50.520 by a factor of four, essentially. The same dynamics where you have a competing 00:25:50.520 --> 00:25:52.320 use case is now four times cheaper. 00:25:52.740 --> 00:25:57.880 Yeah, well, I think the first thing that may be worth mentioning, and you 00:25:57.880 --> 00:26:03.560 mentioned it yourself in the OP_RETURN episode, is that nodes 00:26:03.560 --> 00:26:09.100 don't get paid, right? If you're running a node. And so the idea is, or you know 00:26:09.100 --> 00:26:12.900 this is one of the arguments this is why it's controversial at least in some 00:26:12.900 --> 00:26:17.120 parts of the Bitcoin world is that if you're running a note you're kind of 00:26:17.120 --> 00:26:22.620 agreeing to process transactions also the transactions of other people 00:26:22.620 --> 00:26:28.120 like that's kind of the you know the social contract or whatever you want to call 00:26:28.120 --> 00:26:31.280 it I think that term is very overused but you know that's sort of what you're 00:26:31.280 --> 00:26:37.250 agreeing to do. But you didn't agree to also process or transmit 00:26:37.250 --> 00:26:43.180 or you know store rare Pepes like you did… 00:26:43.180 --> 00:26:48.190 so so then if people start doing that that's kind of abusing 00:26:48.190 --> 00:26:51.500 the system in a way that's kind of the argument. 00:26:51.500 --> 00:26:56.120 It's at least abusing the the altruism of the nodes in the network that we're not 00:26:56.120 --> 00:27:00.100 interested in relaying rare Pepes now you could say well you could just configure 00:27:00.100 --> 00:27:05.010 your note so it doesn't relay rare Pepes unfortunately that It gets you into a 00:27:05.010 --> 00:27:07.790 cat and mouse. Well, it's two problems. It gets you into a cat and mouse game of 00:27:07.790 --> 00:27:11.530 how do you even detect what a rare Pepe is. That might be more work than just 00:27:11.530 --> 00:27:12.750 relaying it, probably. 00:27:12.990 --> 00:27:16.910 Well, you also can't do that. I don't know why you say that. You still have to 00:27:16.910 --> 00:27:17.870 accept the block, right? 00:27:18.730 --> 00:27:19.490 Yeah, the blocks, yes. 00:27:19.630 --> 00:27:20.150 It's still going to be in the block. 00:27:20.230 --> 00:27:22.650 But most of the bandwidth is for relaying transactions. 00:27:24.350 --> 00:27:27.790 Okay, that's fair. But in the end, you still have to process it one way or the other. 00:27:28.010 --> 00:27:28.750 Yeah, that's true. 00:27:29.150 --> 00:27:30.630 What was your second point going to be? 00:27:31.450 --> 00:27:35.370 So you end up with this cat and mouse game. You don't know what is what. The 00:27:35.370 --> 00:27:39.030 second point is, and that comes to relaying transactions. If you decide to not 00:27:39.030 --> 00:27:43.150 relay certain transactions, your mempool is not going to be accurate. Which means 00:27:43.150 --> 00:27:45.930