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:10.920 --> 00:00:13.280 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:13.520 --> 00:00:13.740 Hello. 00:00:14.460 --> 00:00:14.900 Hello. 00:00:15.540 --> 00:00:15.800 Hello. 00:00:16.360 --> 00:00:17.160 Hey, who's there? 00:00:17.520 --> 00:00:20.220 I don't know. Someone who's never been on the show before. 00:00:20.700 --> 00:00:21.500 It's Ruben. 00:00:21.680 --> 00:00:21.820 Oh. 00:00:22.360 --> 00:00:23.220 Ruben is back. 00:00:23.620 --> 00:00:23.800 Yeah. 00:00:23.980 --> 00:00:24.100 Again. 00:00:24.420 --> 00:00:24.780 Yeah. 00:00:25.060 --> 00:00:28.280 Ruben, I think you're our in-house sidechain expert. 00:00:28.500 --> 00:00:29.100 I guess so. 00:00:29.100 --> 00:00:35.010 At this point. Well, I would consider you a... You're a… Bitcoin expert. But it 00:00:35.010 --> 00:00:39.950 seems like your specialization lies in all sorts of sidechain. Anything 00:00:39.950 --> 00:00:40.490 sidechain. 00:00:40.650 --> 00:00:44.630 Yeah, that seems like it. It just happened to be like that, become like that. 00:00:44.850 --> 00:00:48.410 Is that how am I using the term correctly? That's how I've been using the term. 00:00:48.510 --> 00:00:52.670 Sidechain is sort of the umbrella term. And we have all sorts of different ways 00:00:52.670 --> 00:00:57.090 of doing it, which have their own names like drive chain or state chain. 00:00:59.170 --> 00:01:02.720 Depends if you're picking on the definition of sidechain, then it's not. Then you 00:01:02.720 --> 00:01:05.980 would just say other chain or related chain, I guess. 00:01:06.400 --> 00:01:09.980 Yeah, but that doesn't really roll off the tongue. I'm a other chain expert. 00:01:12.480 --> 00:01:14.180 Well, not altcoins, I guess. 00:01:14.340 --> 00:01:15.140 No, you're not altcoins. 00:01:15.380 --> 00:01:19.600 So it's difficult. Yeah, I like, generally speaking, I'm very much interested in 00:01:19.600 --> 00:01:24.280 trying to get Bitcoin to do more with less. And I think sidechains are a good 00:01:24.280 --> 00:01:29.100 avenue for reaching that. So that's kind of why I think I spend a lot of time 00:01:29.100 --> 00:01:29.860 thinking about these things. 00:01:30.100 --> 00:01:34.280 Yeah, so you came up with another idea, another type of sidechain, I would call 00:01:34.280 --> 00:01:35.880 it, which is called a softchain. 00:01:36.020 --> 00:01:36.440 That's right. 00:01:36.680 --> 00:01:38.600 And that's what we're going to discuss today. 00:01:38.980 --> 00:01:41.000 Yeah, we're going to try and understand it. 00:01:41.370 --> 00:01:41.830 Great. 00:01:42.110 --> 00:01:46.710 So first of all, for the listeners who haven't listened to one of the previous 00:01:46.710 --> 00:01:50.750 episodes about sidechains, Ruben, what is a sidechain? Briefly. 00:01:50.890 --> 00:01:56.770 Yeah, so a sidechain is basically a completely separate chain, ideally, that 00:01:56.770 --> 00:02:02.140 you can move your bitcoins to and you can move your bitcoins back again. And the 00:02:02.140 --> 00:02:06.900 dream is kind of that you can build out this ecosystem where your bitcoins are 00:02:06.900 --> 00:02:12.340 not necessarily stuck with Bitcoin's validation rules. But if you like 00:02:12.340 --> 00:02:15.460 Ethereum's validation rules or something, you could maybe move your bitcoins to 00:02:15.460 --> 00:02:19.960 some Ethereum-like chain and use them there. And then when you are done again, 00:02:20.000 --> 00:02:22.920 because you figured out that Ethereum is not so great after all, you can move 00:02:22.920 --> 00:02:28.310 back to Bitcoin. Buying and selling is not quite that at all. And this kind of 00:02:28.310 --> 00:02:32.530 preserves the 21 million Bitcoin limits, where you don't have to deal with all 00:02:32.530 --> 00:02:37.090 these altcoin shenanigans, yet you still get all the functionality that you might 00:02:37.090 --> 00:02:39.230 want that is not available in Bitcoin currently. 00:02:39.690 --> 00:02:43.390 So that's an argument from experimentation or from more features. 00:02:43.670 --> 00:02:44.590 I guess so. Yeah. 00:02:44.610 --> 00:02:47.630 And your other argument, I guess, would be scale, in theory. 00:02:47.870 --> 00:02:51.750 Yeah, yeah, that's definitely a second argument. Good point. Yeah, if you have 00:02:51.750 --> 00:02:56.020 all these sidechains, then potentially, you could have more block space. You 00:02:56.020 --> 00:02:58.780 could have multiple sidechains that are just like Bitcoin or maybe slightly 00:02:58.780 --> 00:03:03.300 different. And yeah, it basically gives you more block space for people to use. 00:03:03.640 --> 00:03:07.600 Yeah. So let's say you want to use some sort of DeFi app that's not really 00:03:07.600 --> 00:03:11.020 compatible with the current Bitcoin protocol. You can move it to a sidechain. 00:03:11.580 --> 00:03:15.180 That has these Ethereum rules and you can do all your DeFi stuff there. And then 00:03:15.180 --> 00:03:18.240 when you're done, you move back your bitcoins to the main Bitcoin blockchain. 00:03:18.580 --> 00:03:22.760 Yeah. And importantly, yeah, you can do it with your bitcoins, right? Because we 00:03:22.760 --> 00:03:26.280 talked about, I think I didn't call it space chains back then, but I call it 00:03:26.280 --> 00:03:30.920 space chains now, which is blind merge mining in a perpetual one-way peg. So that 00:03:30.920 --> 00:03:35.320 one did not allow you to move your bitcoins to, well, you could move to the other 00:03:35.320 --> 00:03:38.560 chain, but you couldn't move back. So this proposal actually allows you to move 00:03:38.560 --> 00:03:41.560 back. But there are obviously downsides as well, which we'll get into. 00:03:41.560 --> 00:03:45.460 Yeah. A couple of weeks ago, we talked about drive chains, which do allow you to 00:03:45.460 --> 00:03:46.380 move your coins back. 00:03:46.810 --> 00:03:50.230 Yeah. And that's also good to kind of point out the difference. So with drive 00:03:50.230 --> 00:03:55.170 chains, very high level, the miners basically control the bitcoins and they 00:03:55.170 --> 00:03:58.730 decide whether or not you get to move back. And with this proposal, it wouldn't 00:03:58.730 --> 00:04:02.770 be like that. It would actually be consensus, basically, whether or not you get 00:04:02.770 --> 00:04:03.250 to move back. 00:04:03.490 --> 00:04:07.390 Yeah. So we just gave a DeFi example. Other examples would be like Zcash, 00:04:07.610 --> 00:04:12.070 sidechain, or like any altcoin that's out there. Basically, you could instead use 00:04:12.070 --> 00:04:15.430 a sidechain and then therefore use sort of the Bitcoin currency unit. 00:04:15.570 --> 00:04:15.710 Yeah. 00:04:16.160 --> 00:04:18.360 Under these different rules and conditions. 00:04:18.520 --> 00:04:18.840 That's right. 00:04:19.160 --> 00:04:23.440 All right. So soft chains, your new, well, is it new? No, when did you propose this? 00:04:23.640 --> 00:04:29.060 Yes and no, it's new. I posted it December 31st last year. So not too long ago 00:04:29.060 --> 00:04:32.580 because we just entered this year. So it was a little New Year's gift, so to speak. 00:04:32.760 --> 00:04:33.740 It's your newest one. 00:04:33.860 --> 00:04:38.440 It's my newest one, but it's, you know, I'm building forth on work that I did 00:04:38.440 --> 00:04:42.960 about a year and a half ago on proof of work fraud proofs. So it's not completely 00:04:42.960 --> 00:04:46.100 new, but the kind of sidechain aspect of it is new. 00:04:46.320 --> 00:04:51.020 Right. So yeah, that is the first step in explaining how soft chains work or 00:04:51.020 --> 00:04:51.760 proof of work. 00:04:51.920 --> 00:04:52.600 Fraud proofs. 00:04:52.740 --> 00:04:57.200 Fraud proofs, exactly. So let's get into that. And before we get into that, I 00:04:57.200 --> 00:05:00.900 want to tell the listener, at this point, it's probably easiest if you forget 00:05:00.900 --> 00:05:05.580 about sidechains for a minute. Ruben is just going to explain a consensus 00:05:05.580 --> 00:05:09.820 mechanism. It could potentially work on the Bitcoin main chain as well. 00:05:10.080 --> 00:05:10.220 Yeah. 00:05:10.560 --> 00:05:14.220 Okay, so let's get into it. What are proof of work fraud proofs? 00:05:14.260 --> 00:05:17.940 Yeah, so we're taking a bit of a detour here and we're going to be talking about 00:05:17.940 --> 00:05:23.540 how you could potentially validate a blockchain, such as Bitcoin or other 00:05:23.540 --> 00:05:29.220 blockchains, in a way that is very cheap to validate, essentially. So it's kind 00:05:29.220 --> 00:05:34.320 of like one way of doing that would be SPV proofs, where SPV basically means you 00:05:34.320 --> 00:05:39.430 look at the proof of work. And you just assume that whichever chain with the most 00:05:39.430 --> 00:05:42.750 proof of work, a lot of effort went into creating that chain, so it must be 00:05:42.750 --> 00:05:47.110 valid. Like that's one way you can get very cheap consensus. But the general 00:05:47.110 --> 00:05:51.290 issue with that is that you're trusting that 51% of the miners or more is 00:05:51.290 --> 00:05:54.970 actually telling you the truth. And if everybody starts relying on that, these 00:05:54.970 --> 00:05:58.330 miners could actually create coins out of thin air. So it's not very secure, but 00:05:58.330 --> 00:06:00.370 it would be one way of kind of getting cheap consensus. 00:06:00.830 --> 00:06:06.730 Yeah. So the normal way to achieve that is for everyone on the network 00:06:06.730 --> 00:06:10.150 to control, to check every, to validate every protocol rule. 00:06:10.270 --> 00:06:10.490 Yes. 00:06:10.670 --> 00:06:13.310 To validate that everything that happens in every block is valid. 00:06:13.590 --> 00:06:13.790 Yeah. 00:06:13.990 --> 00:06:18.110 And then SPV, like you explained, is a much cheaper way to do it because you're 00:06:18.110 --> 00:06:21.610 not checking everything in every block. You're only checking the proof of work. Yeah. 00:06:21.810 --> 00:06:24.930 And so in episode 25, we actually explained SPV. 00:06:25.010 --> 00:06:25.590 Oh, great. Yeah. 00:06:25.710 --> 00:06:30.860 Right. And then soft chains is a method sort of in between. 00:06:31.160 --> 00:06:33.920 Well, proof of work, fraud proofs, right? That's why we're not talking about the 00:06:33.920 --> 00:06:34.480 soft chains yet. 00:06:34.480 --> 00:06:35.060 You're right. 00:06:35.200 --> 00:06:35.320 Yeah. 00:06:36.200 --> 00:06:40.720 It's sort of in between full validation and SPV validation in a way. 00:06:40.800 --> 00:06:46.700 So if you look at SPV, the assumption is SPV works if 51% of all miners are 00:06:46.700 --> 00:06:52.080 being honest. And with proof of work fraud proofs, what you can do is you can say 00:06:52.080 --> 00:06:58.030 this validation method works if there is some honest miner 00:06:58.030 --> 00:07:02.330 out there and you can choose whatever percentage you like, if you say it's 1%, 00:07:02.330 --> 00:07:07.670 that's fine. You can go all the way conservative to say 0.01%. But the difference 00:07:07.670 --> 00:07:13.770 is that what your assumption is affects how slow your validation is. 00:07:14.590 --> 00:07:20.460 You need more confirmations if you want to trust less miners, am I 00:07:20.460 --> 00:07:20.920 saying that right? 00:07:20.920 --> 00:07:25.060 Yeah, so so let's take a simple number like one percent, if you assume that only 00:07:25.060 --> 00:07:29.140 one percent of all miners is honest and 99 is out there to get you, it basically 00:07:29.140 --> 00:07:34.200 means that you got to wait for that honest miner to create their block. And if 00:07:34.200 --> 00:07:38.100 you don't see that block, well, you're not going to see that block until you've 00:07:38.100 --> 00:07:41.820 given them enough time to actually create that block. So that's why it's a slow 00:07:41.820 --> 00:07:46.180 consensus mechanism, but it's much more secure than SPV. And you no longer have 00:07:46.180 --> 00:07:47.340 the 51% assumption. 00:07:47.760 --> 00:07:53.760 Yeah. So to restate that with SPV, with full validation, you don't need 00:07:53.760 --> 00:07:58.400 to trust any hash power, basically. With SPV, you need to trust that at least 00:07:58.400 --> 00:07:59.720 half hash power is honest. 00:08:00.020 --> 00:08:01.180 Yeah. More than half, yeah. 00:08:02.100 --> 00:08:04.700 Proof of war— work frauds proofs… 00:08:04.700 --> 00:08:05.540 Sorry for the name. Yeah. 00:08:05.540 --> 00:08:11.440 You can sort of pick your own level of trust in hash power and then depending on 00:08:11.440 --> 00:08:13.520 that you need to wait for more confirmations. 00:08:13.520 --> 00:08:14.000 Yeah. 00:08:14.000 --> 00:08:18.340 And let's say I think okay I think at least one percent of hash power is going to 00:08:18.340 --> 00:08:23.080 be honest so therefore I'm just going to wait a whole day of confirmations for 00:08:23.080 --> 00:08:26.860 example. Yeah that's maybe two days or whatever. Yeah. Okay. So how does this work? 00:08:26.860 --> 00:08:32.860 Yeah exactly. So so the way this works is you only look at the forks. So if you 00:08:32.860 --> 00:08:36.000 have normally, when you have the Bitcoin blockchain, you download all the 00:08:36.000 --> 00:08:38.640 headers, and then you download all the blocks that are associated with the 00:08:38.640 --> 00:08:43.220 headers. But what you do here is you start with only the headers, and then you 00:08:43.220 --> 00:08:47.380 look whether there are forks. So maybe you have like a block one, block two, 00:08:47.500 --> 00:08:52.040 block three, four, five. And then somewhere along the line, you see another block 00:08:52.040 --> 00:08:56.400 three. So block three B, let's say. So there's one, two, three B, and there's 00:08:56.400 --> 00:08:58.140 one, two, three, A, four, five. 00:08:59.290 --> 00:09:03.290 I want to make a small clarification for listeners that don't know this because 00:09:03.290 --> 00:09:05.210 the term fork is very confusing. 00:09:05.350 --> 00:09:05.890 That's true, yeah. 00:09:05.970 --> 00:09:11.030 We're not talking about Bcash kind of altcoin forks or anything like that. We're 00:09:11.030 --> 00:09:14.990 just talking about the normal operation of things in Bitcoin where sometimes, for 00:09:14.990 --> 00:09:19.830 example, by coincidence, two competing blocks are mined by different miners and 00:09:19.830 --> 00:09:21.850 then eventually the longest chain wins out, right? 00:09:22.110 --> 00:09:22.890 Yeah, that's correct. 00:09:22.890 --> 00:09:24.450 That's the type of fork we're talking about here. 00:09:24.450 --> 00:09:27.150 Yeah, which we mentioned in last week's episode. 00:09:27.490 --> 00:09:27.910 Perfect. 00:09:28.430 --> 00:09:30.870 You're like an encyclopedia of episodes. 00:09:31.790 --> 00:09:31.870 Yeah, 00:09:32.430 --> 00:09:37.470 So basically these are regular, naturally occurring forks that would happen in 00:09:37.470 --> 00:09:43.330 Bitcoin anyway, just by pure coincidence or if a miner just happens to mess up or 00:09:43.330 --> 00:09:48.350 whatever. So these occur naturally. But there are also reasons why they could 00:09:48.350 --> 00:09:52.430 occur kind of unnaturally, which is that a miner is kind of deliberately trying 00:09:52.430 --> 00:09:56.270 to create an invalid… and if there's a deliberate attempt to create an invalid 00:09:56.270 --> 00:10:00.590 block, all the miners that kind of don't want to participate in that invalid 00:10:00.590 --> 00:10:06.590 chain, they need to fork away from that chain. So given we kind of can… 00:10:06.590 --> 00:10:10.530 Hang on, do you mean by invalid in this context? Do you mean that it's breaking 00:10:10.530 --> 00:10:11.230 protocol rules? 00:10:11.410 --> 00:10:12.250 Exactly, yeah. 00:10:12.690 --> 00:10:16.930 So for example, the miner is awarding itself a thousand Bitcoin as a block reward. 00:10:17.150 --> 00:10:21.470 Yeah, so basically anything that your full node would reject. If your full node 00:10:21.470 --> 00:10:24.570 were to download the block and validate the block and they would reject the 00:10:24.570 --> 00:10:26.310 block, that would be an invalid block. 00:10:26.450 --> 00:10:31.320 Right, yeah. So it's possible for miners to create invalid blocks. Then you have 00:10:31.320 --> 00:10:33.520 a fork, basically. What happens then, Ruben? 00:10:33.680 --> 00:10:38.400 Yeah, so that's kind of what you want to check for, right? You want to figure out 00:10:38.400 --> 00:10:43.620 whether something is invalid. And so this is called proof-of-work fraud proofs. 00:10:43.700 --> 00:10:48.240 And the reason for that is maybe it's not the best name. Sjors, you had a suggestion. 00:10:48.500 --> 00:10:50.480 I think it was proof-of-work fraud indicator. 00:10:50.700 --> 00:10:54.260 Fraud indicator, yeah. So I like that. I forgot it again, but yeah, it's good. So 00:10:54.260 --> 00:10:59.310 fraud indicator, let's say. The fact that there's a fork is an indication 00:10:59.310 --> 00:11:05.210 that the block you're forking away from might be invalid, but you don't know for sure. 00:11:05.370 --> 00:11:06.590 May or may not be, yeah. 00:11:07.070 --> 00:11:11.850 So if we then had a method to validate that specific block, we could actually 00:11:11.850 --> 00:11:17.370 kind of investigate that claim and see whether or not something is wrong. So 00:11:17.370 --> 00:11:21.150 that's the first thing. And the second thing is that this miner that created the 00:11:21.150 --> 00:11:26.960 forked block, they did choose to mine… the block before it is the same 00:11:26.960 --> 00:11:28.220 in both forks. 00:11:28.340 --> 00:11:33.380 Yeah, they still agree that the block came... Before it is valid. Everyone 00:11:33.380 --> 00:11:37.320 basically, of all the forks you're seeing, everyone agrees that block is valid at least. 00:11:37.640 --> 00:11:40.320 Yeah, otherwise they wouldn't have forked from that point. They would have forked 00:11:40.320 --> 00:11:40.920 earlier. 00:11:41.180 --> 00:11:41.360 Right. 00:11:41.700 --> 00:11:47.500 So we have two assumptions here. We have the assumption that that block 00:11:47.500 --> 00:11:51.740 might be invalid and the block before it, all the miners agree that it's valid. 00:11:51.920 --> 00:11:52.080 Right. 00:11:52.520 --> 00:11:56.280 So with that assumption, now what you need is you need to download block three 00:11:56.280 --> 00:12:00.320 and you need to validate it. But we have a problem because you need the UTXO sets. 00:12:00.800 --> 00:12:05.260 To validate the block right because every block contains transactions which refer 00:12:05.260 --> 00:12:09.280 back to previous transactions and those previous transactions well they're not in 00:12:09.280 --> 00:12:13.240 this block so either you have to download all the other blocks or you need to 00:12:13.240 --> 00:12:17.320 keep track of you know which coins currently exist and that is the UTXO set. 00:12:17.320 --> 00:12:20.920 Yeah, which we discussed in episode well… 00:12:20.920 --> 00:12:24.200 In a whole bunch of episodes but in particular because of where we're going in 00:12:24.200 --> 00:12:29.880 episode 15 where we explain Utreexo and UTXO commitments right. 00:12:30.540 --> 00:12:34.620 So yeah, Utreexo, which is definitely an episode I think you should go back and 00:12:34.620 --> 00:12:40.560 listen to, but Utreexo basically gives you a solution to validate blocks without 00:12:40.560 --> 00:12:46.100 having the entire [unclear] sets. You just need a hash. And then you need some 00:12:46.100 --> 00:12:50.120 proofs that are attached to the hash. And that allows you to validate a 00:12:50.120 --> 00:12:53.860 transition. So in this case, from block two to block three, we can validate that 00:12:53.860 --> 00:12:59.480 transition. So what you need inside of block two, inside of consensus, is a 00:12:59.480 --> 00:13:04.760 hash to the Utreexo state. And with that state, which you assume is valid, 00:13:04.880 --> 00:13:09.390 because we're assuming block two is valid, you can then… validate the transition 00:13:09.510 --> 00:13:14.470 from block two to block three, without requiring the entire UTXO set. And that's 00:13:14.470 --> 00:13:18.410 how we achieve basically what we want, which is validating block three and 00:13:18.410 --> 00:13:21.310 figuring out whether the most proof of work chain is valid or not. 00:13:21.710 --> 00:13:26.090 Yeah, so the reason it's that much lighter than full validation is because you're 00:13:26.090 --> 00:13:31.210 not downloading all the blocks. You're only looking for potential conflicts where 00:13:31.210 --> 00:13:34.370 they exist. And that's the only thing you check. 00:13:34.670 --> 00:13:34.810 Yeah. 00:13:34.930 --> 00:13:37.760 Well, plus... The block headers, the proof of work for all blocks. 00:13:37.940 --> 00:13:41.580 Yeah, so it's basically every block for which there is another block at the same 00:13:41.580 --> 00:13:46.600 block height. You need to go and check the block inside of the most proof of work chain. 00:13:46.800 --> 00:13:47.120 Right. 00:13:47.360 --> 00:13:51.560 And if you're bored, you can also check, you know, a random other block as a spot 00:13:51.560 --> 00:13:53.880 check. Although for this mechanism, that doesn't really matter. 00:13:54.140 --> 00:13:57.780 Yeah, I don't think it would do anything here, but it's definitely interesting 00:13:57.780 --> 00:14:01.020 that it's possible, thanks to Utreexo, if you have these commitments. 00:14:01.300 --> 00:14:05.040 Yeah, so the interesting thing, there are different ways of doing commitments of 00:14:05.040 --> 00:14:10.800 the UTXO set in blocks. And Utreexo is a very interesting one, because 00:14:10.800 --> 00:14:14.460 it's not just a commitment, that you can, you know, if you have the UTXO set, you 00:14:14.460 --> 00:14:19.920 can figure out what the Utreexo is, but you could have a different hash as well 00:14:19.920 --> 00:14:25.840 but that hash won't be very useful to check the next block and with Utreexo it is 00:14:25.840 --> 00:14:29.080 useful to check the next block because you can it's a hash that you can add 00:14:29.080 --> 00:14:32.440 things to. It's an accumulator. Yeah, so I can take the hash of the previous 00:14:32.440 --> 00:14:36.200 block add all the transactions to it and now I have the hash of the new block. 00:14:36.200 --> 00:14:41.420 Yeah, and well we explained that in episode 15, but not all UTXO commitments will 00:14:41.420 --> 00:14:42.080 work like this. 00:14:42.080 --> 00:14:42.660 Yeah, that's right. 00:14:42.660 --> 00:14:46.660 So yeah, I want to point out right here that this, what you just explained, this 00:14:46.660 --> 00:14:51.360 is why you potentially only need one percent of honest miners. Now let's say in 00:14:51.360 --> 00:14:56.650 this example, you just gave proof of work, fraud proofs, fraud indicators. If 00:14:56.650 --> 00:15:01.630 100% of miners is dishonest, then you're never going to find out because there's 00:15:01.630 --> 00:15:05.090 never going to be a conflicting block. They're always colluding and you're just 00:15:05.090 --> 00:15:06.030 never going to find out. 00:15:06.190 --> 00:15:06.530 Yes. 00:15:06.630 --> 00:15:11.070 But if there's even 1% of honest miners, then at some point that one honest miner 00:15:11.070 --> 00:15:14.550 isn't going to build on the longest proof of work chain because they think it's 00:15:14.550 --> 00:15:18.510 invalid. They know it's invalid. Instead, they're going to create a conflicting 00:15:18.510 --> 00:15:23.230 block that's honest. So even if there were like 100 blocks that were dishonest, 00:15:23.980 --> 00:15:27.900 after block one or whatever. And then at some point, the honest miner will create 00:15:27.900 --> 00:15:33.750 an honest block two. At that point, you see the conflict and you go check which 00:15:33.750 --> 00:15:39.270 of the two block twos is valid. If you see that a block two that created, that 00:15:39.270 --> 00:15:43.110 preceded the 100 blockchain with 100 blocks, then you're just going to reject all 00:15:43.110 --> 00:15:46.690 100 blocks and you're going to continue only on this block number two. 00:15:46.970 --> 00:15:47.130 Yeah. 00:15:47.330 --> 00:15:52.750 So it's important to point out here that the creation of the fork is really not a 00:15:52.750 --> 00:15:57.600 sacrifice, right? It's not that that person who created that fork block and 00:15:57.600 --> 00:16:02.180 caused the 100 blocks to be rejected. That's just kind of the normal way things 00:16:02.180 --> 00:16:05.360 should be. Like that person who created the forked block, they get the block 00:16:05.360 --> 00:16:08.960 reward, whereas everybody else who was building on the invalid chain, they get 00:16:08.960 --> 00:16:10.640 nothing, right? Because their chain is invalidated. 00:16:10.740 --> 00:16:15.100 Right, but it is a little bit risky because at any point, if you're proposing, if 00:16:15.100 --> 00:16:18.040 you're telling the rest of the network, oh, we're about to do a 100 block reorg, 00:16:18.480 --> 00:16:22.060 or maybe a thousand or whatever it is, at some point the rest of the network 00:16:22.060 --> 00:16:26.290 might say, well, although you're right, like it's not worth the damage that this 00:16:26.290 --> 00:16:29.870 reorg does, but we don't want to get too far ahead of our discussion section… 00:16:29.870 --> 00:16:31.750 But, well, we can get into this now maybe? 00:16:31.750 --> 00:16:32.830 Yeah, I think it's a good like… 00:16:32.830 --> 00:16:38.090 Yeah a lot of people might say, well I just sold my car for these coins or I just 00:16:38.090 --> 00:16:43.750 you know I just accepted rent or whatever let's you know okay yes sure the chain 00:16:43.750 --> 00:16:47.880 turned out to be invalid but, let's just forget about it. Let's just continue on 00:16:47.880 --> 00:16:51.560 this chain because I don't want to lose all this money I received. That's sort of 00:16:51.560 --> 00:16:57.060 possible. That's sort of complicated incentive thing going on there, game theory thing. 00:16:57.360 --> 00:17:01.240 Now, of course, if you're receiving money on one of those soft chains or whatever 00:17:01.240 --> 00:17:05.340 thing is built on top of this mechanism, if you're the one receiving coins on it, 00:17:05.440 --> 00:17:10.260 you probably want to do full validation of that particular chain. So at least you 00:17:10.260 --> 00:17:13.740 know that there's a problem. But then you could still have the opposite, where 00:17:13.740 --> 00:17:18.800 you can see that there's cheating going on, but you may have to wait a whole year 00:17:18.800 --> 00:17:22.780 for any miner to agree with you on the fact that there's cheating going on. 00:17:23.090 --> 00:17:26.250 Because all the other people are not validating. You're the only one validating. 00:17:26.510 --> 00:17:31.030 Yeah, so the people who are not validating, not fully validating, but only 00:17:31.030 --> 00:17:35.650 basically doing the proof of work fraud proof validation, they have an assumption 00:17:35.650 --> 00:17:39.210 to make, right? Like they have to assume that there is a honest miner out there 00:17:39.210 --> 00:17:43.550 and they have to, because of that assumption, they have to slow down how long 00:17:43.550 --> 00:17:47.630 they wait. So if you receive money for a car and you use this consensus mechanism 00:17:47.630 --> 00:17:52.980 and you don't wait for the proper number of blocks, yeah, that is just... The 00:17:52.980 --> 00:17:56.440 wrong behavior, basically. That's not what you're supposed to so that's basically 00:17:56.440 --> 00:18:01.220 outside of the trust assumption of this model. But if your assumption is wrong, 00:18:01.220 --> 00:18:03.720 right, if you just assume one percent of all miners is honest, and that's 00:18:03.720 --> 00:18:06.360 actually a wrong assumption, yeah, then then you are screwed. So that's 00:18:06.360 --> 00:18:10.020 definitely, you got to make a conservative choice there. And for that reason, 00:18:10.020 --> 00:18:13.960 this consensus mechanism isn't isn't very practical. Instead of a full node, like 00:18:13.960 --> 00:18:16.160 you could theoretically run this on your phone or something, right? 00:18:16.510 --> 00:18:22.150 So ironically, this reverses the risks when compared to how Bitcoin works when it 00:18:22.150 --> 00:18:26.650 comes to light nodes. So if on Bitcoin, you're running an SPV node, but you see 00:18:26.650 --> 00:18:30.390 that if you're running the SPV node, you might be cheated because you're only 00:18:30.390 --> 00:18:35.150 checking the proof of work. But whoever runs the full node knows exactly what's 00:18:35.150 --> 00:18:38.970 going on. But here it could be the opposite. You could be running a full node, 00:18:38.990 --> 00:18:43.030 you could be verifying everything very carefully, but you just don't get all the 00:18:43.030 --> 00:18:47.130 headers for some reason. And so, yeah, you might not know that somebody else is 00:18:47.130 --> 00:18:51.750 out there lying, basically. You'd have to not see a very long chain of headers, 00:18:51.870 --> 00:18:52.410 but... 00:18:52.410 --> 00:18:56.110 Well, if they're invalid headers, presumably none of your peers are going to tell 00:18:56.110 --> 00:19:00.070 you about it because they're invalid. So maybe it's possible to not be aware. 00:19:00.930 --> 00:19:05.630 Right. Yeah, I guess you'd still be following the valid chain, but you might not 00:19:05.630 --> 00:19:08.590 know that there's an invalid chain out there because you might only be talking to 00:19:08.590 --> 00:19:11.950 other full nodes. So you don't know that the rest of the network is kind of 00:19:11.950 --> 00:19:15.890 trusting on an invalid chain and shit is about to hit the fan. Although you have 00:19:15.890 --> 00:19:19.710 the correct chain, it may take a while for the rest of the network to agree on 00:19:19.710 --> 00:19:22.990 that because there's an invalid chain out there that you don't know about. Though 00:19:22.990 --> 00:19:24.130 I guess you would know about it. 00:19:24.290 --> 00:19:29.800 Yeah, I think arguably it might be just good in general to... Give all valid 00:19:29.800 --> 00:19:33.020 proof-of-work headers to all the full nodes, regardless of whether or not they're 00:19:33.020 --> 00:19:37.140 in the most proof-of-work chain, just as an indicator of whether something is 00:19:37.140 --> 00:19:39.840 wrong. But that's kind of a separate discussion. 00:19:40.380 --> 00:19:40.740 Yeah. 00:19:41.000 --> 00:19:46.760 So we've explained this consensus mechanism in general terms. 00:19:47.040 --> 00:19:47.380 Yeah. 00:19:47.540 --> 00:19:49.760 So how do we apply this as a sidechain? 00:19:49.940 --> 00:19:50.220 Yeah. 00:19:50.360 --> 00:19:51.480 That would be the next step, right? 00:19:51.680 --> 00:19:55.260 Yeah. Yeah. So now we have this consensus mechanism, which you could 00:19:55.260 --> 00:19:58.420 theoretically apply to Bitcoin and you could have consensus this way, but just 00:19:58.420 --> 00:19:58.900 very slowly. 00:19:59.300 --> 00:20:02.460 Yeah. Plus it would require Utreexo or something like that. 00:20:02.540 --> 00:20:02.640 Yeah. 00:20:03.320 --> 00:20:08.490 Which doesn't exist. We create a sidechain, it's easy to just implement it there. 00:20:08.730 --> 00:20:14.260 Yeah, I have a method of actually not even requiring a 00:20:14.260 --> 00:20:20.020 Utreexo commitment, but let's not go into that. But there's a post out there if 00:20:20.020 --> 00:20:20.760 you're interested in that. 00:20:20.920 --> 00:20:26.130 But it is good to realize that... The Utreexo and the commitments, they are a bit 00:20:26.130 --> 00:20:29.770 of a controversial idea. But in this case, they wouldn't have to happen on the 00:20:29.770 --> 00:20:33.470 Bitcoin side. They'd have to happen on the sidechain side. And so maybe we'd be 00:20:33.470 --> 00:20:34.050 fine with that. 00:20:34.350 --> 00:20:38.250 Yeah, yeah, exactly. So what we're doing here is we're using this consensus 00:20:38.250 --> 00:20:42.670 mechanism for the sidechains or softchains, as I call them, that we're going to 00:20:42.670 --> 00:20:47.490 be introducing. So on the side of the softchains, you need to have these Utreexo 00:20:47.490 --> 00:20:52.340 set commitments, but not inside of the Bitcoin blockchain. So that's not 00:20:52.340 --> 00:20:54.660 something that we require for Bitcoin here. 00:20:54.900 --> 00:20:57.100 But you do need some soft fork on the Bitcoin side. 00:20:57.100 --> 00:20:58.060 Yes, yeah, absolutely. 00:20:58.320 --> 00:20:58.700 Tell us. 00:20:58.940 --> 00:21:04.840 Yeah. So the way it works is we are going to introduce a soft fork. And 00:21:04.840 --> 00:21:09.380 let's say we just start very simply. Let's say we want to create 10 more copies 00:21:09.380 --> 00:21:13.580 of Bitcoin. We use Bitcoin Core for it, exactly the same. So we kind of want to 00:21:13.580 --> 00:21:18.340 create a kind of a side chain block size increase, so to speak. So we create 00:21:18.340 --> 00:21:23.040 these 10 chains. And they will have no coins on them. And there's going to be no 00:21:23.040 --> 00:21:27.060 block reward or no coins being generated every block. But people can move their 00:21:27.060 --> 00:21:30.420 coins in. And moving their coins in is going to be very simple. It's just you 00:21:30.420 --> 00:21:33.980 freeze your coins on the Bitcoin blockchain and you point to a chain that you 00:21:33.980 --> 00:21:39.880 want to go to. And then what we do is we expect everybody who 00:21:39.880 --> 00:21:44.700 runs a Bitcoin full node to validate these 10 other soft chains. But they 00:21:44.700 --> 00:21:49.210 validate them through these proof of work fraud proofs. And roughly speaking... 00:21:49.210 --> 00:21:49.830 Fraud indicators. 00:21:50.070 --> 00:21:54.530 Fraud indicators. Yeah, that's a better name. And roughly looking at the Bitcoin 00:21:54.530 --> 00:21:58.390 blockchain and its history and looking at kind of just natural forks occurring by 00:21:58.390 --> 00:22:02.230 accident. This comes down to, I think it was roughly, I don't remember the exact 00:22:02.230 --> 00:22:05.810 numbers, but something like 40 blocks a year. That's probably even on the high 00:22:05.810 --> 00:22:11.450 end. And roughly this would cost you, including the headers, 100 megabytes per 00:22:11.450 --> 00:22:12.290 chain per year. 00:22:12.450 --> 00:22:15.680 What you mean is 40 fork blocks, basically, right? 00:22:15.680 --> 00:22:15.960 Yes. 00:22:15.960 --> 00:22:20.220 So 40 times where you'd have to check… exactly, if anything weird is going on. 00:22:20.220 --> 00:22:24.460 Yeah. And that's with, yeah, not, you know, non-malicious. Nobody on purpose… 00:22:24.460 --> 00:22:27.720 well, presumably, I guess we don't know what what the reason was for these forks. 00:22:27.720 --> 00:22:28.800 Sure. Yeah. 00:22:28.800 --> 00:22:34.680 So given roughly those numbers, we can introduce those 10 chains and we can get 00:22:34.680 --> 00:22:38.160 everybody to validate them with proof-of-work fraud proofs and it would cost them 00:22:38.160 --> 00:22:44.030 10 times 100 megabytes per year. So roughly one gigabytes. And if 00:22:44.030 --> 00:22:49.790 we thought that was a burden on the full nodes, we could even combine this with a 00:22:49.790 --> 00:22:54.450 block size decrease. I think one gigabyte is only like minus 1% or something. So 00:22:54.450 --> 00:22:58.370 we could decrease the Bitcoin block size by 1% to compensate for the extra cost. 00:22:58.610 --> 00:23:03.690 And then we basically introduce these 10 chains. And it's important to note, and 00:23:03.690 --> 00:23:06.690 this is something that some people I've explained this to have gotten confused 00:23:06.690 --> 00:23:11.620 about, you completely separately validate the header. So you just have to get the 00:23:11.620 --> 00:23:16.060 headers from the peer-to-peer network, from these proof of work, from these soft 00:23:16.060 --> 00:23:18.820 chains. So they're not going to be committed inside of the Bitcoin blockchain or 00:23:18.820 --> 00:23:19.460 anything like that. 00:23:19.680 --> 00:23:22.640 It is essentially like you're running 11 nodes. 00:23:22.840 --> 00:23:23.140 Yes. 00:23:23.140 --> 00:23:27.160 So your main Bitcoin node does full validation and then you have 10 Bitcoin 00:23:27.160 --> 00:23:31.200 sidechain nodes built in, of course, that are doing this partial validation by 00:23:31.200 --> 00:23:33.420 just doing the headers and just checking conflicts. 00:23:33.780 --> 00:23:39.570 Yeah, that's right. And then what we do is we make the peg outs incredibly slow. 00:23:39.770 --> 00:23:44.830 We make them like a one year period. So the peg out meaning you moved your coins 00:23:44.830 --> 00:23:48.690 to the soft chain and now you want to move back. So moving back is going to take 00:23:48.690 --> 00:23:53.050 a year. And the reason we do that is because we don't want to rely too much on 00:23:53.050 --> 00:23:56.650 miners. And if we wait a year, I don't know what it works out to, but it's like 00:23:56.650 --> 00:24:02.430