WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.460 --> 00:00:22.560 Live from Utrecht this is Bitcoin 00:00:22.560 --> 00:00:23.640 Explained. 00:00:23.640 --> 00:00:25.060 Hey Sjors. 00:00:25.060 --> 00:00:25.800 Hello. 00:00:25.800 --> 00:00:31.280 we're back and today we're gonna talk about multisig and cool 00:00:31.280 --> 00:00:32.120 MuSig. 00:00:32.120 --> 00:00:33.500 Music? 00:00:33.700 --> 00:00:39.420 That pun is too easy even for our show Sjors. Okay, but first of all 00:00:39.610 --> 00:00:45.070 you want we gave you your special part of the show I'll give you the… 00:00:45.610 --> 00:00:46.850 Are you going to do the song again? 00:00:46.970 --> 00:00:52.590 Of course. Sjors stacks sats. Sjors stacks sats. Sjors stacks sats. 00:00:53.190 --> 00:00:56.890 And of course our editor will run it through the auto tune so that it sounds 00:00:56.890 --> 00:01:02.790 cool. Yeah. So we've got one from Slim Shady. And he sends us 101 00:01:02.790 --> 00:01:06.210 sats for the tune. And another one. 00:01:06.310 --> 00:01:07.470 I'm not even getting the money. 00:01:08.180 --> 00:01:13.160 You're not. And from Vake, 6,000 sats. Learning a lot from each episode. 00:01:14.080 --> 00:01:14.600 So. 00:01:15.320 --> 00:01:17.420 That's good. Glad to hear that. 00:01:18.910 --> 00:01:22.190 And congratulations on the money. 00:01:23.860 --> 00:01:25.500 Ready for the rest of the episode? 00:01:25.860 --> 00:01:26.380 yes 00:01:26.380 --> 00:01:31.300 okay so we're going to discuss multisig which is of course a topic, we've 00:01:31.300 --> 00:01:35.780 mentioned probably many times by now but we've never done a full episode on 00:01:35.780 --> 00:01:40.140 multisig so that's what we're doing today. and we're going to discuss sort of how 00:01:40.140 --> 00:01:45.600 multisig has evolved over the years so the different ways of doing multisig all 00:01:45.600 --> 00:01:49.220 of which are still possible I guess right? we don't you know we don't remove 00:01:49.220 --> 00:01:53.040 options from Bitcoin, so every option that we're going to discuss is actually 00:01:53.040 --> 00:01:53.740 available today. 00:01:54.230 --> 00:01:56.590 Well, some of them are not, but we'll get to those. 00:01:56.910 --> 00:02:01.110 I guess at the very end we're going to discuss some future potential ways to do 00:02:01.110 --> 00:02:02.830 multisig. Is that what you're referring to or not? 00:02:03.250 --> 00:02:05.010 No, I was referring to some early bugs. 00:02:05.630 --> 00:02:10.270 Oh, okay. I guess I'll hear about that in a minute then, as well you are the listener. 00:02:10.890 --> 00:02:14.010 Yeah, and we're also not going to talk about the combination of multisig and 00:02:14.010 --> 00:02:16.650 timelocks and all these kind of things you can do. We're going to talk about 00:02:16.650 --> 00:02:21.930 pretty much the opcode of multisig and its successor in Taproot. 00:02:22.540 --> 00:02:27.500 yeah there are some tie-ins with our previous episode that's also where we got 00:02:27.500 --> 00:02:32.380 the idea to do this episode because in our previous episode on P2SH we kind of 00:02:32.380 --> 00:02:37.340 touched on some of this stuff I don't think the previous episode is required 00:02:37.340 --> 00:02:40.320 listening for this episode but it might help Right, Sjors? 00:02:40.320 --> 00:02:41.220 Yeah, it's not. 00:02:41.220 --> 00:02:47.220 Yeah, okay, so first of all let's let's start at the beginning as always, in, 00:02:47.220 --> 00:02:53.130 very general terms what is multisig? Do you even want to... 00:02:53.290 --> 00:02:58.730 Yeah, the idea is that you can create a transaction that can be signed using not 00:02:58.730 --> 00:03:04.330 just one key, but either multiple keys or one out of keys. So 00:03:04.330 --> 00:03:08.330 you might say, okay, there's three possible keys that I can sign with, three of 00:03:08.330 --> 00:03:12.430 my different hardware wallet devices, and I only need to provide two of them or 00:03:12.430 --> 00:03:15.720 one of them. Or three of them that's what multisig does. 00:03:15.720 --> 00:03:19.700 Yeah, I think in technical terms usually you're the one using the technical terms 00:03:19.700 --> 00:03:24.880 and then I try to dumb it down but in technical terms it's M of M or M of N am I 00:03:24.880 --> 00:03:25.340 saying that's right? 00:03:25.340 --> 00:03:26.140 Yeah, M of N. 00:03:26.750 --> 00:03:32.950 Or N of N right? that's also so N of N would be I mean M of N means that… 00:03:32.950 --> 00:03:38.850 N of M. N of N means that M is equal to N. But yes 00:03:38.850 --> 00:03:40.430 we then you call it N of N. 00:03:42.310 --> 00:03:47.330 Anyways, it means you can have a number of potential keys to sign with, and then 00:03:47.330 --> 00:03:51.370 another equal or smaller number of these keys. 00:03:51.750 --> 00:03:54.170 We're making this more confusing. Yes, and the cryptographers who try to explain 00:03:54.170 --> 00:03:57.410 this stuff like to write things down, so they don't care that the word M is 00:03:57.410 --> 00:03:58.690 pronounced almost the same as N. 00:03:59.030 --> 00:04:04.170 Right. Okay, well, I think everyone knows what multisig is anyways, so we don't 00:04:04.170 --> 00:04:07.750 have to really get into that. Well, okay, one more thing. Why would people want 00:04:07.750 --> 00:04:09.870 to use this? Do you want to give some examples of that? 00:04:10.610 --> 00:04:16.130 Yeah, I mean, the initial use case was a thought of use case was escrow. So the 00:04:16.130 --> 00:04:20.130 idea would be that you would send money to a third party, but then there would be 00:04:20.130 --> 00:04:24.330 an escrow agent in the middle who would hold the money for you. And the idea is 00:04:24.330 --> 00:04:30.310 that this escrow person or company would have one key and you, the sender, has 00:04:30.310 --> 00:04:34.200 one key and me, the recipient, has another key. And then you need two out of 00:04:34.200 --> 00:04:39.480 three. So I send it to the escrow. And then if we both agree, we both sign and it 00:04:39.480 --> 00:04:43.460 goes away from the escrow. The escrow agent is not necessary. If we disagree, 00:04:44.020 --> 00:04:47.840 then the escrow agent will either, you know, will provide a signature either to 00:04:47.840 --> 00:04:49.820 send it back or to send it forward. 00:04:50.690 --> 00:04:56.010 Yeah, or another way to use this is something we've discussed in a previous 00:04:56.010 --> 00:05:01.930 episode about... smart contracts maybe I think where we could we can sort of 00:05:01.930 --> 00:05:07.590 construct proto smart contracts using this where we for example bet on I think 00:05:07.590 --> 00:05:11.450 the example we used was the winner of the world cup and then we have a neutral 00:05:11.450 --> 00:05:15.250 party and we all the three of us have a key you and I bet. 00:05:15.250 --> 00:05:18.750 yeah that was in the episode about discreet log contracts so you can do fairly… 00:05:18.750 --> 00:05:22.750 you can do Lightning obviously that also uses multisig so but the initial use 00:05:22.750 --> 00:05:26.250 case I think was escrow Because that's sort of what people were talking about in 00:05:26.250 --> 00:05:30.450 the comments on GitHub. and even in the source code it was kind of referring to 00:05:30.450 --> 00:05:32.550 escrow but obviously you can do more with it. 00:05:32.550 --> 00:05:37.910 yeah well another very basic example is for example you split 00:05:37.910 --> 00:05:43.770 your own funds across multiple keys right so you sent your own funds you you 00:05:43.770 --> 00:05:48.910 store you save your money your Bitcoin in a multisig address of your own and you 00:05:48.910 --> 00:05:52.110 for example have three keys and you keep these three keys on three different 00:05:52.110 --> 00:05:56.890 machines could be three hardware wallets for example and you store these hardware 00:05:56.890 --> 00:06:01.390 wallets in different locations that way a hacker would have to steal two of your 00:06:01.390 --> 00:06:05.950 three hardware wallets in order to even have a chance to get your funds. yeah for 00:06:06.140 --> 00:06:10.640 example that that's another or another example would be I'll after this example 00:06:10.640 --> 00:06:16.430 we'll move on but another other example would be three people want to or two or 00:06:16.430 --> 00:06:22.070 whatever number of course they want to just store funds collectively and only if 00:06:22.070 --> 00:06:27.370 some subset of them agree to spend the funds they can do it so for example a 00:06:27.370 --> 00:06:32.390 board of a company that consists of you know three board members and they agree 00:06:32.390 --> 00:06:35.910 that two of them will have to sign off to spend money then they can set up a two 00:06:35.910 --> 00:06:39.690 of three multisig address so that would be another example and there's plenty of 00:06:39.690 --> 00:06:43.090 other examples but we won't bore you anymore with that we'll get to the meat of 00:06:43.090 --> 00:06:48.420 the episode So it's yours, multisig. Multisig has been in Bitcoin since the very 00:06:48.420 --> 00:06:49.380 beginning, I think, right? 00:06:49.740 --> 00:06:52.620 Yeah. I thought you were going to make a pun about raw meat. 00:06:53.400 --> 00:06:55.120 Feel free to make it. What's the pun? 00:06:55.320 --> 00:07:00.200 Well, the original version is called raw multisig. Or actually, it's called bare 00:07:00.200 --> 00:07:00.660 multisig. 00:07:00.660 --> 00:07:02.140 There's some potential for a pun then. 00:07:02.400 --> 00:07:03.380 I think I wrote it down incorrectly. 00:07:04.930 --> 00:07:09.310 You're right. Let's get to the raw meat, raw multisig of the episode. It's yours. 00:07:11.120 --> 00:07:15.480 So it's been in Bitcoin since the very beginning. Satoshi implemented multisig. 00:07:15.720 --> 00:07:19.220 Yeah. So from the beginning, it was an op code. So that's one of the commands 00:07:19.220 --> 00:07:23.430 that you can put in a script. And it was just called OP_MULTISIG. And it's just 00:07:23.430 --> 00:07:29.310 there, OP_CHECKMULTISIG. And this was, well, the idea was that this you 00:07:29.310 --> 00:07:33.810 would put as the recipient, you would provide the script saying OP_MULTISIG. And 00:07:33.810 --> 00:07:37.450 then you would also provide two or three or whatever keys. And you would specify 00:07:37.450 --> 00:07:43.430 the threshold. So you would say two and then you would list three keys. That 00:07:43.430 --> 00:07:46.650 would mean you need two out of three signatures to satisfy the script. 00:07:46.910 --> 00:07:47.210 Right. 00:07:47.430 --> 00:07:51.430 And there was no address format for this to be able to communicate this. So we 00:07:51.430 --> 00:07:56.030 talked about that with P2SH because you, the sender, will have to put that script 00:07:56.030 --> 00:08:00.170 on the blockchain. So that means if you wanted to do a 20 out of 20 multisig, the 00:08:00.170 --> 00:08:03.410 sender would have to make a very long transaction and pay the fees for your 00:08:03.410 --> 00:08:04.230 complicated setup. 00:08:05.030 --> 00:08:10.470 Yeah, that was one of the problems, right? So I'm the one… I want to receive 00:08:10.470 --> 00:08:16.380 the coins in a specific way but now you Sjors, 00:08:16.380 --> 00:08:20.380 who are sending the money to me you have to pay for that rather than me having to 00:08:20.380 --> 00:08:24.040 pay for that was one of the exact problems with the original multisig. 00:08:24.040 --> 00:08:28.400 yeah so and and that and the fact that there's no standard address format for it, 00:08:28.400 --> 00:08:32.760 although that of course that could be invented Now, the more interesting part is 00:08:32.760 --> 00:08:37.980 that originally this had no limit. So you could, at least from a consensus point 00:08:37.980 --> 00:08:41.340 of view, I don't know about standardness. So standardness is what nodes will 00:08:41.340 --> 00:08:45.600 relay to each other and what miners will mine by default. But consensus means 00:08:45.600 --> 00:08:49.820 that even if it's in a block, you're going to check by less strict rules. And 00:08:49.820 --> 00:08:53.340 there was no limit on the size of a multisig, as far as I know, in the consensus 00:08:53.340 --> 00:08:57.600 rules. And this is a problem because verifying signatures... 00:08:57.600 --> 00:08:59.820 So hang on, you could make a... 00:09:03.210 --> 00:09:08.930 6,382 out of 18,723 multisig? 00:09:09.070 --> 00:09:12.470 As far as I know, yes. There may have been a limit on the size of the transaction 00:09:12.470 --> 00:09:13.890 itself, but that's it, yeah. 00:09:14.800 --> 00:09:15.560 That's pretty good. 00:09:15.860 --> 00:09:16.960 So that was pretty cool. 00:09:17.100 --> 00:09:18.320 What's the problem? This sounds great. 00:09:18.540 --> 00:09:22.260 Yeah, the problem is the way the script is evaluated, the way the blockchain 00:09:22.260 --> 00:09:25.640 basically checks the validity of the script. And roughly this works as follows. 00:09:25.820 --> 00:09:31.750 You take the pile of public keys. And then the person who spends it will have to 00:09:31.750 --> 00:09:35.670 provide one or a whole pile of signatures. Now they have to be in the correct 00:09:35.670 --> 00:09:39.230 sequence. So it's not a random order that would have been even worse, but they 00:09:39.230 --> 00:09:42.370 have to be in the right sequence, but there could be gaps, right? So in the 00:09:42.370 --> 00:09:45.830 simple example of one out of three, I'm providing one signature and there are 00:09:45.830 --> 00:09:51.290 three public keys. Now, what the script does is it will look at the 00:09:51.290 --> 00:09:56.160 signature and... It will look at the first key. It will see if the signature is 00:09:56.160 --> 00:09:59.920 correct for that first key. If not, it will look at the second key. It will check 00:09:59.920 --> 00:10:02.760 if the signature is correct for the second key. And if not, it will try the third 00:10:02.760 --> 00:10:07.550 key. And if you have two out of three, it's a little bit more efficient. So it 00:10:07.550 --> 00:10:11.990 will look at the first. If you have two signatures out of three, it will look at 00:10:11.990 --> 00:10:15.670 the first signature using the algorithm I just described. And then if it finds a 00:10:15.670 --> 00:10:19.490 match, it tosses that signature and that public key. And then it moves on to the 00:10:19.490 --> 00:10:22.670 next one. So they do have to be in the correct order because otherwise it won't 00:10:22.670 --> 00:10:27.000 find it. But it's still pretty slow because if you have a one out of a million 00:10:27.000 --> 00:10:33.080 multisig, then you're going to try a million public keys before you find it. 00:10:33.870 --> 00:10:37.510 Well, only if it's the very last one, right? You might get lucky. It might be the 00:10:37.510 --> 00:10:37.950 first one. 00:10:38.210 --> 00:10:40.810 Yeah, but if you're trying to attack Bitcoin, you make sure that Bitcoin does not 00:10:40.810 --> 00:10:41.250 get lucky. 00:10:41.690 --> 00:10:46.910 Right. And if it's the 6,852 out of 00:10:46.910 --> 00:10:52.850 18,731, I guess the math gets very complicated. But the bottom 00:10:52.850 --> 00:10:55.890 line is it will take your computer a long time to verify this. 00:10:56.510 --> 00:10:56.670 Yeah. 00:10:56.830 --> 00:11:00.950 It will just take a long time because it has to check for every key that's in 00:11:00.950 --> 00:11:05.250 there. Whether the signature matches and then go on to the next one one. 00:11:05.250 --> 00:11:08.810 Yeah, so there's a little bit of acceleration in there that it doesn't like you 00:11:08.810 --> 00:11:11.850 can't you can't I think you cannot provide them in any order that would be really 00:11:11.850 --> 00:11:15.830 Bad. yeah but still but it's still pretty bad yeah so it was bad enough that 00:11:15.830 --> 00:11:20.750 Satoshi decided very quickly in 2010 to in september 2010, 00:11:21.640 --> 00:11:26.860 to add a limit to say you can only have 20 as in 20 pub keys. 00:11:26.860 --> 00:11:31.360 okay so it can be a one out of 20 or 20 out of 20 according to that. 00:11:31.360 --> 00:11:31.980 Yes. 00:11:31.980 --> 00:11:33.260 I guess that was a soft fork then? 00:11:33.360 --> 00:11:36.320 Yes, it was that was one of the first soft forks 00:11:36.320 --> 00:11:41.980 and it was a so that was a consensus rule implemented by Satoshi in Bitcoin to 00:11:41.980 --> 00:11:43.240 limit the 00:11:44.640 --> 00:11:45.960 size of multisig 00:11:45.960 --> 00:11:51.440 Yeah, he did okay really two things but this was in version 0.3.13 for those who 00:11:51.440 --> 00:11:52.000 want to look it up. 00:11:52.000 --> 00:11:53.380 When was this did you mention this? 00:11:53.380 --> 00:11:57.320 September 2010. So it was released in October 2020. so around the time of the one 00:11:57.320 --> 00:12:01.360 megabyte limit too right? And this was introduced in his usual style so the 00:12:01.360 --> 00:12:05.300 commit so the change that was made which is called something like clean up 00:12:05.300 --> 00:12:10.700 various stuff and in it would be that critical change because if people saw what 00:12:10.700 --> 00:12:13.160 the change was they would try and attack Bitcoin using it 00:12:14.140 --> 00:12:18.420 Right. You say that's his usual way. That was Satoshi's usual way of 00:12:18.420 --> 00:12:21.560 implementing, of changing the Bitcoin protocol, essentially. 00:12:21.820 --> 00:12:24.820 He would basically say, well, from this block height, here are the new rules, and 00:12:24.820 --> 00:12:27.960 that would be in the code. But if you didn't check the code, you wouldn't know 00:12:27.960 --> 00:12:30.620 that the new rules came out there because he wouldn't announce it, or he might 00:12:30.620 --> 00:12:32.600 later announce it, or other people would figure it out later. 00:12:32.880 --> 00:12:37.860 Right. So he probably did this because he figured out that the unlimited multisig 00:12:37.860 --> 00:12:40.440 thing was a problem for the reason you just mentioned. 00:12:40.660 --> 00:12:40.820 Yep. 00:12:40.880 --> 00:12:43.970 But he never actually explained that. He just... hit it in the code somewhere. 00:12:44.290 --> 00:12:47.110 He may have. I didn't check if he did, but he usually didn't. 00:12:47.310 --> 00:12:47.390 Right. 00:12:47.510 --> 00:12:51.310 Or he sometimes didn't. So the other limit he also introduced is a per block 00:12:51.310 --> 00:12:55.270 limit. And the idea there would be that there's a limited number of these 00:12:55.270 --> 00:13:01.060 multisigs that you can have in a given block. This is called the ops limit. 00:13:01.060 --> 00:13:03.000 And that's still there, although it's changed a bit. 00:13:03.720 --> 00:13:07.240 Wait, so what's the limit, first of all, I guess? 00:13:07.400 --> 00:13:13.310 The limit was, at the time, you could have 1,000... multisig transactions 00:13:13.310 --> 00:13:17.510 in a single block, no matter how big they were. Because initially, you would get 00:13:17.510 --> 00:13:22.750 20 points, essentially, for each multisig transaction in a block. And the limit 00:13:22.750 --> 00:13:27.690 was 20,000 for the whole block. So if you had 1,000 multisig transactions, no 00:13:27.690 --> 00:13:32.010 matter how small they were, that was the max you were allowed to put in a block. 00:13:32.150 --> 00:13:36.910 And regular transactions counted as a score of 1. So a single-sig transaction 00:13:36.910 --> 00:13:40.310 would give you 1 point. So you could have 20,000 single-sig transactions in a 00:13:40.310 --> 00:13:44.150 block. or a thousand multisig transactions or some combination 00:13:44.150 --> 00:13:50.020 so what happens if there's a thousand multisig transactions in waiting in the 00:13:50.020 --> 00:13:53.920 mempool say and now you want to send me a multisig transaction you're just out of luck 00:13:53.920 --> 00:13:56.040 No, the mempool can have as many as you want 00:13:56.040 --> 00:13:58.240 Yeah, but it's not going to be included in the block. 00:13:58.240 --> 00:13:59.400 no it'll go into the next block 00:14:01.510 --> 00:14:04.430 So miners have to be careful when they create a block that they don't violate 00:14:04.430 --> 00:14:06.690 this rule, but as long as you do that correctly. 00:14:06.970 --> 00:14:12.450 So maybe this is getting into weeds, but would this work based on fee markets as well? 00:14:13.310 --> 00:14:14.970 No, this is one of the... 00:14:14.970 --> 00:14:19.130 Like which transaction gets priority, I mean, if there's 1,001. 00:14:19.370 --> 00:14:22.550 Well, so a rational miner would have to do some complicated math to figure out 00:14:22.550 --> 00:14:27.870 whether he'd want the multisigs in there or not. So at the time, there was no fee 00:14:27.870 --> 00:14:32.350 market, so that helped. And also, if you looked at the original mining code, so 00:14:32.350 --> 00:14:38.050 the standard mining code as it existed at the time was very conservative. I think 00:14:38.050 --> 00:14:41.210 it would only put in maybe 20 of them. 00:14:42.530 --> 00:14:46.170 like some some really small number oh because there were almost no multisig 00:14:46.170 --> 00:14:51.390 transactions anyway right of course any miner could do it differently but he was 00:14:51.390 --> 00:14:52.690 pretty much the only miner probably 00:14:52.690 --> 00:14:57.910 so yeah just to be clear because we're talking about this kind of in the past 00:14:57.910 --> 00:15:02.990 tense but does this limit still exist in Bitcoin I know we do other ways of doing 00:15:02.990 --> 00:15:06.810 multisig now, but does this technical limit still exist? 00:15:07.010 --> 00:15:10.790 Yes, but we'll get to that in P2SH. The limit is slightly more intelligent. 00:15:11.030 --> 00:15:11.450 Okay. 00:15:11.650 --> 00:15:17.440 But for this bare multisig, so multisig without P2SH, and for 00:15:17.440 --> 00:15:20.220 P2SH multisig, this limit exists. 00:15:20.740 --> 00:15:21.280 Today? 00:15:21.780 --> 00:15:23.360 Yes, but not for Taproot. 00:15:24.350 --> 00:15:27.840 Right. Interesting. I don't think I knew that. 00:15:28.320 --> 00:15:30.920 Yeah. So I don't know how that plays into the fee market. If there's too many 00:15:30.920 --> 00:15:35.030 multisig transactions. candidates yeah I guess then as a miner you'd have to do 00:15:35.030 --> 00:15:38.610 the math what what makes more sense to include the transaction with the higher 00:15:38.610 --> 00:15:42.230 fee but it has a multisig are you going to kick out some some other transaction 00:15:42.230 --> 00:15:45.410 or are you going to say well I'd rather have the single-sick transactions than 00:15:45.410 --> 00:15:49.650 the multisig transactions because you know how the fees work out because you get a limit 00:15:49.650 --> 00:15:53.890 okay so we're going to talk about other ways of doing multisig but my curiosity 00:15:53.890 --> 00:15:59.010 is triggered now so spoiler alert we're also going to talk about P2SH multisig 00:15:59.010 --> 00:16:04.490 SegWit multisig Taproot multisig and MuSig Which of these types of multisig are 00:16:04.490 --> 00:16:08.090 relevant in context of this limit? Is it only bare multisig or other? 00:16:08.090 --> 00:16:09.310 All of them except Taproot. 00:16:10.400 --> 00:16:14.440 Really? So SegWit multisig is also affected by this limit? 00:16:14.980 --> 00:16:15.420 Yes. 00:16:15.420 --> 00:16:16.240 From 2010. 00:16:16.400 --> 00:16:19.520 That's one of the reasons for the change in Taproot, because this limit is 00:16:19.520 --> 00:16:21.160 annoying for all sorts of reasons. 00:16:21.180 --> 00:16:24.200 Okay, I guess we'll get there. We're skipping ahead now, but this will... 00:16:24.200 --> 00:16:27.580 So there's also the standardness rules, right? So as far as I can tell, when he 00:16:27.580 --> 00:16:32.220 introduced this limit, the standardness rule was two out of two. So you could 00:16:32.220 --> 00:16:37.260 have a one out of two or two out of two multisig. And then several years later, 00:16:37.400 --> 00:16:42.360 or actually one year later in December 2011, I think Gavin Andresen raised the 00:16:42.360 --> 00:16:46.520 limit to three. So you could have a two out of three or a three out of three. 00:16:47.000 --> 00:16:47.480 Right. 00:16:47.720 --> 00:16:51.680 And we know that because that limit led to the OP_RETURN wars that we did another 00:16:51.680 --> 00:16:52.240 episode on. 00:16:53.510 --> 00:16:59.000 Yeah. Okay. So the limit was brought back. The consensus rule was made 20 00:16:59.000 --> 00:17:04.460 by Satoshi in 2010. And then the standardness 00:17:04.490 --> 00:17:07.170 rule was made two. 00:17:07.530 --> 00:17:07.870 Yeah. 00:17:08.190 --> 00:17:13.980 Okay. And three later by Gavin Andresen. Okay. So that's raw multisig, 00:17:15.120 --> 00:17:15.340 right? 00:17:15.680 --> 00:17:16.000 Yeah. 00:17:16.000 --> 00:17:18.180 We've now explained what raw multisig is. 00:17:18.320 --> 00:17:21.180 Yes. Or bare multisig, I think is the correct term, but it doesn't really matter. 00:17:21.920 --> 00:17:22.100 Okay. 00:17:23.560 --> 00:17:27.820 Then, and this is what we discussed last week as well. Regardless, we'll go over 00:17:27.820 --> 00:17:33.310 it. Then the next type of multisig in Bitcoin was pay-to-script hash, 00:17:34.960 --> 00:17:40.960 P2SH, multisig. So how did it evolve from bare multisig? 00:17:41.540 --> 00:17:45.240 Yeah, so the difference is, again, the recipient now pays for the fees because 00:17:45.240 --> 00:17:50.620 the recipient provides a hash of the script. And inside that script can be some 00:17:50.620 --> 00:17:54.820 sort of multisig construction. But the sender doesn't have to care. The hash of 00:17:54.820 --> 00:17:57.840 the script is always the same size. So when you pay a detection fee for the 00:17:57.840 --> 00:18:02.160 outputs, that's always going to be the same. It also makes addresses easy. Well, 00:18:02.200 --> 00:18:04.500 that's what we explained in the last episode. It also gives you a little bit 00:18:04.500 --> 00:18:07.700 better privacy because you can't see what the script is until you try to spend 00:18:07.700 --> 00:18:13.970 it. Now, there is a new limit. which is 15 at the consensus level. 00:18:15.470 --> 00:18:19.270 I didn't check what the standardness was. Maybe the standardness was also 15. 00:18:19.430 --> 00:18:21.510 Wait, so the limit was decreased? 00:18:22.050 --> 00:18:27.210 Well, the consensus limit was decreased from 20 to 15, and the standardness 00:18:27.210 --> 00:18:31.510 limit, I think, was increased either immediately or later on to 15. 00:18:32.010 --> 00:18:36.330 Right, so the consensus limit and the standardness limit were made the same at 00:18:36.330 --> 00:18:36.770 that point. 00:18:36.870 --> 00:18:41.270 Yeah, and the consensus limit is accidental because there is a limit of 20 that's 00:18:41.270 --> 00:18:45.430 still there. but you never reach that limit because the script can only be 512 00:18:45.430 --> 00:18:51.370 bytes in P2SH. And if you divide 512 bytes by the number of bytes that one public 00:18:51.370 --> 00:18:53.390 key requires, you end up with 15. 00:18:54.850 --> 00:18:58.650 Okay, this is getting complicated, but I do think I'm following you. 00:18:58.830 --> 00:19:02.230 Yeah, basically it means you cannot spend a multisig with more than 15 keys in it. 00:19:02.760 --> 00:19:08.680 Yeah, but not because that's a specific rule concerning multisig, 00:19:08.800 --> 00:19:12.220 but a more general rule concerning script. 00:19:12.420 --> 00:19:12.740 Yes. 00:19:13.490 --> 00:19:19.090 And that just happens to, the math just happens to end up at 15 in that case. 00:19:19.310 --> 00:19:24.130 Yeah, because in order to spend a multisig transaction, you, the recipient, have 00:19:24.130 --> 00:19:28.570 to specify which keys are involved. All of them, not just the ones you're using. 00:19:29.390 --> 00:19:30.830 And so that's 15. 00:19:31.850 --> 00:19:37.460 So if… Because at first it's sent to a hash, right? So then the script… Yeah. 00:19:37.050 --> 00:19:42.870 and then you reveal the actual script. So the script contains all the 00:19:42.870 --> 00:19:43.410 public keys. 00:19:43.810 --> 00:19:49.650 So if there's a 16 out of 16 multisig, let's say, it just 00:19:49.650 --> 00:19:50.750 means it can't be spent? 00:19:50.930 --> 00:19:54.470 Yep, you can't reveal it. If you try to reveal the script, it's invalid because 00:19:54.470 --> 00:19:54.970 it's too long. 00:19:57.010 --> 00:20:01.960 Wasn't this an incompatibility, like a backwards? compatibility issue at the time? 00:20:01.960 --> 00:20:06.000 yeah the limit of 512 is a backwards compatibility issue because the I think the 00:20:06.000 --> 00:20:09.880 size of stuff that can be on the stack so the size of each element on the stack 00:20:09.880 --> 00:20:15.870 is 512 bytes and the old nodes what they would see if you're using P2SH they 00:20:15.870 --> 00:20:19.610 would see something on the stack and they would hash it so that something on the 00:20:19.610 --> 00:20:23.830 stack has to be 512 bytes now the new nodes don't interpret it that way anymore 00:20:23.830 --> 00:20:27.550 but you have to be backwards compatible hence the 512 limit yeah so if you want 00:20:27.550 --> 00:20:29.090 to lose your coins that's one way to do it. 00:20:31.760 --> 00:20:36.620 right okay anything else we discussed this last week so we probably don't want to 00:20:36.620 --> 00:20:42.180 get into too much in rehashing mode but what else is new with 00:20:42.180 --> 00:20:44.520 P2SH is there anything else we need to know about that? 00:20:44.520 --> 00:20:48.260 yeah so one other thing is that like we said this sigops limit that we talked 00:20:48.260 --> 00:20:52.560 about It used to be that you just get 20 points for any multisig, no matter how 00:20:52.560 --> 00:20:56.180 big it was. So that's kind of annoying because if you're making a small multisig, 00:20:56.340 --> 00:21:01.060 you're not paying, but you're using up a limit in the block that's quite high. 00:21:01.340 --> 00:21:06.320 And now it was changed to the actual number of public keys. So if you do a two 00:21:06.320 --> 00:21:09.260 out of three multisig, you get three sigops. 00:21:11.460 --> 00:21:13.540 Right. Again, this sounds to me... 00:21:13.540 --> 00:21:16.880 Or two. I forgot if the limit is the number of public keys or the number of signatures. 00:21:18.520 --> 00:21:22.800 I'm just wondering out loud here, but when this was changed at the time, again, 00:21:23.020 --> 00:21:28.450 wouldn't that lead to backwards incompatibility issues where different nodes are 00:21:28.450 --> 00:21:29.650 making different calculations? 00:21:29.930 --> 00:21:34.330 No, because this new limit, this new way of counting only applies to the P2SH 00:21:34.330 --> 00:21:39.130 scripts. So the multisig that you were using bare script for... they would still 00:21:39.130 --> 00:21:44.330 count as 20 but if you were using P2SH it's it's essentially a discount for P2SH 00:21:44.330 --> 00:21:50.270 not so much a discount in fees but a discount in how many of 00:21:50.270 --> 00:21:53.960 these things you can put in a single block again it didn't matter in practice, 00:21:53.960 --> 00:21:55.880 because blocks were not anywhere near full. 00:21:56.430 --> 00:22:01.690 yeah no I I get that I think that that makes sense okay so 00:22:03.270 --> 00:22:07.250 But other than that, this worked exactly the same. So as soon as you've unwrapped 00:22:07.250 --> 00:22:11.310 the P2SH thing, you have an OP_CHECKMULTISIG and it works exactly the same way as 00:22:11.310 --> 00:22:15.290 it used in the old consensus code. It is the same code that is checking it, the 00:22:15.290 --> 00:22:16.710 same lines of code that are checking it. 00:22:16.770 --> 00:22:17.470 Yeah, the same opcode. 00:22:17.790 --> 00:22:22.370 Yeah, it's the same piece of C++ code that is just used in both situations. 00:22:23.200 --> 00:22:28.390 Right. Okay, so that was bare multisig and that was... 00:22:28.660 --> 00:22:34.500 P2SH as well now we move to SegWit so SegWit also 00:22:34.500 --> 00:22:37.120 changed things about how multisig works 00:22:37.120 --> 00:22:41.600 yeah well one thing that SegWit changes is SegWit also had a its own P2SH 00:22:41.600 --> 00:22:46.560 essentially wrapped P2SH or pay to SegWit script hash 00:22:46.560 --> 00:22:52.550 and this hash could be the script could be as big as you 00:22:52.550 --> 00:22:56.660 want I think there's no limit or at least the limit is large enough for this 00:22:56.660 --> 00:23:01.220 purpose, which means now the limit is actually 20. So the original limit of 20 00:23:01.220 --> 00:23:04.520 that's in the consensus code is now actually relevant for SegWit. 00:23:07.170 --> 00:23:10.670 So it wasn't that SegWit decided to make it 20. It's just that they removed the 00:23:10.670 --> 00:23:12.490 512 limit on the script size. 00:23:12.730 --> 00:23:18.130 Right. Yeah, that's what we just... discussed so there wasn't an actual 00:23:18.130 --> 00:23:23.510 explicit limit on multisig but there was a practical limit because there was a 00:23:23.510 --> 00:23:28.450 more general script limit and this more general script limit was removed in the 00:23:28.450 --> 00:23:33.700 case of SegWit, and therefore we went back to the original 00:23:33.700 --> 00:23:38.920 Satoshi imposed multisig limit consensus limit is that right 00:23:38.920 --> 00:23:41.220 the super sneaky soft fork that he introduced Yep. 00:23:41.680 --> 00:23:45.640 Okay, right. So then because of SegWit, we went back to 20. 00:23:46.040 --> 00:23:49.880 Yes, and also the limit per block, so that we talked about the sigops limit per 00:23:49.880 --> 00:23:55.360 block. SegWit also multiplied that by four. So if you wanted to use multisig 00:23:55.360 --> 00:23:59.840 and you did it inside of SegWit, it would be cheaper. You would be able to put 00:23:59.840 --> 00:24:00.660 more of them in a block. 00:24:02.390 --> 00:24:07.270 okay where now now I'm getting lost again so where is this limit? does this 00:24:07.270 --> 00:24:08.390 question even make sense? 00:24:08.390 --> 00:24:12.230 yeah the sigops limit is per block so there is a counter that says the number of 00:24:12.230 --> 00:24:16.890 sigops and every time it sees a normal signature it says okay one sees another 00:24:16.890 --> 00:24:17.450 normal signature 00:24:17.450 --> 00:24:19.130 but it's all in the witness right? 00:24:19.840 --> 00:24:23.420 It doesn't matter where the signature is. But this counter is different for where 00:24:23.420 --> 00:24:28.220 it is. So before SegWit, there was one counter, and if it saw a single sig, it 00:24:28.220 --> 00:24:31.200 would give you one point. If it saw a multisig, it would give you n points, 00:24:31.300 --> 00:24:34.980 depending on what n was. Except if it was a raw multisig, then it would give you 00:24:34.980 --> 00:24:40.120 20 points. Now the new rule is that all of these examples from before would get 00:24:40.120 --> 00:24:44.160 four points. So that was multiplied by four. But if it was in SegWit, it would 00:24:44.160 --> 00:24:45.060 only get one point. 00:24:45.230 --> 00:24:47.670 Yeah, that's the weight limit, essentially, what we're talking about, right? 00:24:47.770 --> 00:24:51.940 It's the same trick as with the weight limit, but it's not the same thing. It's a 00:24:51.940 --> 00:24:55.080 different counter, but it gets the same discount as everything else at SegWit. 00:24:55.220 --> 00:25:00.760 I see. Okay. So once again, we're talking about a 00:25:00.760 --> 00:25:03.020 specific limit on... 00:25:03.210 --> 00:25:05.150 Well, not SegWit. 00:25:05.410 --> 00:25:06.250 There's a point system. 00:25:06.680 --> 00:25:08.760 Yeah. The point system was... 00:25:08.760 --> 00:25:12.520 The thing is, we're not talking about the block size limit itself. We're talking 00:25:12.520 --> 00:25:16.880 about another type of limit for the types of transactions that can be put in 00:25:16.880 --> 00:25:22.480 blocks and that different transactions can score different points. 00:25:22.680 --> 00:25:25.940 Yeah. And for some reason, that was also multiplied by four. I don't know what 00:25:25.940 --> 00:25:29.940 the reason is because as far as I know, the problems with this inefficient 00:25:29.940 --> 00:25:31.240 evaluation is still there. 00:25:31.520 --> 00:25:36.950 Yeah. Well, my mind is going to... why wouldn't that be backwards 00:25:36.950 --> 00:25:41.430 incompatible? But I guess the reason is because it is in the witness, so you can 00:25:41.430 --> 00:25:44.690 just do whatever at that point. It doesn't have to be backwards compatible 00:25:44.690 --> 00:25:46.690 because all the nodes don't see the witness, right? 00:25:46.930 --> 00:25:47.690