WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:05.580 --> 00:00:10.360 Live from Utrecht, this is the Van Wirdum Sjorsnado. Hello. Hello. Hello. 00:00:10.780 --> 00:00:11.080 Hello. 00:00:11.580 --> 00:00:14.220 Hello. Hello. Ruben, welcome back. 00:00:14.560 --> 00:00:15.580 Thank you. Good to be back. 00:00:15.800 --> 00:00:20.580 We're going to discuss DriveChains today, and you are our in-house DriveChain expert. 00:00:20.820 --> 00:00:24.100 Well, I'm not quite Paul Sztorc, but I'll try my best. 00:00:25.240 --> 00:00:26.260 Sztorc Substitute. 00:00:26.580 --> 00:00:31.280 Yeah, you've designed your own sidechain type of solution, so you're at least 00:00:31.280 --> 00:00:33.660 sort of thinking about this kind of stuff on a regular basis. 00:00:33.840 --> 00:00:35.960 That is true, yeah. I've done a lot of thinking about this. 00:00:36.340 --> 00:00:37.800 So you're going to help us out today? 00:00:39.050 --> 00:00:39.110 Yep. 00:00:39.210 --> 00:00:43.610 Okay, well, so DriveChain episode. That obviously means we're going to spend most 00:00:43.610 --> 00:00:47.050 of the episode complaining about how Bitcoin Core doesn't want to make any 00:00:47.050 --> 00:00:47.510 changes. 00:00:47.850 --> 00:00:48.690 Yep, absolutely. 00:00:50.470 --> 00:00:54.810 That's a joke. I actually really like Paul. He's one of my favorite people to 00:00:54.810 --> 00:00:57.990 listen to, but he does go on tangents sometimes. 00:00:59.020 --> 00:01:03.280 Yeah, hopefully we'll be able to kind of give a different perspective from Paul's 00:01:03.280 --> 00:01:06.980 perspective. I think it's always good to hear multiple explanations from multiple 00:01:06.980 --> 00:01:10.440 people. So this hopefully helps people to understand drive chains more deeply. 00:01:10.720 --> 00:01:14.800 Okay, so let's get into it. First of all, so drive chains are a type of side 00:01:14.800 --> 00:01:19.480 chains. We've already discussed side chains on this podcast, I think twice now. 00:01:19.760 --> 00:01:25.500 But nevertheless, let's very briefly mention the benefits of side chains. Do you 00:01:25.500 --> 00:01:26.520 want to go? Yeah, Ruben. 00:01:26.680 --> 00:01:31.910 Okay, yeah. Basically, this is a two-way pegged sidechain, meaning that you can 00:01:31.910 --> 00:01:36.150 actually move Bitcoins in and out of this chain. Chain itself kind of runs 00:01:36.150 --> 00:01:39.890 completely separately. So there's no attachment in terms of consensus or anything 00:01:39.890 --> 00:01:44.470 like that. So you can either run the Bitcoin blockchain and the sidechain or just 00:01:44.470 --> 00:01:47.990 the Bitcoin blockchain. But anyone who wants to run the Bitcoin blockchain does 00:01:47.990 --> 00:01:52.940 not have to necessarily care about the sidechain unless they want to use it. And 00:01:52.940 --> 00:01:56.700 the kind of nice thing about this is that you can have any kind of chain with any 00:01:56.700 --> 00:02:00.420 kind of consensus rules. You could have an Ethereum chain, you could have a Zcash 00:02:00.420 --> 00:02:04.880 chain, anything like that. And now you can move your Bitcoins to it and do 00:02:04.880 --> 00:02:06.820 whatever you want with it and then move back to Bitcoin again. 00:02:07.180 --> 00:02:11.020 Yeah, so DriveChain is more of a concept of a sidechain. It's not a specific 00:02:11.020 --> 00:02:16.920 sidechain. It's a way to do sidechains. And they have, I think, two sort of 00:02:16.920 --> 00:02:22.470 test net sidechains right now. One of them is like the big block. Or is it even 00:02:22.470 --> 00:02:24.130 testnet? I think so, right? Yeah, it must be. 00:02:24.410 --> 00:02:27.350 They are definitely tested there. There are no real bitcoins on there as of right now. 00:02:27.690 --> 00:02:30.970 So one, they have a big block version and they have a Zcash version. 00:02:31.030 --> 00:02:32.270 Yeah, that's what I believe. 00:02:32.510 --> 00:02:36.930 I think back in 2017, I briefly experimented with the version of drive chains 00:02:36.930 --> 00:02:40.530 they had then and tried to make like a gigabyte chain just to see what would 00:02:40.530 --> 00:02:45.150 happen. I started messing with the consensus code and it was really difficult, as 00:02:45.150 --> 00:02:49.380 you can imagine. And I actually found... Not a bug, but like a lacking thing in 00:02:49.380 --> 00:02:53.520 the test suite for it that was making it really hard to debug. And I made a pull 00:02:53.520 --> 00:02:56.920 request to Bitcoin Core. And that's actually how I got massively distracted into 00:02:56.920 --> 00:02:59.820 contributing to Bitcoin Core and didn't pay attention to the drive chains anymore. 00:02:59.980 --> 00:03:00.580 Oh, wow, really? 00:03:00.840 --> 00:03:01.380 That's just a little backstory. 00:03:02.420 --> 00:03:02.980 That's crazy. 00:03:03.080 --> 00:03:08.540 Right. But anyways, to sum it up, so a sidechain, including drive chains, are a 00:03:08.540 --> 00:03:13.390 way to use Bitcoin on a different blockchain with different rules. Yeah. Another 00:03:13.390 --> 00:03:17.210 benefit I want to mention, because this is something Paul likes to mention, is 00:03:17.210 --> 00:03:22.660 that on the sidechain users still pay fees. 00:03:23.120 --> 00:03:28.440 And these fees would ultimately go to Bitcoin miners, which arguably helps 00:03:28.440 --> 00:03:29.760 security of the Bitcoin network. 00:03:30.100 --> 00:03:35.260 Yeah, and that's specific to the way that Paul suggests doing consensus for drive 00:03:35.260 --> 00:03:39.380 chains, for these separate blockchains. And that's through blind merged mining, 00:03:39.500 --> 00:03:42.900 which we also did an episode about blind merged mining in a perpetual one-way 00:03:42.900 --> 00:03:48.880 peg. And so in that specific proposal, any type of merged mining really, the fees 00:03:48.880 --> 00:03:51.940 would go to the Bitcoin miners. Theoretically, you could also do it as a 00:03:51.940 --> 00:03:55.560 completely separate proof of work consensus mechanism. And then the fees wouldn't 00:03:55.560 --> 00:04:00.500 necessarily go to the Bitcoin miners, but just the person who mines the sidechain. 00:04:00.980 --> 00:04:06.680 Right. Yeah, I think for DriveChain, there are two main innovations, two main 00:04:06.680 --> 00:04:12.540 proposals, which are BIPs 300 and 301. One of them is 00:04:12.540 --> 00:04:16.900 merged mining, and the other one is the pegging in, pegging out mechanism. 00:04:17.660 --> 00:04:22.540 Yeah, 301 is blind merged mining, and 300 is the pegging out mechanism mainly. 00:04:22.700 --> 00:04:23.700 Yeah, and pegging in, I guess, yeah. 00:04:23.940 --> 00:04:29.840 Right, so should we discuss the blind merged mining part? We already covered 00:04:29.840 --> 00:04:32.620 it in previous episodes, but I think it's worth at least sort of... A little 00:04:32.620 --> 00:04:35.920 recap. Yeah, a little recap. Who wants to give it a go? 00:04:36.860 --> 00:04:41.800 Yeah, so the idea of blind merge mining, let's first say the idea of merge 00:04:41.800 --> 00:04:47.480 mining, right, is that a Bitcoin miner also mines another chain and then they put 00:04:47.480 --> 00:04:50.320 something in the Bitcoin chain to indicate that they've mined that other chain. 00:04:51.200 --> 00:04:56.240 And this means that the Bitcoin miner has to run software for Bitcoin as well as 00:04:56.240 --> 00:05:00.880 this other chain. And the problem with that is that let's say these sidechains 00:05:00.880 --> 00:05:06.520 become really profitable. Then because miners are competing, then every miner has 00:05:06.520 --> 00:05:11.340 to essentially run all these nodes for all these sidechains. And that means they 00:05:11.340 --> 00:05:14.480 have to do a lot of validation work. And that's exactly what we want to prevent, 00:05:14.680 --> 00:05:15.440 basically. 00:05:16.020 --> 00:05:16.220 Why? 00:05:16.400 --> 00:05:21.320 Well, because we want miners to be able to... be in very bad circumstances, say, 00:05:21.460 --> 00:05:25.700 behind a Tor node in the middle of nowhere on the moon, and still be able to 00:05:25.700 --> 00:05:28.700 produce blocks without getting orphaned and without having to download terabytes 00:05:28.700 --> 00:05:34.160 of data from Earth. Right. So what Blind Merge Mining tries to solve this problem 00:05:34.160 --> 00:05:39.260 by saying, well, dear miner, just put this hash in the blockchain, and it could 00:05:39.260 --> 00:05:43.740 either be in the coinbase or some other way. And if you do that, you don't have 00:05:43.740 --> 00:05:46.640 to care what that hash means. Just put it in there and we'll give you some money 00:05:46.640 --> 00:05:50.920 to do that. That's the essence of blind merge mining. So that means the miners in 00:05:50.920 --> 00:05:54.660 theory do not have to check anything on these other chains. And so it would not 00:05:54.660 --> 00:05:56.600 drive up the cost for miners. 00:05:57.800 --> 00:06:01.460 Yeah, I have nothing to add to that. I think that's exactly right. So specific to 00:06:01.460 --> 00:06:06.620 drive chains, it's via the Coinbase. So it's kind of a specialized soft fork in 00:06:06.620 --> 00:06:12.060 order to implement this blind merge mining mechanism. It's not necessary to use 00:06:12.060 --> 00:06:16.130 it for drive chains. You could also use it for other types of chains. And it's 00:06:16.130 --> 00:06:21.150 very similar to my blind merge mining proposal, which is, in a sense, it's a 00:06:21.150 --> 00:06:25.250 derivative of what Paul Sztorc's work. But the difference is there that you don't 00:06:25.250 --> 00:06:27.090 really need a specialized soft fork, so that's nice. 00:06:27.270 --> 00:06:30.610 So why does Paul's version require a soft fork? 00:06:30.790 --> 00:06:36.210 Well, technically, it no longer does, because he could utilize my work. 00:06:36.450 --> 00:06:39.990 Without making it more complicated, let's assume he cannot utilize your work, 00:06:40.050 --> 00:06:41.330 which also requires a soft fork. 00:06:41.570 --> 00:06:46.670 yeah well yeah it requires a yeah non-specialized soft fork so at least you don't 00:06:46.670 --> 00:06:50.670 you don't need to change anything about Bitcoin consensus specifically for 00:06:50.670 --> 00:06:52.030 enabling blind merged mining 00:06:52.460 --> 00:06:56.660 Yeah, what I liked about the current version of that BIP proposal is that it 00:06:56.660 --> 00:07:02.100 allows sidechains to propose blocks to Bitcoin miners. So essentially you have 00:07:02.100 --> 00:07:05.220 people on the sidechain who want to see a new block in the sidechain and they 00:07:05.220 --> 00:07:09.660 give a hash to the Bitcoin miners. But they can offer multiple, I think multiple 00:07:09.660 --> 00:07:14.200 sidechain miners can offer blocks to various Bitcoin miners in a sort of an 00:07:14.200 --> 00:07:19.360 auction process. And without like going into too much of the game theory. One 00:07:19.360 --> 00:07:22.540 interesting aspect of that is that you could use Lightning or a slightly modified 00:07:22.540 --> 00:07:26.000 version of Lightning to do this. Because the nice thing about Lightning is that 00:07:26.000 --> 00:07:30.460 you can do atomic trades. Essentially, you can say, okay, if you mine this block, 00:07:30.620 --> 00:07:35.580 for if you mine this hash for me, then I'm going to give you money. And the way 00:07:35.580 --> 00:07:40.720 they do that here is, I think they're saying that if this sidechain block appears 00:07:40.720 --> 00:07:45.250 in the Bitcoin blockchain, then I'm going to give you money. And so that does 00:07:45.250 --> 00:07:48.290 require a soft fork because normally what you do with Lightning is you're saying, 00:07:48.410 --> 00:07:52.410 if you reveal the secret to me, I'm going to give you the money. Or if you reveal 00:07:52.410 --> 00:07:57.150 the secret to the blockchain, the money is mine, essentially. But the problem 00:07:57.150 --> 00:08:01.570 with revealing a secret is, well, somebody could mine a block and then the secret 00:08:01.570 --> 00:08:05.230 is revealed because the block exists and it has a secret in it. But now the block 00:08:05.230 --> 00:08:09.680 gets re-orged. So if you want to incentivize miners to make sure that block does 00:08:09.680 --> 00:08:13.720 not get reorg'd, then it's not enough to just reveal a secret because the secret 00:08:13.720 --> 00:08:17.840 can't be disappeared again when there's a reorg. The secret is just known. So the 00:08:17.840 --> 00:08:22.120 soft fork would consist of something like saying, does this thing exist in the 00:08:22.120 --> 00:08:22.600 coinbase? 00:08:24.140 --> 00:08:28.480 So it has to be some sort of check to see some sort of state in the Coinbase. 00:08:28.860 --> 00:08:34.200 Yeah. So does this also mean... that on the drive chain, side chain, there would 00:08:34.200 --> 00:08:38.320 only be one block for each Bitcoin block? One block every 10 minutes, basically? 00:08:38.560 --> 00:08:43.160 Yeah, so there could be multiple drive chains, right? So there could be multiple 00:08:43.160 --> 00:08:46.640 blocks for every drive chain, but for every drive chain, there can only be one 00:08:46.640 --> 00:08:48.780 block per Bitcoin block. I see. Yeah. 00:08:49.130 --> 00:08:52.490 Yeah, I mean, you could probably have blocks in between, but they just wouldn't 00:08:52.490 --> 00:08:56.490 be enforced by Bitcoin consensus. So they probably wouldn't be very valuable. 00:08:57.170 --> 00:09:01.190 Yeah, you'd have to have some. I mean, theoretically, there are ways probably to 00:09:01.190 --> 00:09:04.030 get that to happen. Well, that's what RSK 00:09:04.030 --> 00:09:08.820 does. RSK sort of uses the same strategy as Bitcoin mining pool where there are 00:09:08.820 --> 00:09:10.700 sort of almost blocks that count. 00:09:10.820 --> 00:09:13.560 But to really have it enforced, the sidechain would probably need proof of work 00:09:13.560 --> 00:09:18.100 itself to have at least some security on those intermediate blocks. But then the 00:09:18.100 --> 00:09:22.780 reason why Bitcoin has 10-minute blocks is because otherwise the orphan rate gets 00:09:22.780 --> 00:09:26.480 too high. So I don't think there's much utility in having faster blocks. 00:09:26.720 --> 00:09:32.610 So specific to RSK, they use a federation, right? the federation can sign 00:09:32.610 --> 00:09:37.090 blocks faster and then every 10 minutes you kind of checkpoint in whatever the 00:09:37.090 --> 00:09:39.850 federation signed in the past 10 minutes into the Bitcoin blockchain and then it 00:09:39.850 --> 00:09:43.910 becomes irreversible so it's sort of it's sort of like a level of security that 00:09:43.910 --> 00:09:47.430 you have right where it first the federation signs and then you assume eventually 00:09:47.430 --> 00:09:51.070 it appears in the Bitcoin blockchain and yeah you can take that as already having 00:09:51.070 --> 00:09:53.210 consensus as soon as the federation signs essentially 00:09:53.790 --> 00:09:57.110 Yeah, but if we don't want federations, which I think in the Drivechain concept, 00:09:57.230 --> 00:10:02.070 we don't. You need something. But to be clear, the BIP 301 about blind merge 00:10:02.070 --> 00:10:06.630 mining suggests one approach that uses Lightning that... I think clearly requires 00:10:06.630 --> 00:10:10.030 a soft fork, and I think Paul also agreed on that. Yeah. But they describe other 00:10:10.030 --> 00:10:13.890 mechanisms to do this type of auctioning, where basically the game is, if you 00:10:13.890 --> 00:10:18.330 create a block for me, then here's some money. And I guess there's various ways 00:10:18.330 --> 00:10:21.150 of doing it, but you probably need some way to prove that something exists in a 00:10:21.150 --> 00:10:26.890 block. So either a way to verify a Merkle proof or something else. But 00:10:26.890 --> 00:10:30.330 that itself would be a generic soft fork, right? Being able to verify a Merkle 00:10:30.330 --> 00:10:35.340 proof. Yeah. So the BIP is a bit short on details. I'm just going to... say that. 00:10:35.560 --> 00:10:39.660 Yeah, fair enough. It's also a bit of an implementation detail though, isn't it? 00:10:39.820 --> 00:10:41.280 Like this is a solvable thing? 00:10:41.500 --> 00:10:45.860 No, it's not. Because the problem with a lot of these concepts, we have this 00:10:45.860 --> 00:10:49.340 issue with, and this is not really comparable, but I just want to illustrate a 00:10:49.340 --> 00:10:52.280 point. You had Vitalik pitching quantum computer simulators. 00:10:53.620 --> 00:10:54.720 That sounds brilliant. 00:10:55.000 --> 00:10:59.640 Yes. But the details really, really matter because you can give yourself the 00:10:59.640 --> 00:11:02.820 illusion that you've solved the problem, but actually you have shoved the problem 00:11:03.200 --> 00:11:07.140 somewhere in a corner that you call implementation detail. But then if you go 00:11:07.140 --> 00:11:11.400 into that little corner implementation detail, you get confronted with the 00:11:11.400 --> 00:11:15.920 original problem again. Same with the Oracle problem that a lot of other chains 00:11:15.920 --> 00:11:19.920 have. They think, oh, we solved the Oracle problem. But there are still some 00:11:19.920 --> 00:11:23.980 implementation details left. And it's like, oh, crap. Actually, we have not 00:11:23.980 --> 00:11:27.100 solved the Oracle problem. So, no, I would not say that the lacking details 00:11:27.100 --> 00:11:30.460 matter. But they have implemented some of this stuff, I think. Just not the 00:11:30.460 --> 00:11:31.040 lightning variant. 00:11:31.220 --> 00:11:36.080 I think it depends on the situation, right? And at least my feeling here is that 00:11:36.080 --> 00:11:39.940 the implementation details are not going to get in the way of whether or not this 00:11:39.940 --> 00:11:41.560 works. But, yeah, maybe I'm wrong. 00:11:41.920 --> 00:11:45.520 You may be right, especially because there are multiple proposals for blind merge 00:11:45.520 --> 00:11:47.380 mining that could all be fit into this puzzle. 00:11:47.740 --> 00:11:53.160 Yeah, I think that's what I was getting at. Personally, I think the other part of 00:11:53.160 --> 00:11:56.620 the drive chain proposal is actually the more interesting one. So the important 00:11:56.620 --> 00:12:00.920 thing is, for listeners that don't know this, the coins on the drive chain, on 00:12:00.920 --> 00:12:04.420 the side chain, are supposed to have the same value as Bitcoin. And for that, 00:12:04.560 --> 00:12:08.680 it's necessary that you can move the coins to the side chain as well as back. 00:12:08.860 --> 00:12:09.300 Exactly. 00:12:09.460 --> 00:12:11.280 And that's sort of the trick of drive chain. 00:12:11.440 --> 00:12:15.660 Yes, because the last time we talked about blind merge mining and side chain, we 00:12:15.660 --> 00:12:20.810 had this... perpetual one-way peg, which, you know, proof of pain or other terms 00:12:20.810 --> 00:12:24.710 of use for it, the money would basically go into the sidechain, but it would 00:12:24.710 --> 00:12:28.950 never come back. And that, you know, we talked about that in some length there. I 00:12:28.950 --> 00:12:32.330 see that as problematic. Other people see maybe it's possible. At the very least, 00:12:32.450 --> 00:12:35.810 I mean, at the very least, it's very limiting, right? Like the drive chain's 00:12:35.810 --> 00:12:41.280 concept is just superior in terms of functionality. So definitely. If you have a 00:12:41.280 --> 00:12:44.760 secure way of moving your Bitcoins back to the Bitcoin blockchain, that's really, 00:12:44.780 --> 00:12:45.780 yeah, the best thing. 00:12:46.240 --> 00:12:50.620 Yeah. So I guess maybe we want to quickly do a high level view again, because now 00:12:50.620 --> 00:12:54.260 I think I get it. There's two things you want to do with a good side chain. One 00:12:54.260 --> 00:12:57.260 is you want to be able to produce blocks and like recognize which blocks are 00:12:57.260 --> 00:13:01.940 official. That's what blind merge mining does. And the other is move coins in and 00:13:01.940 --> 00:13:07.860 out of that specific side chain. And that is what this other BIP that we're 00:13:07.860 --> 00:13:12.070 going to talk about, the hash rate escrow. does those two separate things 00:13:12.070 --> 00:13:13.510 yes and 00:13:13.510 --> 00:13:17.570 yeah that's definitely kind of the the key part of sidechains moving your coins 00:13:17.570 --> 00:13:22.610 into a sidechain is easy it's just freezing your coins or or like my proposal 00:13:22.610 --> 00:13:23.470 burning your coins 00:13:23.470 --> 00:13:26.050 essentially just sending it to a Bitcoin address 00:13:26.050 --> 00:13:31.130 sending it to a Bitcoin address yeah that is the question then is when are these 00:13:31.130 --> 00:13:33.830 bitcoins going to be spendable again and that's the peg out 00:13:34.520 --> 00:13:37.800 Yes, you mean when are they going to be spendable on the Bitcoin blockchain again? 00:13:38.000 --> 00:13:38.240 Yes. 00:13:38.420 --> 00:13:42.940 So you send them to an address. At that point, everyone knows, okay, now these 00:13:42.940 --> 00:13:45.960 coins are really on the sidechain, so they cannot move on the Bitcoin blockchain. 00:13:46.400 --> 00:13:50.880 And then at some point, when you're done on the sidechain, you should be able to 00:13:50.880 --> 00:13:54.080 lock them on the sidechain or burn them there or whatever. And then they should 00:13:54.080 --> 00:13:56.280 be movable on the Bitcoin blockchain again. 00:13:56.440 --> 00:14:00.870 Yeah, and that's really the key, right? How does the Bitcoin blockchain know? Who 00:14:00.870 --> 00:14:06.070 owns the coins on the sidechain, on the drivechain? And are these coins that 00:14:06.070 --> 00:14:09.910 are... Somebody's suggesting, hey, I'm going to spend these Bitcoins that were on 00:14:09.910 --> 00:14:12.210 the sidechain and they're unfrozen again. 00:14:12.390 --> 00:14:15.950 Yeah, now I'm going to send them to my own cold storage. Yeah. And then how 00:14:15.950 --> 00:14:19.970 does... Bitcoin blockchain know that this is a valid transaction, that this is allowed. 00:14:20.290 --> 00:14:23.350 And there is a naive way of doing it, which is, I think, good to point out, which 00:14:23.350 --> 00:14:27.790 is that everybody who runs Bitcoin also runs the sidechain. But if you do that, 00:14:27.970 --> 00:14:30.690 it's not really a sidechain. The whole point of the sidechain is that you can 00:14:30.690 --> 00:14:34.730 separate the two and you don't have to run both. So then we're violating really 00:14:34.730 --> 00:14:38.450 the core principle and it becomes more like a block size increase. So we want to 00:14:38.450 --> 00:14:38.970 avoid that. 00:14:39.110 --> 00:14:41.470 Well, worse than a block size increase, because we've just said we can have 00:14:41.470 --> 00:14:45.470 arbitrary rules on that sidechain. So we have a block size increase and a rule 00:14:45.470 --> 00:14:46.450 complexity increase. 00:14:46.670 --> 00:14:50.370 Yeah, I mean, generally, I guess people call that an extension block, right? 00:14:50.390 --> 00:14:54.770 That's roughly the same proposal where you have a separate space inside of the 00:14:54.770 --> 00:14:56.790 Bitcoin blockchain that can have different rules. 00:14:57.190 --> 00:14:59.970 Yeah, you have multiple, I guess, ways of looking at it. But if you consider 00:14:59.970 --> 00:15:02.110 SegWit an extension block, I guess in that direction. 00:15:02.330 --> 00:15:03.350 Yeah, I don't, but yeah. 00:15:03.530 --> 00:15:06.670 Okay, but then SegWit has to really... 00:15:06.670 --> 00:15:07.510 We're getting off the rails. 00:15:08.290 --> 00:15:08.650 Sorry. 00:15:09.250 --> 00:15:13.570 Back to the rails. Yes. yeah so the idea of a sidechain is that the people who 00:15:13.570 --> 00:15:17.030 want to use the sidechain can use the sidechain and the people that don't want to 00:15:17.030 --> 00:15:21.470 use the sidechain don't need to care about the sidechain still somehow the coins 00:15:21.470 --> 00:15:25.810 must only move on the Bitcoin blockchain when the legitimate owner of the 00:15:25.810 --> 00:15:30.350 sidechain says they should move yeah and not everyone on the Bitcoin blockchain 00:15:30.350 --> 00:15:34.370 knows who's the legitimate owner or any of these details okay so ruben how is 00:15:34.370 --> 00:15:34.850 this solved 00:15:34.850 --> 00:15:40.550 hash rate escrow so that's the way paul calls it in BIP 300 essentially 00:15:40.550 --> 00:15:46.100 there is a very simple rule that says you give your money to the miners and the 00:15:46.100 --> 00:15:51.960 miners can spend it but very slowly over the course of three to six months 00:15:51.960 --> 00:15:56.950 the Bitcoin miners are going to vote on whether or not they want to allow 00:15:56.950 --> 00:16:02.750 one of these transactions to be spent. So let's say I come out of a sidechain 00:16:02.750 --> 00:16:06.470 and I send a transaction to the Bitcoin blockchain. I say, hey, I want to spend 00:16:06.470 --> 00:16:10.660 this UTXO that came from a specific drive chain. then the miners can say like, 00:16:10.760 --> 00:16:14.440 okay, well, we're going to vote on it. And every time a miner creates a block, it 00:16:14.440 --> 00:16:19.240 says, okay, sure, yeah, this is a valid pegout. And after three months or six 00:16:19.240 --> 00:16:23.560 months, if half, roughly half of the miners have said, yes, this is a valid 00:16:23.560 --> 00:16:25.800 pegout, then I get my coins. 00:16:26.280 --> 00:16:32.020 Well, I think, so miners can do three things. Miners can vote in favor 00:16:32.020 --> 00:16:33.100 of the transaction. 00:16:33.400 --> 00:16:33.580 Yeah. 00:16:34.040 --> 00:16:38.080 They can ignore it. Or they can vote against it. 00:16:38.320 --> 00:16:38.460 Yeah. 00:16:38.640 --> 00:16:40.960 So if it's like half-half, it's going to take forever. 00:16:41.460 --> 00:16:46.020 Yeah, theoretically it can be worse, right? Because if you have like... You have 00:16:46.020 --> 00:16:51.240 to have 50% yes votes, but every no vote... brings you back again so yeah so 00:16:51.240 --> 00:16:53.060 definitely you need like yeah there 00:16:53.060 --> 00:16:56.140 can be multiple competing peg out transactions right so what happens is the 00:16:56.140 --> 00:17:01.340 sidechain miner or whoever proposes says hey i'd like to move these coins back to 00:17:01.340 --> 00:17:05.220 the Bitcoin blockchain and another one does another proposal and then miners 00:17:05.220 --> 00:17:09.380 start voting on those and presumably they would take whatever is most favorable 00:17:09.380 --> 00:17:13.780 for them but they also want to make sure it's not violating the rules of the 00:17:13.780 --> 00:17:14.280 sidechain 00:17:14.280 --> 00:17:17.900 yeah i don't want to immediately dive into the catch-22 here but yeah let's go 00:17:17.900 --> 00:17:23.670 into this process a little bit more. First of all, let's say 100% of miners agree 00:17:23.670 --> 00:17:26.430 with the transaction. How long is it going to take in that case? 00:17:26.510 --> 00:17:29.930 In that case, it only takes three months. If everybody votes, yes. 00:17:30.510 --> 00:17:34.550 And then if it's like half of the miners and the other half doesn't care, then it 00:17:34.550 --> 00:17:38.670 takes about six months. And if it's like half of the miners vote in favor and 00:17:38.670 --> 00:17:40.250 half against, then it's going to take forever. 00:17:40.590 --> 00:17:44.870 Anything worse than that, the peg-out just becomes invalidated. After six months, 00:17:45.150 --> 00:17:46.010 you're done. 00:17:46.370 --> 00:17:46.650 Right. 00:17:46.910 --> 00:17:52.290 So what percentage of miners can block this? It's always a majority, right? That 00:17:52.290 --> 00:17:52.990 can make this happen. 00:17:53.170 --> 00:17:57.670 Yeah, because there's always the possibility of re-orging the Bitcoin blockchain. 00:17:57.890 --> 00:18:00.630 So no votes can be re-orged out by 51% of the miners. 00:18:02.030 --> 00:18:06.890 In any case, 51% of the miners can always make a pegout go through, regardless of 00:18:06.890 --> 00:18:10.970 this mechanism. But if you assume there's not going to be any Bitcoin reorgs, 00:18:11.410 --> 00:18:14.670 then you need, it depends on how many no votes there are, right? For every no 00:18:14.670 --> 00:18:17.690 vote, you need a yes vote, and you need 50% yes votes. 00:18:18.150 --> 00:18:19.850 Okay, my math is not that amazing. 00:18:21.130 --> 00:18:21.870 Hopefully I'm right. 00:18:23.590 --> 00:18:27.070 Another thing that was in the BIP that maybe we should mention is that how do you 00:18:27.070 --> 00:18:30.810 even make these drive chains? Or do we want to go somewhere else first? 00:18:31.690 --> 00:18:36.630 Yeah, let's go somewhere else first. Okay, first question, Ruben. Why wouldn't 00:18:36.630 --> 00:18:42.550 miners just steal the coins for themselves? I think that's the main question, right? 00:18:42.550 --> 00:18:46.470 That's the question we've been kind of ignoring up until now, which is definitely 00:18:46.470 --> 00:18:51.830 the big question here. So the main reason why drive chains would work really all 00:18:51.830 --> 00:18:57.410 depend on this argument, which is that... Miners should want the 00:18:57.410 --> 00:19:02.350 sidechain to exist because they get fees from it and because the value of Bitcoin 00:19:02.350 --> 00:19:05.530 itself goes up in value if there are all these sidechains out there that people 00:19:05.530 --> 00:19:06.090 can use. 00:19:07.530 --> 00:19:13.110 We need miners to want the chain to exist and to want to basically give people 00:19:13.110 --> 00:19:17.190 their pegouts when they ask for it. Other than that, there is no reason. So it's 00:19:17.190 --> 00:19:21.310 really a question of incentives. And if the incentives are aligned, the sidechain 00:19:21.310 --> 00:19:24.690 gets to exist. If the incentives are not aligned, the sidechain just dies. 00:19:24.910 --> 00:19:28.490 And I guess this also creates two things. This creates a collective action 00:19:28.490 --> 00:19:32.580 problem, I think. Because you might have one miner that says, I don't care about 00:19:32.580 --> 00:19:35.780 this sidechain and I don't care about the future, so I'm going to take the most 00:19:35.780 --> 00:19:40.100 money, even if that's an illegal transaction. Yeah, no, that's, I think, the 00:19:40.100 --> 00:19:45.900 collective action problem, right? So if a majority of miners do feel that these 00:19:45.900 --> 00:19:48.840 sidechains are worth keeping around for the long term, they're not going to take 00:19:48.840 --> 00:19:52.460 the short-term profit of theft. And they're going to punish other miners who do 00:19:52.460 --> 00:19:55.820 try to do that. Or not punish, but at least they're going to actively vote 00:19:55.820 --> 00:19:59.320 against that type of behavior. Because you might have a situation where in the 00:19:59.320 --> 00:20:04.220 beginning, say only 1% of the miners care. In the beginning, there's not enough 00:20:04.220 --> 00:20:07.460 money at all. So maybe no miner does anything with the sidechain stuff. Then 00:20:07.460 --> 00:20:11.240 there's enough fees out there that some miners will start flagging this thing 00:20:11.240 --> 00:20:14.500 because they would like to have that other revenue. Then other miners might just 00:20:14.500 --> 00:20:18.160 passively copy whatever those first miners are doing because they would like the 00:20:18.160 --> 00:20:23.680 extra free revenue. Why not? Then at some point, somebody starts cheating. And 00:20:23.680 --> 00:20:28.120 then one miner starts cheating or starts cooperating with the cheat, either 00:20:28.120 --> 00:20:32.540 deliberately or accidentally because he's not checking. So then the game develops 00:20:32.540 --> 00:20:33.000 from there. 00:20:33.200 --> 00:20:38.200 Yeah. The question then kind of becomes, how do these Bitcoin miners make sure 00:20:38.200 --> 00:20:42.480 that the peg-outs that they're choosing are correct or not? And this is kind of a 00:20:42.480 --> 00:20:48.060 mechanism that is not really explicitly laid out, but essentially the idea is 00:20:48.060 --> 00:20:53.040 that... The Bitcoin miners want to do the right thing. They want the chain to 00:20:53.040 --> 00:20:56.580 exist. That's our assumption. And if there is some kind of pegout, they're being 00:20:56.580 --> 00:21:00.300 lazy and they're moving a pegout forward that's not supposed to be moved forward, 00:21:00.620 --> 00:21:04.800 then presumably somebody will talk to the miner and say like, hey, what you're 00:21:04.800 --> 00:21:08.340 doing is incorrect. Please go and check. And the first check that they can do is 00:21:08.340 --> 00:21:12.240 an SPV check. So they can take the drive chain and they can just download the 00:21:12.240 --> 00:21:17.300 headers. And inside of the header is also contained the pegout transaction. So 00:21:17.300 --> 00:21:22.660 you get an SPV proof of whether the pegout is valid or not. So this is not a 00:21:22.660 --> 00:21:28.300 guarantee, but it means that 51% of the miners off the drive chain, they think 00:21:28.300 --> 00:21:32.500 that the pegout is valid. And then if that's not good enough, they would have to 00:21:32.500 --> 00:21:35.820 go and basically run the full drive chain and check. 00:21:36.020 --> 00:21:41.860 But this would require on someone telling the miner that something's up. So it's 00:21:41.860 --> 00:21:45.530 not... purely blockchain based in that case someone has to contact them through 00:21:45.530 --> 00:21:47.210 irc or whatever it is 00:21:47.210 --> 00:21:51.890 yeah it's kind of a assumption of good behavior so you're assuming that nothing 00:21:51.890 --> 00:21:55.430 is going wrong and if something is going wrong you're assuming that somebody will 00:21:55.430 --> 00:21:59.730 out there will kind of give you a nudge and be like hey do some extra work here 00:21:59.730 --> 00:22:01.610 because it's not going right 00:22:01.610 --> 00:22:05.130 right but then then the question is what becomes the equilibrium yeah one 00:22:05.130 --> 00:22:09.300 equilibrium could be okay, now all miners have to check all SPV proofs all the 00:22:09.300 --> 00:22:12.860 time because otherwise people will constantly be cheating them because there is 00:22:12.860 --> 00:22:17.780 no cost to cheating. True. Anybody can suggest, I think everybody in the world 00:22:17.780 --> 00:22:22.860 can suggest a transaction that takes all the money out of every single drive 00:22:22.860 --> 00:22:27.300 chain and sends it to them personally. Yeah. And the only cost for that is zero, 00:22:27.320 --> 00:22:30.120 I think. They just broadcast a transaction. Yeah, yeah. Maybe it has to confirm. 00:22:30.840 --> 00:22:35.860 There has to be a, I mean, that action, yeah, the action needs to be in the 00:22:35.860 --> 00:22:38.660 Bitcoin blockchain. So they need to roughly send one transaction to the Bitcoin 00:22:38.660 --> 00:22:39.700 blockchain. So there's 00:22:39.700 --> 00:22:42.660 probably, you know, at least going to be somebody who does that out of, as a 00:22:42.660 --> 00:22:43.260 matter of principle. 00:22:43.640 --> 00:22:46.260 Yeah. Well, the question is, do they get the votes, right? Are the miners going 00:22:46.260 --> 00:22:47.180 to vote on that peg out? 00:22:47.360 --> 00:22:51.460 No, but they're going to, the problem is that the miners, because somebody is 00:22:51.460 --> 00:22:55.200 doing that, they have to do the SPV checking unless they know who this bully is 00:22:55.200 --> 00:22:57.300 and they systematically ignore this, this bully. 00:22:57.620 --> 00:23:02.360 Yeah. If you assume all miners are lazy and they do nothing except for maybe one 00:23:02.360 --> 00:23:06.210 miner out there and that miner is voting on the right thing. and all the other 00:23:06.210 --> 00:23:09.050 miners are just like, oh, let's just follow that guy, then the equilibrium 00:23:09.050 --> 00:23:10.330 actually works out. Okay, 00:23:10.510 --> 00:23:15.530 yeah. If you have one non-lazy miner who actually checks the original chain at 00:23:15.530 --> 00:23:18.630 some level, and the other miners lazily follow, yeah, that could work. 00:23:18.910 --> 00:23:24.090 But yeah, I mean, it's definitely, like, the worst case is that every Bitcoin 00:23:24.090 --> 00:23:28.890 miner is also a DriveChain full node user, and then you get back to the problem 00:23:28.890 --> 00:23:30.910 that you described earlier about the merge mining. 00:23:31.130 --> 00:23:33.950 Yeah, that's what I... Yesterday, I think in the preparation, I called it the 00:23:33.950 --> 00:23:38.210 catch-22. If you get to a situation where every miner has to verify every drive 00:23:38.210 --> 00:23:43.170 chain in detail, not just SPV, we just lost the entire benefit of blind merge 00:23:43.170 --> 00:23:47.090 mining. But it's not guaranteed that that's going to happen, but that is a big concern. 00:23:47.310 --> 00:23:52.530 What happened to the UASF solution? Because I do remember Paul talking about this 00:23:52.530 --> 00:23:58.410 at some point, where if miners tried to steal the coins, then drive chain users 00:23:58.410 --> 00:24:03.660 could deploy a UASF to stop. the coins from moving on the Bitcoin blockchain. 00:24:03.980 --> 00:24:08.160 Yeah, so that is a theoretical possibility, which is good to kind of go through, 00:24:08.320 --> 00:24:12.260 I guess. So it's theoretically possible that miners try to steal all the coins 00:24:12.260 --> 00:24:17.260 from a sidechain that is quite popular. And then all the sidechain users, which 00:24:17.260 --> 00:24:21.660 are also Bitcoin users, they say like, hey, look, miner, if you let this 00:24:21.660 --> 00:24:25.980 transaction go through, we're just going to reject that block that will spend 00:24:25.980 --> 00:24:31.200 this transaction. So don't do that because we're going to basically threaten to 00:24:31.200 --> 00:24:36.200 fork off of Bitcoin. And if you want to keep these users here with the Bitcoin 00:24:36.200 --> 00:24:41.460 blockchain, you got to do what we say. And it's presumably a UASF because. 00:24:41.900 --> 00:24:45.960 Like what we're assuming is kind of similar to the Segwit situation where we 00:24:45.960 --> 00:24:49.300 don't really know whether there's like a majority who's going to enforce this. If 00:24:49.300 --> 00:24:53.420 the majority of the Bitcoin users threatened that, then it would work out. But 00:24:53.420 --> 00:24:57.200 the assumption is that with sidechains, you don't have a majority of users. You 00:24:57.200 --> 00:25:01.040 have all these niches, right? You have all these smaller amounts of users. So 00:25:01.040 --> 00:25:03.320 maybe optimistically you have like 20%. 00:25:03.320 --> 00:25:08.260 And not an intransigent minority either because it's not a sort of randomly 00:25:08.260 --> 00:25:12.700 distributed subset. across all Bitcoin users like you might have with the 00:25:12.700 --> 00:25:18.000 original UASF movement where you don't really know who's going to be resisting it 00:25:18.000 --> 00:25:21.300 but here you know well only the people who actually care about this side chain 00:25:21.300 --> 00:25:24.700