WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:00.530 --> 00:00:02.890 Before the show, a quick word from our sponsor. 00:00:11.760 --> 00:00:14.240 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:14.720 --> 00:00:14.960 Hello. 00:00:15.760 --> 00:00:18.020 Sjors, we're going to talk about a classic today. 00:00:18.340 --> 00:00:19.980 Yeah, we're going to party like it's 2015. 00:00:21.750 --> 00:00:22.270 SegWit. 00:00:22.530 --> 00:00:23.230 That's right. 00:00:23.550 --> 00:00:28.390 Segregated Witness, which was the previous soft fork. Well, it was the last 00:00:28.390 --> 00:00:32.010 soft fork. We're working towards the Taproot soft fork now. 00:00:32.250 --> 00:00:33.610 It's the last soft fork we know of. 00:00:34.090 --> 00:00:38.470 Yes, I guess so. It activated in 2017. 00:00:39.590 --> 00:00:43.390 It was developed in... It started being developed in 2015. 00:00:43.470 --> 00:00:45.550 I think it was late 2015, yeah. 00:00:46.860 --> 00:00:50.740 the final idea came about to turn it into a soft fork. 00:00:50.960 --> 00:00:54.600 Yeah, and it's probably, would you say, it's probably the biggest protocol 00:00:54.600 --> 00:00:56.840 upgrade Bitcoin has seen so far, right? 00:00:57.300 --> 00:01:02.060 Well, it's the biggest protocol upgrade we've seen since the days of completely 00:01:02.060 --> 00:01:05.120 reckless deployments of upgrades, right? 00:01:05.340 --> 00:01:08.920 Wouldn't you say it's almost the biggest code change, for example? 00:01:09.440 --> 00:01:14.460 Yeah, I think so. It's a bigger change than P2SH, but I don't know what was done 00:01:14.460 --> 00:01:17.980 in the very early Satoshi days, you know, when hundreds of opcodes were turned 00:01:17.980 --> 00:01:19.200 off and all that stuff. 00:01:19.920 --> 00:01:22.860 So where do we start? Do we start... 00:01:22.860 --> 00:01:24.920 We could start with what the problem was. 00:01:25.220 --> 00:01:28.240 Okay, what was the problem? Why do we need SegWit, Sjors? 00:01:28.400 --> 00:01:30.120 Yeah, why do witnesses need to be segregated? 00:01:30.400 --> 00:01:30.760 Exactly. 00:01:31.180 --> 00:01:36.150 So the problem was transaction malleability. And transaction malleability means 00:01:36.150 --> 00:01:41.960 that… If I'm sending you some coins and you're sending them to 00:01:41.960 --> 00:01:47.670 Ruben, who's not here, then that transaction that you're 00:01:47.670 --> 00:01:51.950 sending refers to the transaction that I just sent. And the problem there, and 00:01:51.950 --> 00:01:57.910 that's fine normally, but the problem is that somebody could take 00:01:57.910 --> 00:02:02.740 our transaction and manipulate it. It could take my transaction and manipulate it 00:02:02.740 --> 00:02:06.320 and then your transaction would no longer refer to my transaction but would refer 00:02:06.320 --> 00:02:06.920 to a void. 00:02:07.280 --> 00:02:11.340 Yeah, and to be more specific, I think, what the part of the transaction that's 00:02:11.340 --> 00:02:16.200 being manipulated is actually the signature. So every transaction is signed with 00:02:16.200 --> 00:02:20.580 a cryptographic signature and the signature I don't understand the details, but I 00:02:20.580 --> 00:02:24.640 know that the signature can be tweaked somehow in a way that it looks different 00:02:24.640 --> 00:02:25.860 but it's still valid. 00:02:26.300 --> 00:02:31.070 Yeah and there were lots of ways to do that. So one of the ways that was fixed 00:02:31.070 --> 00:02:36.590 without SegWit is that you could, I think, just multiply the signature with minus 00:02:36.590 --> 00:02:41.310 one or something, just put a minus in front of it, and it would still be valid. 00:02:41.510 --> 00:02:45.190 And so anybody could just put that minus in front of it. So you would broadcast a 00:02:45.190 --> 00:02:48.290 transaction and it would go from one node to the other. Somebody else could see 00:02:48.290 --> 00:02:51.950 that transaction and they could say, well, I'm just going to flip this bit and 00:02:51.950 --> 00:02:57.000 send it onwards and then we'll see which one wins. And this is just for… simple 00:02:57.000 --> 00:03:00.240 signatures but I think there were other… if you have more complicated scripts, 00:03:00.240 --> 00:03:03.820 there are also ways that somebody can mess with that script. 00:03:03.820 --> 00:03:07.820 Yeah, so someone can mess with it in flight. Basically, you send the transaction 00:03:07.820 --> 00:03:12.220 to the network, and then it's forwarded from peer to peer and until it reaches 00:03:12.220 --> 00:03:16.300 miner and it's included in a block, but every peer on the network… but can 00:03:16.300 --> 00:03:20.080 basically take the transaction, tweak it a little bit, and forward it, or the 00:03:20.080 --> 00:03:20.940 miner can do that. 00:03:20.940 --> 00:03:24.300 Yeah, I guess even the person making it can do it. 00:03:24.300 --> 00:03:24.860 Sure. 00:03:25.260 --> 00:03:28.420 Yeah, or the miner can do it. So you may ask yourself, why is this a problem, 00:03:28.500 --> 00:03:32.260 right? Because I sent you some coins and you sent them to Ruben. Okay, I ruined 00:03:32.260 --> 00:03:35.660 your transaction, so you just sent it again. So that's not a big deal. 00:03:35.660 --> 00:03:39.640 You didn't really ruin the transaction, you just tweaked it a bit, but it's still valid. 00:03:39.700 --> 00:03:44.060 Well, I ruined your transaction. So I sent coins to you and you sent coins to 00:03:44.060 --> 00:03:48.300 Ruben, but that last transaction no longer points to an existing transaction 00:03:48.300 --> 00:03:50.500 because somebody messed with my transaction. 00:03:50.840 --> 00:03:53.340 Yeah, it's the second transaction that's getting in trouble. 00:03:53.620 --> 00:03:57.180 Yeah. And this is not a problem in the scenario we just described, right? Because 00:03:57.180 --> 00:04:02.950 you can just make a new one. Except, what about if... You're not 00:04:02.950 --> 00:04:08.530 you, but what if I sent a transaction to a super secure vault in the Arctic, like 00:04:08.530 --> 00:04:13.230 thousands of meters underground? And then I went to the Arctic and I created a 00:04:13.230 --> 00:04:17.420 redeem transaction back to my hot wallet, but I didn't broadcast it. I just… I 00:04:17.420 --> 00:04:18.040 just signed it. 00:04:18.690 --> 00:04:24.070 Why are you making such a complicated example with vaults and arctics? 00:04:24.290 --> 00:04:27.550 Well, this one isn't that complicated. I just, you know, I went to my vault. I 00:04:27.550 --> 00:04:33.520 created the transaction out of my vault. And then… I basically buried the 00:04:33.520 --> 00:04:38.390 vault in like… like 100 meters of rock. So it's very difficult for me to go back 00:04:38.390 --> 00:04:41.710 to the vault and make a new transaction. And then I broadcast my original 00:04:41.710 --> 00:04:44.400 transaction that sends the money to the vault and somebody messes with it. Now I 00:04:44.400 --> 00:04:47.940 have to go back to Antarctica and there's you know there's COVID and it's very 00:04:47.940 --> 00:04:52.770 complicated. So that's a terribly difficult example. Another example would be Lightning. 00:04:53.110 --> 00:04:54.330 Yeah, that's the more obvious one. 00:04:55.610 --> 00:04:59.110 Yeah, so with Lightning, what happens, and we've explained Lightning in earlier 00:04:59.110 --> 00:05:03.890 episodes, but the idea is you sent money, two people sent money to a shared 00:05:03.890 --> 00:05:07.070 address, and then the only way to get money out of that address is with 00:05:07.070 --> 00:05:12.090 transactions that you've both signed before you sent money into that address. So 00:05:12.090 --> 00:05:16.450 you don't want somebody messing with the transaction that goes into the address. 00:05:16.920 --> 00:05:20.700 Because then you can't spend from it anymore. Or you can, but you'd both have to 00:05:20.700 --> 00:05:24.320 sign it again. And so one party could kind of cheat the other party out of the coins. 00:05:24.580 --> 00:05:28.740 Yeah, the point with Lightning is that you're building unconfirmed transactions 00:05:28.740 --> 00:05:33.600 on each other. So if… then… if one of the underlying transactions is tweaked then 00:05:33.600 --> 00:05:37.180 the transactions that follow up on that one aren't valid anymore. 00:05:37.660 --> 00:05:40.760 Yeah, and people spend lots of time trying to find ways around that problem, 00:05:40.880 --> 00:05:45.870 because people were thinking about Lightning-like solutions quite a while, and it 00:05:45.870 --> 00:05:46.950 was just really hard to solve. 00:05:47.230 --> 00:05:52.810 Yeah, so to be clear, the concrete attack in this Lightning example is that 00:05:52.810 --> 00:05:58.430 one of the parties would tweak the transaction they shared between them, 00:05:58.810 --> 00:06:02.550 send this tweaked transaction to the network, and then I guess the other party 00:06:02.550 --> 00:06:06.190 probably wouldn't even recognize that transaction, or even if he did, he couldn't 00:06:06.190 --> 00:06:09.970 use his own transaction to get his funds back. Am I saying that right? 00:06:10.090 --> 00:06:14.210 Yeah, all the transactions that get your funds back are no longer valid. So this 00:06:14.210 --> 00:06:16.430 could be a problem, you know, in all the cheating scenarios. 00:06:16.670 --> 00:06:22.490 Yeah, exactly. There's also another well-known example, which was the Mt. 00:06:22.590 --> 00:06:28.500 Gox case. And that was a mistake on the part of Mt. Gox as well. If we assume 00:06:28.500 --> 00:06:33.240 that the story we've been told about how the hack happened is really true, but 00:06:33.240 --> 00:06:34.160 the story was... 00:06:34.160 --> 00:06:35.940 The hack or you mean one of the many hacks? 00:06:36.120 --> 00:06:40.120 The big one, basically. They claimed that the big one was due to transaction 00:06:40.120 --> 00:06:45.720 malleability. And the story was that they were basically doing their 00:06:45.720 --> 00:06:51.400 internal accounting based on transaction IDs. So a 00:06:51.400 --> 00:06:57.220 customer would withdraw funds, use malleability to change the 00:06:57.220 --> 00:07:00.840 withdrawal transaction a little bit, still get the money because the transaction 00:07:00.840 --> 00:07:06.700 is still valid, but then claim, guys, I made a withdrawal, but I 00:07:06.700 --> 00:07:10.960 never received the money. Mt. Gox would take the transaction ID, look if it was 00:07:10.960 --> 00:07:14.920 in the blockchain, so that there's no transaction ID like that in the blockchain. 00:07:15.400 --> 00:07:18.140 Our customer must be right. And then resend the coins. 00:07:18.520 --> 00:07:21.680 Yeah, but there are so many other things you have to do wrong for that particular 00:07:21.680 --> 00:07:22.780 thing to happen. 00:07:23.080 --> 00:07:23.480 Yeah. 00:07:23.440 --> 00:07:25.780 But anyway, let's… let's blame it on malleability. 00:07:26.500 --> 00:07:30.260 I'm just giving an example of something that could go wrong because of 00:07:30.260 --> 00:07:34.860 malleability if, yeah, in this case, you make other mistakes as well. So that was 00:07:34.860 --> 00:07:35.440 malleability. 00:07:35.760 --> 00:07:36.020 Yeah. 00:07:36.220 --> 00:07:37.420 So that's what we want to solve, right? 00:07:37.360 --> 00:07:41.880 Yeah, and there have been you know partial solutions to this already because it's 00:07:41.880 --> 00:07:46.040 it's a much bigger problem than just the signature I think but in either way, it 00:07:46.040 --> 00:07:50.460 turns out that it seems like a whack-a-mole game that's just really hard to 00:07:50.460 --> 00:07:55.740 solve. And the fundamental problem there seems to be that because you're pointing 00:07:55.740 --> 00:07:59.980 to something that includes a signature, it just gets too complicated. One thing 00:07:59.980 --> 00:08:05.520 SegWit does is it no longer refers to the signature because it refers to, 00:08:05.900 --> 00:08:11.480 well, the signature is put somewhere else in a transaction, in some sort of extra data. 00:08:11.920 --> 00:08:16.560 To make this very clear, in case some of our listeners aren't keeping up, the 00:08:16.560 --> 00:08:20.820 thing is a transaction consists of all of the transaction data plus the 00:08:20.820 --> 00:08:26.180 signature. Formally or usually, or still the case in some transactions, the 00:08:26.180 --> 00:08:31.000 transaction data and the signature is hashed together. This gives you a string of 00:08:31.000 --> 00:08:36.680 numbers and that's the transaction ID. Because the signature can be tweaked, that 00:08:36.680 --> 00:08:41.840 means the hash, meaning the transaction ID, can also be tweaked. 00:08:42.060 --> 00:08:46.480 And you end up with basically the same transaction with a different transaction 00:08:46.480 --> 00:08:51.350 ID. And that causes all the problems we just discussed. So that's the problem we 00:08:51.350 --> 00:08:56.610 needed to solve. Somehow we need to make sure that a transaction would always 00:08:56.610 --> 00:08:58.370 result in the same transaction ID. 00:08:58.240 --> 00:09:03.920 Yeah, so the solution there is to put the hash… sorry, put the signature in a 00:09:03.920 --> 00:09:08.930 separate place inside the transaction that, as far as old nodes are concerned, 00:09:09.110 --> 00:09:14.670 doesn't even exist. And you still refer back to other transactions by the 00:09:14.670 --> 00:09:19.580 original data. So basically the original part of the transaction, that still 00:09:19.580 --> 00:09:22.960 creates the hash. And the signature is this new data, and you do not use it to 00:09:22.960 --> 00:09:23.520 create a hash. 00:09:24.110 --> 00:09:29.250 Right, so the signature ID can't be tweaked anymore because the signature isn't 00:09:29.250 --> 00:09:29.950 in there anymore. 00:09:30.110 --> 00:09:32.630 Right, so you can still tweak the signature if you wanted to, although there's 00:09:32.630 --> 00:09:36.330 some limitations on that too. But if you tweak the signature, that's not part of 00:09:36.330 --> 00:09:42.070 the hash. And this is nice, right? So that's one thing it does, SegWit. 00:09:42.230 --> 00:09:46.190 And the other thing it does is it just, because this data goes into a place that 00:09:46.190 --> 00:09:51.630 old nodes don't care about, well, suddenly you can bypass the one megabyte block 00:09:51.630 --> 00:09:56.190 size limit without a hard fork. Because old nodes will see a block with exactly 00:09:56.190 --> 00:09:59.670 one megabyte in it, but new nodes will see more… more megabytes. 00:10:00.600 --> 00:10:06.520 Yeah, blocks have a one megabyte limit. And that was… that used to be 00:10:06.520 --> 00:10:11.980 transaction data plus all the signatures, plus a little bit of metadata. And now 00:10:11.980 --> 00:10:16.880 it's basically mostly the signature data and not the signatures. And that's where 00:10:16.880 --> 00:10:20.520 the block size increase comes from. The signatures is sort of the increase. 00:10:20.940 --> 00:10:26.240 Yep, exactly. And that's theoretically up to four megabyte, but in practice it's 00:10:26.240 --> 00:10:30.560 more like two and a half, I guess, the total size that you get for blocks. 00:10:31.520 --> 00:10:37.270 Yeah. Why is that? There is some new calculation for how 00:10:37.270 --> 00:10:39.950 data is counted when it comes to the signature. 00:10:40.690 --> 00:10:46.490 Well, yeah. So I think what happens is you take the old data and you multiply 00:10:46.490 --> 00:10:52.130 it by three or something, and then you take the new data and you add it up. So 00:10:52.130 --> 00:10:56.390 the signature is kind of discounted in a way. And that's… that's kind of an 00:10:56.390 --> 00:10:59.310 arbitrary number but at least it creates an incentive to use SegWit. 00:10:59.720 --> 00:11:04.680 Right. And that's also why it's a bit more flexible now, the block size limit. If 00:11:04.680 --> 00:11:09.690 there are many... Transactions with many signatures for example multi-sig 00:11:09.690 --> 00:11:14.510 transactions then the size of the blocks could be a little bit bigger because of 00:11:14.510 --> 00:11:15.990 how it's all calculated? 00:11:15.990 --> 00:11:19.410 Right, because with the usual old-fashioned transactions there is not much going 00:11:19.410 --> 00:11:23.310 on in terms of signatures you know, there just aren't that many signatures but 00:11:23.310 --> 00:11:27.170 you could conceive of much more complicated transactions, that have much longer 00:11:27.170 --> 00:11:32.210 signatures like in a multi-sig situation, and those are nicely discounted in 00:11:32.210 --> 00:11:32.830 SegWit, yeah. 00:11:32.830 --> 00:11:38.710 Right. So how is it possible that SegWit could be deployed as a soft fork? 00:11:40.200 --> 00:11:41.300 Okay, yeah. 00:11:41.480 --> 00:11:46.920 Which means backwards compatible upgrade. So old nodes still recognize 00:11:46.920 --> 00:11:51.000 the SegWit chain as long as it has majority hash power at least. 00:11:51.300 --> 00:11:57.230 Yeah, and they do this because this new data that we've added is not... Like 00:11:57.230 --> 00:12:01.670 it's not communicated to all nodes. So every transaction has a little piece of 00:12:01.670 --> 00:12:05.790 witness that's not communicated to all nodes. And every block has a part that is 00:12:05.790 --> 00:12:10.190 the witness that's not communicated to all nodes. So basically new nodes... 00:12:10.190 --> 00:12:11.410 First of all, where is this part? 00:12:12.090 --> 00:12:13.770 I think it's at the end of the block. 00:12:15.270 --> 00:12:17.610 It's in the coinbase transaction, right? 00:12:18.350 --> 00:12:22.290 So I think it's appended at the end of the block, but it's also referred to in 00:12:22.290 --> 00:12:25.750 the coinbase transaction. Because what you do want to do is you want to make sure 00:12:25.750 --> 00:12:31.600 that the block hash just refers to the things that are in the block. But it 00:12:31.600 --> 00:12:34.280 only refers to the things that are in a block as far as legacy nodes are 00:12:34.280 --> 00:12:37.940 concerned. So… but you don't want to tell the legacy nodes about the SegWit 00:12:37.940 --> 00:12:43.080 stuff. So what happens is there is a OP_RETURN statement in the coinbase which 00:12:43.080 --> 00:12:44.820 refers to a hash of all the witness stuff. 00:12:45.600 --> 00:12:49.220 Yeah, the Coinbase, in case listeners don't know this, isn't just the company. 00:12:49.220 --> 00:12:54.660 It's also the transaction that pays the miner his rewards. So basically the first 00:12:54.660 --> 00:12:56.260 transaction in any block. 00:12:56.680 --> 00:13:00.440 Yeah, and the transaction can just spend the money however it wants, but it has 00:13:00.440 --> 00:13:04.620 to contain at least one output with OP_RETURN in it. And that OP_RETURN must 00:13:04.620 --> 00:13:09.720 refer to the witness blocks. So all nodes just see an OP_RETURN statement and 00:13:09.720 --> 00:13:10.280 they don't care. 00:13:10.580 --> 00:13:12.380 And OP_RETURN is a little bit of text. 00:13:12.750 --> 00:13:17.810 Yeah, OP_RETURN basically means, okay, you're done verifying, ignore this, but it 00:13:17.810 --> 00:13:19.710 can be followed by text, which is then ignored. 00:13:19.870 --> 00:13:20.110 Right. 00:13:20.250 --> 00:13:22.630 Except by new nodes, which will actually check this. 00:13:23.010 --> 00:13:23.190 Right. 00:13:23.710 --> 00:13:28.630 So this allows the nodes to communicate blocks and transactions to new nodes and 00:13:28.630 --> 00:13:32.910 to old nodes, and they all agree on what's there. And the other thing, the other 00:13:32.910 --> 00:13:36.130 reason why this can be in soft fork, and that's more important for the new nodes, 00:13:36.330 --> 00:13:41.720 is… Well, you're spending, where are you sending the coins to when you're using 00:13:41.720 --> 00:13:46.880 SegWit? So you're using a special address type now. And this address type, or 00:13:46.880 --> 00:13:51.580 like on the blockchain, what you have is a scriptPubKey. That is what an output 00:13:51.580 --> 00:13:56.410 says. So an output of a transaction tells you how to spend the new transaction. 00:13:56.630 --> 00:14:01.250 It puts a constraint on it. And so this scriptPubKey with SegWit starts with a 00:14:01.250 --> 00:14:05.830 zero, or at least does now, but with Taproot, it'll start with a one. And then 00:14:05.830 --> 00:14:10.390 it's followed by the hash of a public key or the hash of a script. 00:14:11.520 --> 00:14:16.460 And new nodes know what to do with this. They see this version zero. They know, 00:14:16.560 --> 00:14:21.870 okay, this is SegWit the way we know it. And they see a public key hash, and they 00:14:21.870 --> 00:14:25.310 know, okay, whoever wants to spend this needs to actually provide the public key 00:14:25.310 --> 00:14:30.280 and a signature. But old nodes, what they see is, okay, there is this condition, 00:14:30.620 --> 00:14:35.720 which is put zero on the stack and put this random garbage on the stack that I 00:14:35.720 --> 00:14:39.960 don't know what it is. And the end result is there's something on my stack and 00:14:39.960 --> 00:14:45.710 it's not zero, and I did not fail. And so, okay, whatever, this is fine, you can 00:14:45.710 --> 00:14:50.680 spend this. So old nodes think that anybody can spend that coin, but new nodes 00:14:50.680 --> 00:14:52.840 know exactly who can spend it and who can not spend it. 00:14:52.840 --> 00:14:55.980 Yeah, it's actually [unclear] anyone can spend out… 00:14:55.980 --> 00:14:56.500 Yes. 00:14:56.500 --> 00:15:01.540 So in a hypothetical situation, where there would only be all the nodes on the 00:15:01.540 --> 00:15:05.140 network, then it would also literally mean that the coins in these addresses 00:15:05.140 --> 00:15:06.280 could be spent by anyone. 00:15:06.280 --> 00:15:09.500 Yeah, this is why the activation of Taproot was of course, you know, always 00:15:09.500 --> 00:15:13.500 exciting because yes the miners signaled, but okay, what happens? 00:15:13.500 --> 00:15:17.440 Yeah, we discussed that in the last episode, of… I think or the one before that. 00:15:17.930 --> 00:15:21.770 Well, in general, we've talked about what can go wrong with soft fork activation, 00:15:21.970 --> 00:15:26.750 and this would be one of it. And so, well, it didn't go wrong. So that's good. 00:15:27.230 --> 00:15:31.370 Yeah, so the reason it didn't go wrong is because if there's a mix of all the new 00:15:31.370 --> 00:15:36.650 nodes on the network, but most miners enforce the new rules, then most miners 00:15:36.650 --> 00:15:42.060 will ensure that these coins in the Anyone Can Spend outputs from the perspective 00:15:42.060 --> 00:15:46.940 of old nodes, won't actually get spent. They'll consider blocks that spend these 00:15:46.940 --> 00:15:51.120 coins invalid, and as long as they're the majority, they'll also create the 00:15:51.120 --> 00:15:55.560 longest chain. So now new nodes are happy because all the new rules are being 00:15:55.560 --> 00:15:59.900 followed, and old nodes are happy because no rules are being broken from their 00:15:59.900 --> 00:16:03.280 perspective, and they just follow the longest chain. So everyone's still in 00:16:03.280 --> 00:16:03.720 consensus. 00:16:04.080 --> 00:16:08.610 Yeah. And this rule I just told you about, this scriptPubKey that puts things on 00:16:08.610 --> 00:16:12.130 the stack, and as long as it's not zero, everybody's happy. It's kind of a hack. 00:16:12.290 --> 00:16:17.690 It's kind of just leveraging some ugly aspect of, you know, ancient ways that 00:16:17.690 --> 00:16:22.730 Bitcoin scripts work. But with SegWit, the first thing will be the number zero or 00:16:22.730 --> 00:16:27.150 the number one, et cetera. And this actually introduces a cleaner variant of the 00:16:27.150 --> 00:16:32.010 same principle, which is that as far as a SegWit node is concerned, 00:16:32.940 --> 00:16:36.220 if it starts with the number zero, it's going to enforce the rules. If it starts 00:16:36.220 --> 00:16:41.200 with the number one or higher, it'll consider it a… it doesn't matter, anybody 00:16:41.200 --> 00:16:46.940 can spend this. And if we get Taproot, then the new nodes will see 00:16:46.940 --> 00:16:50.720 version zero, they'll enforce the rules. They'll see version one, they'll enforce 00:16:50.720 --> 00:16:54.940 the rules. But if they see version two or higher, they will just consider it 00:16:54.940 --> 00:16:59.680 valid. And that means that moving forward, it's much easier to introduce soft 00:16:59.680 --> 00:17:04.170 forks like Taproot without having to find another hack in the old scripting 00:17:04.170 --> 00:17:05.170 system to exploit. 00:17:05.630 --> 00:17:09.990 Right. So SegWit was a little bit of a hack, but it was, in that sense, a 00:17:09.990 --> 00:17:14.590 one-time hack because now we can use versioning. And every time we want to 00:17:14.590 --> 00:17:19.370 introduce a new rule for spending coins, it's going to be pretty clean and easy 00:17:19.370 --> 00:17:20.710 moving forward. 00:17:21.010 --> 00:17:24.290 Yeah, exactly. And within Taproot, I guess there's a little out of scope for this 00:17:24.290 --> 00:17:28.170 one, but within Taproot, we have these multiple branches that can have their own condition. 00:17:29.680 --> 00:17:33.400 Those scripts also have a versioning mechanism. So there's even more versioning 00:17:33.400 --> 00:17:33.940 that can be done. 00:17:34.400 --> 00:17:39.580 Right. One more question, Sjors. We mentioned that the signatures, they're 00:17:39.580 --> 00:17:42.380 included in the end of the block you mentioned. 00:17:42.540 --> 00:17:43.760 I think they're just appended. 00:17:44.020 --> 00:17:49.280 But there's a reference in the coinbase. So how are all these transactions 00:17:49.280 --> 00:17:51.320 included in one little transaction? 00:17:51.620 --> 00:17:52.580 Well, it's called the Merkle tree. 00:17:53.220 --> 00:17:53.800 Merkle tree? 00:17:53.940 --> 00:17:54.080 Yeah. 00:17:54.120 --> 00:17:55.020 This sounds exciting. 00:17:55.220 --> 00:17:57.240 We talked about Merkle trees in an earlier episode. 00:17:57.440 --> 00:17:58.400 I think we did. 00:17:58.620 --> 00:18:02.520 Quite at length. We tried to explain them and it was possibly quite terrible, but 00:18:02.520 --> 00:18:06.520 we've done it and we're not going to do it again. But basically, it's essentially 00:18:06.520 --> 00:18:09.280 just taking a hash, but a Merkle tree is a little bit more elegant than a hash 00:18:09.280 --> 00:18:14.670 because it allows you to… like point to specific elements inside the tree, where 00:18:14.670 --> 00:18:17.790 you know, a hash will just say yes or no for everything that's in it. Could be a 00:18:17.790 --> 00:18:22.270 whole megabyte. It's correct or not. But with a Merkle tree you can say okay, I 00:18:22.270 --> 00:18:26.950 can actually prove that this specific transaction exists inside that tree at that 00:18:26.950 --> 00:18:31.250 position without having to like reveal everything else in it, and that's kind of 00:18:31.250 --> 00:18:31.970 cool. Yeah, 00:18:31.970 --> 00:18:36.400 And I think it's essentially sort of a mirror of the actual transactions, right? 00:18:36.560 --> 00:18:38.980 Which are also included in the Merkle tree in the block. 00:18:39.220 --> 00:18:42.920 Yeah, it's the same idea. So it's not rocket science. 00:18:43.060 --> 00:18:46.820 So we have one Merkle tree for transactions, the regular transaction data, and 00:18:46.820 --> 00:18:52.000 then sort of a mirroring Merkle tree for all the references to the signatures in 00:18:52.000 --> 00:18:52.920 the coinbase block, right? 00:18:53.280 --> 00:18:58.740 Yeah exactly. And I think you could generalize that to something called 00:18:58.740 --> 00:19:03.040 extension blocks, where you could add something else to transactions in the future 00:19:04.400 --> 00:19:08.400 and just refer to that in a coinbase output. And so you could, you know, increase 00:19:08.400 --> 00:19:14.360 block size through soft forks to a degree. But you can't really go super far 00:19:14.360 --> 00:19:19.720 with that because as far as the old, old nodes is concerned, there still has to 00:19:19.720 --> 00:19:22.880 be a valid transaction out there. And a valid transaction probably has to have at 00:19:22.880 --> 00:19:26.840 least an input, you know, and at least an output, even if the output says do 00:19:26.840 --> 00:19:30.200 whatever you want with this. Can't make it smaller than that. And there is still 00:19:30.200 --> 00:19:33.890 the one megabyte limit as far as these old nodes are concerned. You can't use 00:19:33.890 --> 00:19:39.850 extension blocks just to add data to transactions. You can use 00:19:39.850 --> 00:19:43.870 it to add data to transactions, but you can't use it to create an infinite number 00:19:43.870 --> 00:19:49.590 of transactions because those transactions have a minimum size, probably about 60 00:19:49.590 --> 00:19:50.130 bytes. 00:19:51.170 --> 00:19:52.390 We're going off the rails. 00:19:52.630 --> 00:19:56.070 That's fine. All right, bring us back to the rails. I think there were some other 00:19:56.070 --> 00:19:57.710 benefits of SegWit that we wanted to mention. 00:19:57.850 --> 00:20:02.650 Well, so we mentioned transaction malleability is solved, which was necessary for 00:20:02.650 --> 00:20:07.550 something like the Lightning Network. So that's why we have Lightning Network 00:20:07.550 --> 00:20:11.910 now, because we had SegWit. The other benefit we mentioned is block size limit 00:20:11.910 --> 00:20:12.510 increase. 00:20:12.770 --> 00:20:17.950 Yeah, and I guess we had four years almost of low fees. Now they're high again. 00:20:18.710 --> 00:20:24.550 Yeah, they're stacking up now. Then we had the versioning, so easier to 00:20:24.550 --> 00:20:28.430 make new upgrades. Were there more benefits than that? 00:20:29.180 --> 00:20:33.980 Yeah, there is. There is committing to the inputs. So this is fun for hardware 00:20:33.980 --> 00:20:37.060 wallets. If you're a hardware wallet and you want to sign something, we talked 00:20:37.060 --> 00:20:41.700 about that in one of the very first episodes where we explained that if you're a 00:20:41.700 --> 00:20:44.520 hardware wallet and you want to sign a transaction, you want to look at the 00:20:44.520 --> 00:20:48.220 output amounts, you can do that. But you want to make sure that the input 00:20:48.220 --> 00:20:52.740 amounts... actually sort of add up to the same as the output amounts so that 00:20:52.740 --> 00:20:57.240 money isn't just disappearing into fees. But the only way to do that is to 00:20:57.240 --> 00:21:00.340 actually have the input transactions and look at their output amounts. 00:21:01.800 --> 00:21:07.660 And so that meant that in the old days, you would have to send all the input 00:21:07.660 --> 00:21:10.780 transactions to the hardware wallet as well, and it would have to process them, 00:21:10.860 --> 00:21:13.160 and it's kind of a lot of work, or it could be a lot of work if they're big 00:21:13.160 --> 00:21:13.600 transactions. 00:21:14.080 --> 00:21:19.880 Yeah, so to be clear, this is always the case for any wallet. You always, you 00:21:19.880 --> 00:21:24.140 know, you have inputs, that's the coins you own, and then you have the outputs, 00:21:24.300 --> 00:21:28.060 that's the coins you're sending, including a change output to yourself usually. 00:21:28.700 --> 00:21:33.580 And then the difference between them, that's the fee and that's for the miner to keep. 00:21:33.960 --> 00:21:36.540 Yeah, the fee is not actually mentioned in the transaction. 00:21:37.080 --> 00:21:40.700 Yeah, exactly. There's no… there's no fee amount or anything like that in 00:21:40.700 --> 00:21:44.900 transaction. You just have to calculate it yourself. That's fine for a regular 00:21:44.900 --> 00:21:48.480 wallet because the regular wallet just knows how much all of the inputs are worth 00:21:48.480 --> 00:21:53.160 and the outputs are obvious there in the transaction. And then the difference, 00:21:53.360 --> 00:21:58.920 it's easy to calculate. But a hardware wallet is basically just signing 00:21:58.920 --> 00:22:03.980 from private keys and it doesn't necessarily know how much all the inputs are 00:22:03.980 --> 00:22:08.040 worth. So now it's, am I saying this right? Yeah, that's right. Yeah, it's 00:22:08.120 --> 00:22:12.800 sending money away, but it's actually not sure how much money it's sending and 00:22:12.800 --> 00:22:15.980 therefore a hardware wallet has the risk that it's sending 00:22:17.380 --> 00:22:21.040 10 million coins as a fee without realizing that? 00:22:21.040 --> 00:22:24.740 Right. The main problem there is the fee could be arbitrary. And so if somebody 00:22:24.740 --> 00:22:28.840 colludes to the miner or just wants to take your coins hostage in some weird way 00:22:28.840 --> 00:22:34.480 that's not good so what SegWit does is it commits to those inputs. 00:22:34.480 --> 00:22:38.700 So normally, a transaction you know, in the old days a transaction would… the 00:22:38.700 --> 00:22:42.240 input would just be the ID of the transaction that we just talked about with all 00:22:42.240 --> 00:22:47.040 the malleability stuff, and… Yeah, the index, basically. So a transaction has 00:22:47.040 --> 00:22:51.260 multiple outputs, so you'd say this is spending output zero of this and this 00:22:51.260 --> 00:22:55.020 transaction. And with SegWit, what's basically added to that is the amount. 00:22:55.560 --> 00:23:00.550 Actually, not just the amount, I think the entire transaction. So take the 00:23:00.550 --> 00:23:04.590 transaction and hash it, and that's what you're committing to now. And that 00:23:04.590 --> 00:23:08.770 includes the output amounts of that transaction. So now, when you're signing it, 00:23:08.810 --> 00:23:12.810 you can check it. It could still be entirely fake, by the way. You could craft a 00:23:12.810 --> 00:23:17.790 fake transaction with fake inputs and any output amount you want. But then if the 00:23:17.790 --> 00:23:20.870 hardware wallet signs it and you put it on the blockchain, well, it's not going 00:23:20.870 --> 00:23:22.910 to be valid. So that's kind of a useless cheat. 00:23:23.170 --> 00:23:26.170 Yeah, we talked about that in episode two, maybe? 00:23:26.370 --> 00:23:27.630 No, I think in the first episode. 00:23:27.850 --> 00:23:28.310 Episode one? 00:23:28.430 --> 00:23:29.510 Yeah, with the actual tornado. 00:23:30.130 --> 00:23:35.360 Right. Okay, so now we have four... benefits of SegWit one of them is 00:23:35.360 --> 00:23:40.020 malleability, which was sort of the main one. I think that was the reason… it was 00:23:40.020 --> 00:23:44.140 included… it was included in the Elements sidechain of Blockstream, I think, 00:23:44.140 --> 00:23:47.340 before it even made it to Bitcoin. And I think that was the reason they had it 00:23:47.340 --> 00:23:49.560 was solving malleability. 00:23:49.560 --> 00:23:53.130 So, I mean, yeah, it enables things like Lightning. So that's a pretty big 00:23:53.130 --> 00:23:54.110 capacity increase. 00:23:54.130 --> 00:23:58.210 Exactly. So that's one. And then we have the block size increase, which is two. 00:23:58.430 --> 00:24:02.530 Then we have the versioning bits, which makes it easier to deploy future 00:24:02.530 --> 00:24:07.970 upgrades, which is three. And then four, you just mentioned, is the hardware 00:24:07.970 --> 00:24:10.730 wallet fee issue is solved. 00:24:11.670 --> 00:24:15.370 Yeah, or at least we thought it was solved. We explained in the first episode 00:24:15.370 --> 00:24:18.410 that there's some gotchas. But yeah, those are, I think, the four main benefits. 00:24:18.510 --> 00:24:23.160 And I think there's some minor tweaks as well in there. It was a pretty big 00:24:23.160 --> 00:24:26.020 change. Compared to that, Taproot is relatively simple. 00:24:26.300 --> 00:24:31.740 Yeah, so I spent a lot of time on reddit.com slash r/btc, 00:24:31.880 --> 00:24:36.100 and all I read there is that SegWit is the awfulest thing ever. How come, Sjors? 00:24:36.600 --> 00:24:37.280 The awfulest? 00:24:37.440 --> 00:24:38.280 Yes, it's horrible. 00:24:38.900 --> 00:24:44.220 Okay, well, sorry to hear that. I don't know. I mean, I've heard more reasonable 00:24:44.220 --> 00:24:49.580 objections from non-RBTC places saying, well, it would have been slightly simpler 00:24:49.580 --> 00:24:53.560 to do it as a hard fork. But the more I look at it, the less I'm convinced of that. 00:24:54.240 --> 00:24:59.760 Yeah, I guess the argument there would be that the signature hash reference… the 00:24:59.760 --> 00:25:04.500 signature hash tree is included in the coinbase and there would have been a 00:25:04.500 --> 00:25:05.900 cleaner place to put it if… 00:25:06.310 --> 00:25:09.430 Well, you wouldn't have had to put it anywhere. If you do a hard fork, you can 00:25:09.430 --> 00:25:14.530 just add the witness data to the blocks and in the main Merkle tree. So you don't 00:25:14.530 --> 00:25:15.750 need to do anything in the OP_RETURN. 00:25:15.890 --> 00:25:16.130 Right. 00:25:16.710 --> 00:25:20.770 But the downside is you need to actually do a hard fork. And just to think 00:25:20.770 --> 00:25:24.550 through what's involved to do that is that's where all the complexity then goes 00:25:24.550 --> 00:25:29.530 and all the precedent risk. So I think it's good that this was done as a soft fork. 00:25:30.190 --> 00:25:35.770 Yeah, I was saying it in jest, but I think that is probably the only 00:25:35.770 --> 00:25:41.530 argument that I've heard that even makes slight sense, that that's also 00:25:41.530 --> 00:25:44.140 being exposed. [unclear] English word… 00:25:44.230 --> 00:25:45.810 It's been a while since 00:25:45.660 --> 00:25:47.530 I read all that stuff. 00:25:47.710 --> 00:25:51.210 I think that's one of the more serious ones. But other than that, I think the 00:25:51.210 --> 00:25:53.830 main arguments were, you know, it was a Blockstream conspiracy. 00:25:54.690 --> 00:25:56.970