WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.690 --> 00:00:22.850 Live from Utrecht, this is Bitcoin 00:00:22.850 --> 00:00:24.270 Explained. 00:00:24.590 --> 00:00:24.970 Hey Sjors. 00:00:25.310 --> 00:00:25.650 Hello. 00:00:26.570 --> 00:00:32.330 Sjors, today we're going to cover another Ordinals related topic. Not 00:00:32.330 --> 00:00:36.630 really, but I'm just giving you some context why I came up with this suggestion. 00:00:36.990 --> 00:00:40.930 The reason is over the past couple of weeks I got the same question multiple 00:00:40.930 --> 00:00:44.710 times. Once on a Twitter spaces and I think maybe 00:00:44.710 --> 00:00:50.590 once or twice also just in a private conversation. and the 00:00:50.590 --> 00:00:55.670 question is why is the witness discount there in the first place because that's 00:00:55.670 --> 00:01:00.050 what Ordinals are using no well that's what inscriptions are using I should say 00:01:00.050 --> 00:01:03.950 they're taking advantage of the fact that there is a witness discount Yeah. 00:01:03.950 --> 00:01:09.910 Right, so I got the question why is the discount even there and that's the 00:01:09.910 --> 00:01:12.050 question we're going to answer in this episode isn't that right 00:01:12.050 --> 00:01:14.370 That sounds like a great question let's answer that. 00:01:14.370 --> 00:01:19.980 But first everyone's favorite part of the episode Sjors stacks 00:01:19.980 --> 00:01:24.080 sats. Sjors stacks sats. Sjors stacks sats. 00:01:24.080 --> 00:01:30.020 Well, we have a very recursive sat this this week from ad fake for 12,837 00:01:30.020 --> 00:01:34.420 sats saying Sjors stacks sats with a bunch of emojis. 00:01:34.420 --> 00:01:37.960 You're not saying it right, just you gotta sing it 00:01:39.180 --> 00:01:43.840 you gotta sing it No, it's your you're the one stacking sats you gotta sing it 00:01:43.840 --> 00:01:45.600 you gotta read it out loud singing. 00:01:45.600 --> 00:01:46.860 I don't sing. 00:01:46.860 --> 00:01:49.580 Come on Sjors, everyone wants to hear this. 00:01:50.000 --> 00:01:50.760 I don't sing. 00:01:51.810 --> 00:01:56.270 All right. Well, do you want to tell our listeners how they can help you stack sats? 00:01:56.930 --> 00:02:00.630 Yeah, they can use any of the podcasting 2.0 apps that do this. 00:02:00.930 --> 00:02:02.590 And it's called boostagrams, right? 00:02:02.870 --> 00:02:02.990 Yeah. 00:02:03.270 --> 00:02:08.440 Okay. People can Google that. That was Sjors Stacks Sats. 00:02:09.150 --> 00:02:13.450 Ordinals. No inscriptions. No witness discount. That's what we were. 00:02:13.690 --> 00:02:14.330 That's right. 00:02:14.470 --> 00:02:14.830 Okay. Yeah. 00:02:15.510 --> 00:02:15.950 So... 00:02:16.270 --> 00:02:22.150 also it's it's probably a good topic to cover an episode at this point 00:02:22.150 --> 00:02:27.950 because when this was so the time this was discussed by now you know 00:02:27.950 --> 00:02:32.710 it's been seven eight years Pieter Wuille to be exact proposed 00:02:32.710 --> 00:02:37.330 SegWit which included the discount in December 2015 00:02:38.740 --> 00:02:43.980 and then we had a couple of years of drama and block size wars and scaling all of 00:02:43.980 --> 00:02:49.450 that and it was all discussed to death for a while but and SegWit 00:02:49.450 --> 00:02:55.010 activated in 2017 so even that is almost six years ago by now so there's probably 00:02:55.010 --> 00:02:57.310 a lot of people that weren't around by back then 00:02:57.310 --> 00:02:58.150 That's right. 00:02:58.150 --> 00:03:03.710 that know that there is a discount but just weren't there at the time and even 00:03:03.710 --> 00:03:09.390 for us that's what I was saying when it was asked to me I could sort of answer it 00:03:09.390 --> 00:03:14.750 but to really sort of answer this question properly you and I 00:03:14.750 --> 00:03:20.510 you more than I went back way into the archives and you watched some old 00:03:20.510 --> 00:03:24.610 presentations and tried to figure out what the reasoning was back then. Isn't that right? 00:03:24.890 --> 00:03:25.350 That's right. 00:03:25.630 --> 00:03:31.190 Okay, so before we get there, maybe we should first give a very brief 00:03:31.190 --> 00:03:34.550 recap of what SegWit is? 00:03:34.910 --> 00:03:38.130 Yeah, I think so. We did a whole episode about it. SegWit has many different 00:03:38.130 --> 00:03:42.090 benefits, but the thing that we're focusing here on is that it was also a block 00:03:42.090 --> 00:03:47.440 size increase and that it created the distinction between Well, it basically 00:03:47.440 --> 00:03:51.740 splits the transaction into two parts. The main transaction, so to speak, and the 00:03:51.740 --> 00:03:56.700 witness, which generally is the signature or stuff like a signature, like a hash 00:03:56.700 --> 00:04:01.480 pre-image, things like that. And the thing that I guess people are asking about 00:04:01.480 --> 00:04:06.250 is that these witness data, these signatures... are discounted so if you're you 00:04:06.250 --> 00:04:09.930 know if you're making a transaction that's 300 bytes then you're you're paying 00:04:09.930 --> 00:04:13.170 more for the part of the transaction that is not the witness than you are for the 00:04:13.170 --> 00:04:14.710 part of the transaction that is the witness. 00:04:14.710 --> 00:04:20.160 Yeah, maybe the other thing to mention about SegWit is I don't know if it was the 00:04:20.160 --> 00:04:24.920 main reason but at least one of the big reasons what it was that it also made it 00:04:24.920 --> 00:04:28.240 it fixed the malleability bug right? Well, we did an episode about this we don't… 00:04:28.240 --> 00:04:32.980 Yeah, I mean that that is the exactly that was the main point of it it segregates 00:04:32.980 --> 00:04:35.740 the witness and this fixes malleability. Yeah. 00:04:37.340 --> 00:04:40.480 I mean was it the main point I don't think it really matters at this point but 00:04:40.480 --> 00:04:45.380 there were definitely two main reasons right malleability for Lightning and then 00:04:45.380 --> 00:04:51.340 a block size limit increase that didn't require hard fork 00:04:51.900 --> 00:04:53.560 and that's because of the discount, 00:04:53.560 --> 00:04:57.680 Right, but I don't think that the idea of segregating the witness had nothing to 00:04:57.680 --> 00:05:00.480 do with increasing the block size it's just that people realize that you could 00:05:00.480 --> 00:05:04.820 use it to increase the block size which is kind of a nice bycatch right and once 00:05:04.820 --> 00:05:08.320 you do realize that you can start reasoning why the discount is roughly what it is. 00:05:08.320 --> 00:05:14.090 Okay, so I think that's what we're getting into I think the best way to 00:05:14.090 --> 00:05:18.190 get into it is just restate the question and then you can take it for that from 00:05:18.190 --> 00:05:18.910 there what do you think? 00:05:18.910 --> 00:05:19.830 I can try that. 00:05:19.830 --> 00:05:23.320 Sure. why is there a witness discount? 00:05:23.320 --> 00:05:26.520 Well, it's how you increase the block size. 00:05:26.520 --> 00:05:31.640 Aha, but that's not the only reason right? There's there's more to it. 00:05:31.640 --> 00:05:36.240 Well, there's more going on you just mentioned you don't did you just mention 00:05:36.240 --> 00:05:39.800 this you don't actually have to include a discount to increase the block size 00:05:39.800 --> 00:05:40.340 right? 00:05:40.950 --> 00:05:44.910 Yeah. So, okay. So the question is, if you just wanted to increase the block 00:05:44.910 --> 00:05:48.910 size, how would you do that? Well, the original idea was to do a hard fork where 00:05:48.910 --> 00:05:53.770 you simply increase the block size. So there's just instead of buying five ice 00:05:53.770 --> 00:05:56.810 creams per block, now you can buy 10 ice creams per block. 00:05:57.790 --> 00:06:00.610 You can make double the amount of transactions. 00:06:00.950 --> 00:06:01.350 That's right. 00:06:01.590 --> 00:06:06.310 Right. And hang on. So at this point, we're not even talking 00:06:06.310 --> 00:06:09.210 about... the discount yet right? 00:06:09.210 --> 00:06:13.770 No, this is a very simple way to increase the block size is just a hard fork that 00:06:13.770 --> 00:06:16.090 was known but there were good reasons not to do a hard fork. 00:06:16.090 --> 00:06:19.510 Oh, sorry yeah that you were still in the hard fork part. Yeah, okay, yeah. Let's 00:06:19.510 --> 00:06:24.610 get to SegWit then why was SegWit better other than it wasn't a hard fork or 00:06:24.610 --> 00:06:25.070 wasn't it 00:06:25.390 --> 00:06:31.290 Yeah, so SegWit was so the idea of segregating a witness existed before the idea 00:06:31.290 --> 00:06:36.440 of the soft fork called SegWit right But the question is, but it turns out that 00:06:36.440 --> 00:06:41.160 you can use the soft fork SegWit to increase the block size. And the reason is 00:06:41.160 --> 00:06:46.820 because you are basically making transactions that to old nodes look like they 00:06:46.820 --> 00:06:50.600 don't have a signature. They're just giving away the money for free to anybody 00:06:50.600 --> 00:06:55.460 else who wants it. But new nodes will download essentially a separate block or a 00:06:55.460 --> 00:07:00.650 separate part of the block that is a witness block. And this could be as big as 00:07:00.650 --> 00:07:01.430 you want in theory. 00:07:02.730 --> 00:07:04.430 which means that you could... 00:07:04.430 --> 00:07:10.290 Let's pause there for one second. So even by doing that, that 00:07:10.290 --> 00:07:14.030 would in itself be a block size increase in a way, right? 00:07:14.230 --> 00:07:17.970 It could be a block size increase really depending on how you do it because you 00:07:17.970 --> 00:07:22.950 can add an additional constraint. So if you just say that you can have as much 00:07:22.950 --> 00:07:26.710 witness data as you want, then it would be an infinite block size increase 00:07:26.710 --> 00:07:32.500 essentially. But you could also say, well, you cannot add as much stuff as you 00:07:32.500 --> 00:07:35.980 want the total amount of data. So the total between the block and the witness 00:07:35.980 --> 00:07:39.160 still needs to be one megabyte, for example. So it could have been done without a 00:07:39.160 --> 00:07:39.800 block size increase. 00:07:40.100 --> 00:07:45.260 Okay, I think this is a good point to explain what I meant by that. 00:07:47.940 --> 00:07:53.340 The important part is that old nodes will only accept up to one megabyte of 00:07:53.340 --> 00:07:54.260 transaction data. 00:07:54.520 --> 00:07:54.880 Yes. 00:07:55.160 --> 00:07:59.560 A block must be one megabyte. Now, if you're moving part of the transaction, and 00:07:59.560 --> 00:08:02.200 I think a witness is a big part of the transaction, right? 00:08:02.300 --> 00:08:03.040 Certainly, yes. 00:08:03.420 --> 00:08:07.580 It's around half or even more than half. It depends on the transaction, right? 00:08:07.800 --> 00:08:10.460 Yeah, I think for a typical transaction, it was slightly less than half. 00:08:10.980 --> 00:08:16.880 Yeah, maybe 40%. Anyways, it's roughly half. So in that case, if 00:08:16.880 --> 00:08:21.080 we're assuming there's only going to be regular transactions, which is obviously 00:08:21.080 --> 00:08:25.950 a bad assumption, but let's make that bad assumption, then already... you're 00:08:25.950 --> 00:08:30.330 almost doubling the amount of transactions that can be processed on the network 00:08:30.330 --> 00:08:34.110 just by separating the witness yes right if you're not adding any additional 00:08:34.110 --> 00:08:38.570 constraints because now the base part of the transaction can be up to one 00:08:38.570 --> 00:08:43.130 megabyte all the base parts of every transaction in the block and then all the 00:08:43.130 --> 00:08:48.050 witnesses which is almost half is in a separate part so already you've doubled it 00:08:48.050 --> 00:08:50.170 just by segregating the witness 00:08:51.580 --> 00:08:55.140 under a bad assumption and no additional constraints, right? 00:08:55.480 --> 00:08:55.530 Yes. 00:08:56.510 --> 00:09:00.730 Okay, so maybe a logical next question is, 00:09:01.550 --> 00:09:07.150 why wasn't this done, I guess? Why wasn't this just what segregated witnesses? 00:09:07.490 --> 00:09:11.590 Well, the thing here is that the question is, how big should that extra data be? 00:09:11.710 --> 00:09:16.200 Should there be a limit on it? And if you make that a separate limit, so let's 00:09:16.200 --> 00:09:20.800 say you say the main stuff in the blockchain is one megabyte per block. And the 00:09:20.800 --> 00:09:24.100 witness, we're just going to pick a random number, maybe call it also one 00:09:24.100 --> 00:09:25.400 megabyte or two megabytes, whatever. 00:09:26.260 --> 00:09:29.960 Yeah, let's just also say one megabyte, right? That way it's a doubling. That's 00:09:29.960 --> 00:09:30.600 what I was just... 00:09:30.600 --> 00:09:33.700 Yeah, but if you do that in a naive way where you just say these are separate 00:09:33.700 --> 00:09:39.280 buckets, then you create a very difficult fee market because now in order to 00:09:39.280 --> 00:09:43.300 decide what goes into a block, the miner has to solve what's called a nonlinear 00:09:43.300 --> 00:09:48.020 equation, basically, where they have to decide how... Basically, you have to 00:09:48.020 --> 00:09:51.220 compete for space in the main block and you have to compete for space in the 00:09:51.220 --> 00:09:54.760 witness block and those are completely separate markets. And that is 00:09:54.760 --> 00:09:56.920 mathematically a very hard problem to solve. 00:09:57.160 --> 00:10:02.400 Yeah, I guess the problem, and correct me if I'm wrong, the problem would be that 00:10:02.400 --> 00:10:08.140 a transaction only includes one fee, but now all of a sudden there's kind of two 00:10:08.140 --> 00:10:13.080 markets, one for the base transactions and one for the witness. And so now the 00:10:13.080 --> 00:10:17.540 miner has to make some sort of calculation per transaction, whether to include it 00:10:17.540 --> 00:10:23.070 or not. And depending on those buckets, and this gets very 00:10:23.070 --> 00:10:27.030 complicated very fast for miners to figure out what to include. That's sort of 00:10:27.030 --> 00:10:27.450 right, right? 00:10:27.450 --> 00:10:31.730 Yeah, and it also creates potential for abuse. So let's say the main part of the 00:10:31.730 --> 00:10:36.630 block is the most scarce, and so fees are quite high for that. But once you've 00:10:36.630 --> 00:10:40.110 paid for that, the witness part is really, there's not much competition. So if 00:10:40.110 --> 00:10:44.170 you want to spam the witness part, that might be very cheap, and that creates all 00:10:44.170 --> 00:10:45.510 sorts of weird incentives. 00:10:46.350 --> 00:10:51.410 Right. So this argument can be sums up as things get complicated. 00:10:51.750 --> 00:10:55.270 You don't want to have your fee market based on more than one variable. 00:10:56.500 --> 00:10:56.860 Right. 00:10:57.060 --> 00:11:00.620 And actually, if we look at the modern world, that's not the case because we'll 00:11:00.620 --> 00:11:04.360 probably talk about this in earlier episodes. There's such a thing as transaction 00:11:04.360 --> 00:11:07.380 packages where you cannot look at the fee of one transaction. You have to look at 00:11:07.380 --> 00:11:10.220 the fee of a combination of transactions. So actually, the problem is already 00:11:10.220 --> 00:11:11.400 very hard. 00:11:11.540 --> 00:11:14.720 And also what we mentioned in one of the previous episodes, like the SIGHASH 00:11:14.720 --> 00:11:17.080 limits should maybe be taken into account at this point. 00:11:17.260 --> 00:11:20.480 That was already a factor that you had to take into account. So your fee 00:11:20.480 --> 00:11:23.730 calculations get more difficult if you take the SIGHASH into account. which 00:11:23.730 --> 00:11:25.110 generally we just kind of don't. 00:11:25.430 --> 00:11:31.190 Nevertheless, even though it's still more complicated than one variable, 00:11:31.450 --> 00:11:34.390 it would be worse if there were even more variables. 00:11:34.650 --> 00:11:38.250 Well, there was some discussion on the mailing list that said, well, going from 00:11:38.250 --> 00:11:42.350 one to two variables is very, very bad. Going from two to three is probably not 00:11:42.350 --> 00:11:46.890 as bad. But I guess the hope was to really nail it to one variable and somehow 00:11:46.890 --> 00:11:52.100 find a way to deal with the SIGHASH limit. these things so anyway it's nice to 00:11:52.100 --> 00:11:52.840 have one fee rate. 00:11:52.840 --> 00:11:58.780 Okay, so this okay so go on. so it's nice to have one fee rate I 00:11:58.780 --> 00:11:59.740 mean… 00:11:59.740 --> 00:12:04.660 Well, that means that there has to be one limit and right now as we discussed it 00:12:04.660 --> 00:12:08.100 the simple way would be to have two limits so how do you turn two limits into one 00:12:08.100 --> 00:12:12.000 limit that's essentially what was done and the solution to that is this thing 00:12:12.000 --> 00:12:15.830 called virtual bytes where you say we're not actually counting the real bytes 00:12:15.830 --> 00:12:18.670 anymore we're making this thing called the virtual byte and the simplest way to 00:12:18.670 --> 00:12:23.490 do that might be to say one byte in the main block counts as one virtual byte and 00:12:23.490 --> 00:12:28.190 one byte in the witness counts as one virtual byte so really one byte is one byte 00:12:28.190 --> 00:12:33.070 but we are going to limit the total number of bytes to one million so one 00:12:33.070 --> 00:12:38.140 megabyte So this means that you can have as many witness bytes as you want or as 00:12:38.140 --> 00:12:41.360 many main bytes as you want, but the total has to be 1 million. So now you have 00:12:41.360 --> 00:12:41.860 one limit. 00:12:42.080 --> 00:12:45.920 Okay. Well, the example you just gave would not be a block size increase then, right? 00:12:46.780 --> 00:12:49.120 Exactly. That would be no block size increase. 00:12:49.320 --> 00:12:49.520 Right. 00:12:49.740 --> 00:12:54.460 If you wanted to do your 2 megabyte example, then you would have to make the 00:12:54.460 --> 00:13:00.390 limit 2 megabytes. So you would say, but that's not possible, right? Naively. 00:13:00.710 --> 00:13:06.110 Because if you... Because you said the total limit has to be two, but you can't 00:13:06.110 --> 00:13:10.650 have the main block be more than one. So that's not possible, naively. 00:13:10.950 --> 00:13:15.150 The reason it's not possible to make that very clear is it wouldn't be backwards 00:13:15.150 --> 00:13:15.590 compatible. 00:13:15.830 --> 00:13:16.090 Exactly. 00:13:16.410 --> 00:13:20.250 Old nodes would now see two megabyte blocks and reject them while new nodes would 00:13:20.250 --> 00:13:22.670 be fine with them. So that's the reason you're saying it's not possible. 00:13:22.910 --> 00:13:26.090 So first we started with, we split the witness out from the main data. Then we're 00:13:26.090 --> 00:13:29.230 like, oh, that gives us a lot of extra space. But oh my God, now we have this 00:13:29.230 --> 00:13:33.170 super complicated fee market that nobody can reason about. Let's bring back the 00:13:33.170 --> 00:13:37.230 limit of one megabyte for the total amount. So now we don't have a block size 00:13:37.230 --> 00:13:42.590 increase anymore. What do we do? and this is where the witness discount comes in. 00:13:42.590 --> 00:13:47.270 Well, or you're missing one step or we can increase it but then it wouldn't be 00:13:47.270 --> 00:13:51.730 backwards compatible that'd be hard fork, so not Yeah, so now that so this is 00:13:51.730 --> 00:13:56.310 where the discount comes in okay so how does the discount actually work maybe 00:13:56.310 --> 00:13:57.570 that's a good next question? 00:13:57.570 --> 00:14:01.950 Yeah, so what the discount does it's more like a you could also see it as a tax 00:14:01.950 --> 00:14:07.140 on the old stuff. It's basically saying every part of the old chain is, sorry, 00:14:07.880 --> 00:14:11.860 every part of the main part of the transaction, which means all the outputs and 00:14:11.860 --> 00:14:17.840 all the sort of stuff in the middle of a transaction counts as four, and all 00:14:17.840 --> 00:14:22.900 the witness stuff counts as one. And then we say the total is, in this way of 00:14:22.900 --> 00:14:26.910 counting, is four million. And so what that means is if you only use old stuff, 00:14:27.210 --> 00:14:31.150 every byte counts as four. So if you only use, basically you don't use SegWit at 00:14:31.150 --> 00:14:35.850 all, your block gets to be one megabyte and then you hit this four weight limit 00:14:35.850 --> 00:14:36.550 limit. 00:14:36.850 --> 00:14:42.570 Yeah, it's a little bit confusing here because again, when we say 00:14:42.570 --> 00:14:46.430 we're going to make the new limit four, wait, what did you say? 00:14:46.430 --> 00:14:49.670 You can also do it the other way around. You can say, well, we'll count the main 00:14:49.670 --> 00:14:55.380 parts as one. So one megabyte of main stuff is one megabyte block in total. And 00:14:55.380 --> 00:14:58.220 we're going to count everything in the witness. We're going to count that as 00:14:58.220 --> 00:14:58.880 0.25. 00:14:59.360 --> 00:14:59.940 So one quarter. 00:15:00.360 --> 00:15:01.580 That's maybe easier to think about. 00:15:01.780 --> 00:15:04.520 Actually, yeah, I was just going to say that's an easier way to understand it. 00:15:04.580 --> 00:15:05.700 And it's kind of equivalent. 00:15:05.900 --> 00:15:10.220 And this is the difference between weight units and virtual bytes. So this last 00:15:10.220 --> 00:15:14.020 thing we talked about are virtual bytes. So we say one virtual byte in the main 00:15:14.020 --> 00:15:17.810 part of the block or in the main part of the transaction is just one byte. but 00:15:17.810 --> 00:15:21.530 one byte in the witness part counts as 0.25 virtual bytes. 00:15:21.890 --> 00:15:27.880 Right. So now there's a block being mined with, yeah, just one 00:15:27.880 --> 00:15:33.280 megabyte of all transaction styles. So now both new and old nodes will just see 00:15:33.280 --> 00:15:34.360 one megabyte. It's fine. 00:15:34.540 --> 00:15:34.680 Yep. 00:15:37.130 --> 00:15:41.010 And the alternative is, okay, so the other extreme would be there's going to be 00:15:41.010 --> 00:15:46.570 four megabytes of witness stuff, and then new nodes are going to 00:15:46.570 --> 00:15:52.350 discount this. 0.25 so now they're seeing one megabyte again so 00:15:52.540 --> 00:15:57.230 that's within their limit as we're talking about weight limits yeah and then all 00:15:57.230 --> 00:16:00.230 the nodes are just going to see nothing essentially they're going to see an empty 00:16:00.230 --> 00:16:04.530 block because everything is in the witness precisely so an empty block is also 00:16:04.530 --> 00:16:09.370 within the one megabyte limit so now both nodes are okay yeah exactly okay so 00:16:09.370 --> 00:16:15.090 basically what we've said now that so this sounds a lot this argument 00:16:15.090 --> 00:16:21.040 sounds a lot like It is kind of an accounting trick. We just want to make sure 00:16:21.040 --> 00:16:26.320 that we have a block size increase while we don't create different fee markets 00:16:26.320 --> 00:16:27.880 because that gets very complicated. Right. 00:16:27.980 --> 00:16:32.340 So I would always or I would tend to separate it in three concerns that we need 00:16:32.340 --> 00:16:36.380 to deal with. One is that you want to have one market despite having this 00:16:36.380 --> 00:16:39.680 separate witness. The other is that we wanted to have a block size increase 00:16:39.680 --> 00:16:45.220 somehow. And the third is then the way you do that is by having this discount in 00:16:45.220 --> 00:16:48.880 the witness data. But you could kind of do these things separately. So we could 00:16:48.880 --> 00:16:53.420 have separated the witness, but kept the block size the same. And we could have 00:16:53.420 --> 00:16:56.580 increased the block size without SegWit, I guess. But if you wanted to increase 00:16:56.580 --> 00:17:00.500 the block size and have SegWit, then the only way to do that is with this witness 00:17:00.500 --> 00:17:05.860 discount. Now, the exact number is somewhat arbitrary. Well, we can defend that 00:17:05.860 --> 00:17:07.920 number, but that will be the next phase. 00:17:10.960 --> 00:17:13.880 Now we've explained why you really need to have a discount. 00:17:15.000 --> 00:17:20.700 yeah okay so we can defend the number before we get to defending the number I 00:17:20.700 --> 00:17:24.340 think there is also an argument or at least there was an argument 00:17:26.060 --> 00:17:31.620 a more technical argument for giving a discount it would better align incentives 00:17:31.620 --> 00:17:33.940 of the Bitcoin system is that right? 00:17:33.940 --> 00:17:37.780 Yeah, and there's there's kind of two ways to look at those incentives we're 00:17:37.780 --> 00:17:42.500 talking about the UTXO set essentially so this is the the set that you're kind of 00:17:42.500 --> 00:17:46.040 keeping either in memory or at least you you very often need to read read it 00:17:46.040 --> 00:17:51.680 which is the list of who owns which coin and by using this discount mechanism 00:17:51.680 --> 00:17:56.040 that list tends to not grow a lot And there's two ways to look at that. One is 00:17:56.040 --> 00:18:00.180 we're saying, I guess the more abstract way is to say the block size is 00:18:00.180 --> 00:18:04.180 increasing, but the only part that is increasing is the witness. And the witness 00:18:04.180 --> 00:18:09.360 does not go into the UTXO set ever. You check the witness, but you don't put it 00:18:09.360 --> 00:18:13.320 in the UTXO set. So by only increasing the witness size, you are increasing the 00:18:13.320 --> 00:18:17.960 block size without increasing the UTXO set. The other way to look at it. It's 00:18:17.960 --> 00:18:22.720 more from an individual transaction point of view, where before SegWit, it was 00:18:22.720 --> 00:18:28.090 much more expensive to spend an input than to create an output 00:18:28.090 --> 00:18:29.890 for a very basic transaction. 00:18:30.230 --> 00:18:32.610 Wait, before? Sorry, can you repeat that for me? 00:18:32.850 --> 00:18:36.870 Before SegWit, it was more expensive to spend an input than to create a new 00:18:36.870 --> 00:18:40.790 output. And the reason is because when you're spending an input, you need to put 00:18:40.790 --> 00:18:46.190 on the blockchain usually a public key and a signature. Because you're trying to 00:18:46.190 --> 00:18:52.030 prove that you have the hash. And so that's about 90 bytes, roughly. Whereas to 00:18:52.030 --> 00:18:58.030 create a new output is basically just 20 bytes. Because you only need 00:18:58.030 --> 00:19:02.990 to put the hash of a thing on there. Well, at least it's 20 bytes more than a few 00:19:02.990 --> 00:19:05.770 other things. You also have to put the amount on the chain, etc. That doesn't 00:19:05.770 --> 00:19:11.630 change. So SegWit changes this because of the discount. Changes this 00:19:11.630 --> 00:19:12.070 math. 00:19:12.860 --> 00:19:18.820 What does it, though? Because you just said it's 90 versus 20. 90 for 00:19:18.820 --> 00:19:20.880 an input, 20 for an output. 00:19:21.160 --> 00:19:23.980 Yeah, and so the input now gets a 4x discount. 00:19:24.180 --> 00:19:24.440 Yes. 00:19:24.860 --> 00:19:27.540 So that makes it, you know, it's still slightly more expensive. 00:19:27.740 --> 00:19:31.860 It's only the witness, right? Yes. And there's more to the input, I would assume. 00:19:32.300 --> 00:19:37.580 Yes, exactly. So it doesn't work exactly like this because the input also has to 00:19:37.580 --> 00:19:40.440 point to the previous transaction that takes up space. 00:19:40.660 --> 00:19:40.980 Right. 00:19:41.260 --> 00:19:42.900 And that doesn't get a discount. 00:19:43.160 --> 00:19:43.320 Right. 00:19:43.820 --> 00:19:47.640 But at least it makes it significantly less expensive to spend an input than it 00:19:47.640 --> 00:19:48.080 used to be. 00:19:48.300 --> 00:19:53.820 Okay, so it's about equal now? Creating an input is about as expensive as 00:19:53.820 --> 00:19:54.540 creating an output? 00:19:54.940 --> 00:19:58.480 I mean, it still depends on which kind of input and which kind of output. I think 00:19:58.480 --> 00:20:04.320 it's still slightly more expensive to spend it. Yeah, slightly more expensive to 00:20:04.320 --> 00:20:06.320 spend it. But at least the difference isn't as big anymore. 00:20:06.540 --> 00:20:10.500 Okay, and what is the practical benefit of this? 00:20:11.650 --> 00:20:15.890 Well, so yeah, so I read, I think it was the Stack Overflow or Reddit somewhere 00:20:15.890 --> 00:20:19.470 where somebody gave a nice example of like you have a wallet and has three coins 00:20:19.470 --> 00:20:25.270 in it. It has a 0.25, a 0.5 and a one BTC coin in it. And you 00:20:25.270 --> 00:20:30.090 want to spend 0.75. So anybody who's very good at math can see there's two ways 00:20:30.090 --> 00:20:35.270 to do that. You can combine your 0.25 and your 0.5 coin. That's 0.75. 00:20:35.830 --> 00:20:41.570 Or you can use your one BTC coin and you get... 0.25 and change those are your 00:20:41.570 --> 00:20:47.270 two options and in the old situation because it is so expensive to spend an input 00:20:47.270 --> 00:20:53.050 you would be better off taking your one BTC coin and then just creating the 00:20:53.050 --> 00:20:56.050 change address rather than spending those two coins 00:20:56.050 --> 00:21:00.450 Right, so then you have four—no, then you have three UTXOs still. 00:21:00.930 --> 00:21:02.070 Yes. 00:21:03.340 --> 00:21:07.280 Plus the UTXO that's being spent to the ice cream seller. 00:21:07.520 --> 00:21:08.600 Well, that's not your problem. 00:21:08.840 --> 00:21:13.900 Yeah. Okay, so maybe this is part of my confusion then. 00:21:14.060 --> 00:21:15.680 The incentive for you in the old days... 00:21:15.680 --> 00:21:17.600 We're really talking about individual incentives here. 00:21:17.680 --> 00:21:23.020 Yeah, so in the old days for you as the sender, it was better to just take your 00:21:23.020 --> 00:21:28.110 1BTC coin and get some change back. because the change that you have to create is 00:21:28.110 --> 00:21:32.450 only 22 bytes, at least the part that, you know, you're actually, 20 bytes, 00:21:32.610 --> 00:21:35.130 sorry, the part that you're actually putting, that you have some control over. 00:21:36.280 --> 00:21:39.920 Whereas if you had to spend that old coin, you had to use these 90 bytes, so 00:21:39.920 --> 00:21:43.460 these 90 bytes, if you wanted to add, sorry, if you wanted to add those two coins. 00:21:44.700 --> 00:21:47.360 You have to spend at least one coin, right? So the difference is, do you spend an 00:21:47.360 --> 00:21:52.580 extra coin? and make change and don't have change or do you not do that and only 00:21:52.580 --> 00:21:55.980 have change and so that the difference is 90 versus 20 so the difference is 00:21:55.980 --> 00:21:56.860 roughly 70 bytes 00:21:56.860 --> 00:21:58.260 Yeah, but hang on. 00:21:58.260 --> 00:21:59.620 And with SegWit the difference is much smaller. 00:21:59.620 --> 00:22:05.320 Sjors, I'm confused okay you're saying this is in my individual benefits but who 00:22:05.320 --> 00:22:08.400 cares about my individual benefit isn't isn't the goal you 00:22:08.400 --> 00:22:08.560 do. 00:22:09.550 --> 00:22:15.450 Yes, but why do Bitcoin developers because isn't the goal wasn't the goal to 00:22:15.450 --> 00:22:16.810 reduce the UTXO set? 00:22:17.180 --> 00:22:21.900 Yeah, exactly. So it would be nice if the incentives are such that you prefer to 00:22:21.900 --> 00:22:27.120 spend your coins, I.e. you reduce the size of the UTXO set. It should be in your 00:22:27.120 --> 00:22:27.840 interest to do that. 00:22:29.100 --> 00:22:29.500 Yes. 00:22:29.780 --> 00:22:34.670 And it wasn't. Because in this example we just made, it was much cheaper for you 00:22:34.670 --> 00:22:39.470 to not spend the small change that you had in your wallet, but rather just 00:22:39.470 --> 00:22:42.870 fragment it further and further and further and further. Maybe in the long run 00:22:42.870 --> 00:22:44.970 that changes, of course, because eventually you'll have to spend it. 00:22:45.410 --> 00:22:51.170 Would this only hold up if you can add up your UTXOs to make a 00:22:51.170 --> 00:22:54.210 payment in such a way that there's no change address? 00:22:55.640 --> 00:22:56.680 Yeah, I think so. 00:22:57.060 --> 00:23:02.980 Right. Okay. So in the cases where you can add up UTXOs to prevent 00:23:02.980 --> 00:23:08.860 getting a change address, in these cases, it's better to have the 00:23:08.860 --> 00:23:14.120 discount because you're incentivized to actually do that rather than to take one 00:23:14.120 --> 00:23:19.200 big chunk of coin. and get a change address and only have one input yeah okay I 00:23:19.200 --> 00:23:21.360 think that makes sense that sounds about right to me 00:23:21.360 --> 00:23:24.740 Yeah, and of course it is always more complicated because you have to think about 00:23:24.740 --> 00:23:28.580 what's the future fee rate going to be so I've created all these change outputs 00:23:28.580 --> 00:23:31.540 okay but now you're stuck with them so eventually maybe you still want to 00:23:31.540 --> 00:23:35.460 consolidate them and if you expect fees to go up in the future it may still be in 00:23:35.460 --> 00:23:38.980 your interest to make sure you don't have too many small coins because it's going 00:23:38.980 --> 00:23:41.600 to make your life harder in the end yep. 00:23:42.400 --> 00:23:48.340 okay so this is this is the argument for why it's better aligns incentives 00:23:48.340 --> 00:23:53.540 with the greater Bitcoin protocol essentially right yeah with the Bitcoin system 00:23:53.540 --> 00:23:58.100 was this the only argument in that direction or was there something else 00:23:59.410 --> 00:24:03.590 Yeah, well, the other was basically, well, I guess that gets us to why the 4x 00:24:03.590 --> 00:24:04.170 would be good. 00:24:04.250 --> 00:24:09.990 That was going to be my next question. Yeah, why 4x and why not 2x or 8x or 500x? 00:24:10.010 --> 00:24:13.210 Yeah, so first of all, I think, I mean, the number was, I don't think it was 00:24:13.210 --> 00:24:17.530 calculated with any precision, with any kind of algorithm. It was sort of a 00:24:17.530 --> 00:24:21.690 guesstimate. And then it's useful to understand that software developers like 00:24:21.690 --> 00:24:25.390 powers of two. So they like the number 1, they like the number 2, they like the 00:24:25.390 --> 00:24:30.490 number 4, they like the number 8, 16, 32, etc. They don't like numbers like 3 and 00:24:30.490 --> 00:24:35.590 5. So really, you know, why is it 4, why is it not 2, why is it not 8 should be 00:24:35.590 --> 00:24:40.880 your question. And then you, basically the analysis is kind of like this. 00:24:41.540 --> 00:24:47.320 The part that you're making more difficult is the signature validation. 00:24:47.320 --> 00:24:51.660 So you're adding four times as much signature stuff potentially because you're 00:24:51.660 --> 00:24:56.220 giving it a discount. And it turned out that recently it became about five to 00:24:56.220 --> 00:24:58.660 seven times easier to verify those signatures. 00:24:58.960 --> 00:25:02.520 Well, when you say recently, you mean recently before SegWit was introduced. 00:25:02.700 --> 00:25:07.160 That's right. Because we did another episode a long time ago called libsecp256k1, 00:25:07.360 --> 00:25:11.840 where we explained this library that essentially is purpose-built for Bitcoin 00:25:11.840 --> 00:25:16.480 that just validates signatures and a few other things. And that library was made 00:25:16.480 --> 00:25:19.640 about, yeah, like I said, it was about five or seven times faster. 00:25:20.900 --> 00:25:26.380 So knowing that you can verify five times more signatures per second means that 00:25:26.380 --> 00:25:30.160 it's kind of okay if there are five times more signatures, at least from the 00:25:30.160 --> 00:25:35.160 point of view of your CPU. So if you look at computer science in general, there's 00:25:35.160 --> 00:25:39.860 kind of different bottlenecks. One of your bottlenecks is your CPU, the other is 00:25:39.860 --> 00:25:42.800 your RAM, the other is your download, and the other is maybe your disk storage. 00:25:44.510 --> 00:25:49.810 And so here the idea was, yeah, we can probably reasonably safely increase this 00:25:49.810 --> 00:25:53.010 by four because it doesn't make it much worse. 00:25:53.650 --> 00:25:58.790 And that was because the library was updated is what you were saying. The other 00:25:58.790 --> 00:26:02.770 thing I do remember, I don't know how big of a factor that was really for the 00:26:02.770 --> 00:26:08.370 developers, but I think it was Jonathan Toomim who was a Bitcoin, 00:26:08.370 --> 00:26:14.200 one of the forks, Bitcoin Classic. Bitcoin Classic developer I think 00:26:14.200 --> 00:26:19.790