WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:07.250 --> 00:00:10.410 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:10.710 --> 00:00:10.970 Hello. 00:00:11.510 --> 00:00:13.290 Oh my god, who's there? 00:00:13.710 --> 00:00:14.750 A burglar. 00:00:15.550 --> 00:00:17.190 We have another... 00:00:17.600 --> 00:00:18.340 Entity. 00:00:18.440 --> 00:00:21.220 We have another Van Wirdum Sjorsnado with Extra Somsen today. 00:00:21.480 --> 00:00:21.960 That's right. 00:00:22.520 --> 00:00:23.160 Ruben, welcome. 00:00:23.420 --> 00:00:24.020 Welcome back. 00:00:24.360 --> 00:00:25.400 Yeah, glad to be back. 00:00:26.000 --> 00:00:31.620 Guys, first of all, congratulations. As of yesterday, we are 00:00:31.620 --> 00:00:36.540 the number one. In the world of most new corona cases. 00:00:37.460 --> 00:00:42.640 Well done. Even better than the White House? Yes, we're number one. Oh, that's 00:00:42.640 --> 00:00:46.380 amazing. Does anyone want to thank their parents, Ruben? 00:00:46.540 --> 00:00:49.800 I just hope my parents will be safe in these trying times. 00:00:52.810 --> 00:00:55.280 Sjors. I know you're happy with this. 00:00:55.980 --> 00:00:59.420 No, I mean, I could say I told you so, but... 00:00:59.420 --> 00:01:04.240 Yeah, you kind of did, didn't we? Like last week, that was basically... Who could 00:01:04.240 --> 00:01:08.150 have predicted this, right? I don't know. I guess Sjors could have. Okay, let's 00:01:08.150 --> 00:01:10.990 talk Bitcoin. Oh, do you want to add something about Corona, Sjors? 00:01:11.270 --> 00:01:12.570 No, we'll see what happens. 00:01:12.890 --> 00:01:15.870 We'll see what happens. Guys, I forgot to mention something. 00:01:16.110 --> 00:01:16.790 Oh my God. 00:01:17.010 --> 00:01:18.630 I have amazing news. 00:01:18.870 --> 00:01:19.310 Tell me. 00:01:19.450 --> 00:01:20.910 Actually, Sjors, you already know the news. 00:01:21.090 --> 00:01:21.310 I know. 00:01:21.670 --> 00:01:22.030 Ruben. 00:01:22.150 --> 00:01:22.570 What's the news? 00:01:22.850 --> 00:01:26.210 The Van Wirdum Sjorsnado has its own feed now. 00:01:26.450 --> 00:01:26.850 Wow. 00:01:27.170 --> 00:01:30.370 Its own RSS feed and it showed up in my podcast app. 00:01:30.730 --> 00:01:31.070 Excellent. 00:01:31.350 --> 00:01:35.720 So, I'm now subscribed to the Van Wirdum Sjorsnado. If you're listening and if 00:01:35.720 --> 00:01:39.420 you want to hear it for all our episodes, then you can subscribe to the Van 00:01:39.420 --> 00:01:40.040 Wirdum Sjorsnado. 00:01:40.240 --> 00:01:43.280 I'll be subscribing for sure. It's actually exactly what I was asking you guys 00:01:43.280 --> 00:01:46.120 for, like what I was missing. I just wanted to be able to subscribe to your 00:01:46.120 --> 00:01:47.620 podcast specifically. So great. 00:01:48.840 --> 00:01:53.320 That's two subscribers already, Sjors, me and Ruben. That's excellent. We're on the roll. 00:01:53.520 --> 00:01:59.280 I was already subscribed. It's free. Another related news is that we have had our 00:01:59.280 --> 00:02:00.280 first swap cast. 00:02:00.600 --> 00:02:01.600 Oh yeah, that's true. 00:02:01.780 --> 00:02:05.060 Because we actually featured on the Unhashed podcast. 00:02:05.420 --> 00:02:09.280 That's right. Yeah. So sometimes we're getting technical issues or whatever and 00:02:09.280 --> 00:02:14.380 unable to record. And then what we do is we look at other... podcast or something 00:02:14.380 --> 00:02:18.640 where maybe I appear or one of the other guys and we broadcast that. So in this 00:02:18.640 --> 00:02:22.740 case, I came onto your show. So I asked you guys, maybe we can put that on the 00:02:22.740 --> 00:02:26.740 Unhashed podcast. So our Unhashed podcast listeners were also able to listen to 00:02:26.740 --> 00:02:30.620 the last episode. And probably, you know, if, I don't know, a couple of weeks 00:02:30.620 --> 00:02:33.960 from now, we run into issues again, maybe I'll be asking you to air this episode. 00:02:34.860 --> 00:02:37.180 Maybe it'll be number two. Yeah. And 00:02:37.180 --> 00:02:41.100 if you need an extra motivation to check that out, we actually re-edited the 00:02:41.100 --> 00:02:43.260 audio. So it's going to be a little bit better than the original. 00:02:43.420 --> 00:02:43.820 That's correct. 00:02:44.060 --> 00:02:44.160 Check it out. 00:02:44.460 --> 00:02:49.720 All right. I wanted to mention that. Let's talk Bitcoin, Ruben. We're going to 00:02:49.720 --> 00:02:51.460 discuss another of your proposals. 00:02:51.700 --> 00:02:52.060 That's right. 00:02:52.300 --> 00:02:57.280 It's your sidechain proposal, which I'm sure has a very compelling name, which 00:02:57.280 --> 00:02:58.500 I'm forgetting right now. 00:02:58.540 --> 00:03:02.400 Yeah, so it's actually kind of tricky because the word sidechain is very 00:03:02.400 --> 00:03:07.100 overloaded. So I'm not entirely certain whether or not I should be calling it a sidechain. 00:03:07.440 --> 00:03:07.540 Right. 00:03:07.800 --> 00:03:12.460 So generally speaking, these days I call it a blind merge mine chain. And it 00:03:12.460 --> 00:03:15.740 actually is kind of a combination of two mechanisms. So one is blind merge 00:03:15.740 --> 00:03:19.740 mining, which is some kind of process. where you somehow create another 00:03:19.740 --> 00:03:24.740 blockchain via Bitcoin. And the second one is called the perpetual one-way peg, 00:03:24.940 --> 00:03:29.640 which is kind of a method of creating a token on the chain without having some 00:03:29.640 --> 00:03:33.400 kind of speculation aspect where there's going to be a pump and dump, some kind 00:03:33.400 --> 00:03:35.180 of shit coin, avoiding all of that. 00:03:35.440 --> 00:03:41.040 Yeah. And I say, first of all, the reason why you're probably not super 00:03:41.040 --> 00:03:45.440 comfortable calling it a sidechain is because the idea behind the sidechain is 00:03:45.440 --> 00:03:51.120 essentially that you move, bitcoins or coins or something back to bitcoins 00:03:51.120 --> 00:03:56.780 from Bitcoin to an alternative chain where alternative rules apply and then you 00:03:56.780 --> 00:03:58.980 can move it back to the Bitcoin blockchain 00:03:58.980 --> 00:03:59.640 that's right 00:03:59.640 --> 00:04:02.320 and that last step that's actually not possible in your proposal 00:04:02.320 --> 00:04:06.140 that last step is not entirely possible there is some hope that maybe the token 00:04:06.140 --> 00:04:10.340 that's on there is not going to be too far from being worth one Bitcoin so you 00:04:10.340 --> 00:04:12.600 can trade it back and forth but that is not guaranteed at all 00:04:12.600 --> 00:04:18.100 yeah that's kind of the theory which we'll get into in a bit yeah Okay, so it's 00:04:18.100 --> 00:04:23.820 not quite a sidechain, but it has some similar properties. Most obviously, this 00:04:23.820 --> 00:04:29.610 alternative chain can have alternative rules. So Bitcoin has all sorts of 00:04:29.610 --> 00:04:34.210 rules, like a block is found once every 10 minutes and all of the other rules. 00:04:34.410 --> 00:04:39.330 And then with this... Merge mine chain, this alternative chain, you can have 00:04:39.330 --> 00:04:43.610 other rules. For example, you can have more privacy or you can have more smart 00:04:43.610 --> 00:04:49.610 contracting types of capabilities or what are some other nifty 00:04:49.610 --> 00:04:51.330 benefits you see in a chain like this? 00:04:51.490 --> 00:04:55.430 Or you can even have the same rules, but it's just going to be cheaper because 00:04:55.430 --> 00:04:59.310 you do a bunch of transactions on the side chain and then occasionally you make a 00:04:59.310 --> 00:05:02.770 block and that's represented as just one transaction on the Bitcoin side. 00:05:03.020 --> 00:05:08.060 Yeah, cheaper transactions, that's an option. What are other benefits you foresee 00:05:08.060 --> 00:05:09.540 for something like this? Let's talk about that. 00:05:09.780 --> 00:05:14.780 So, I mean, this is, I guess it goes into kind of the use cases. So I would say 00:05:14.780 --> 00:05:18.380 that this kind of chain, so it can be literally any chain, right? So everything 00:05:18.380 --> 00:05:22.080 that altcoins are doing can kind of be done on these blind merged mined chains, 00:05:22.280 --> 00:05:26.680 except the one difference here is that it's not going to be a store of value. If 00:05:26.680 --> 00:05:29.420 you want to store a value, you got to use Bitcoin. But anything else, anything 00:05:29.420 --> 00:05:32.590 that's not storing value, you can do with these chains. And then the question 00:05:32.590 --> 00:05:36.530 kind of becomes, well, what non-store of value use cases are there for other 00:05:36.530 --> 00:05:40.830 chains? And a couple of things have come to mind, mainly colored coins. So that 00:05:40.830 --> 00:05:44.550 would be the main use case, I think. Any person who wants to create some kind of 00:05:44.550 --> 00:05:50.070 token, USD tether, for instance, can issue these on a separate chain. And that is 00:05:50.070 --> 00:05:53.950 preferable to issuing them on top of the Bitcoin blockchain because on the 00:05:53.950 --> 00:05:56.850 Bitcoin blockchain, presumably fees are going to be high. You're going to have to 00:05:56.850 --> 00:05:59.570 compete for block space. But here you have your kind of your separate chain with 00:05:59.570 --> 00:06:03.210 your separate block space. So it's sort of scalable in that sense. 00:06:03.880 --> 00:06:07.420 Could you have like a different monetary policy on a chain like this? 00:06:07.740 --> 00:06:13.580 Well, the idea is generally that you don't really have a token that 00:06:13.580 --> 00:06:18.100 is being issued on this chain. So if you want some monetary policy on there, you 00:06:18.100 --> 00:06:21.360 kind of have to issue a token on there. And if you issue a token on there, you're 00:06:21.360 --> 00:06:25.200 going to reintroduce speculation. So I would say that's kind of a separate thing. 00:06:25.340 --> 00:06:25.740 Okay. 00:06:25.920 --> 00:06:26.680 So no, not really. 00:06:27.020 --> 00:06:28.980 Okay, so let's get into how it works. 00:06:29.220 --> 00:06:32.580 Yeah, especially, I guess we want to start with blind merge mining. 00:06:32.640 --> 00:06:36.880 Yeah, there's two aspects of it. One you just mentioned is one of them is blind 00:06:36.880 --> 00:06:39.120 merge mining. The other is proof of burn. 00:06:39.420 --> 00:06:40.560 Perpetual one-way peg. 00:06:40.960 --> 00:06:43.020 Right, okay. So yeah, merge mining first. 00:06:43.240 --> 00:06:48.730 Yes, yeah. So I guess... Very, very broadly, there are multiple ways of doing 00:06:48.730 --> 00:06:52.970 blind merge mining. And one we're going to be talking about here is kind of a fee 00:06:52.970 --> 00:06:55.110 bidding method of doing blind merge mining. 00:06:55.630 --> 00:06:59.590 So what is merged or merged mining at all or blind or not? 00:06:59.810 --> 00:07:05.110 So yeah, the original merge mining concept is kind of to ask Bitcoin miners to 00:07:05.110 --> 00:07:08.760 add a hash. off some other blockchain while they're hashing Bitcoin's proof of 00:07:08.760 --> 00:07:13.280 work. The word blind kind of adds to it that you don't really need the miners to 00:07:13.280 --> 00:07:17.040 figure out which blocks to add because the original method of regular merge 00:07:17.040 --> 00:07:22.180 mining, the issue was that the miners wouldn't be just checking Bitcoin. They 00:07:22.180 --> 00:07:25.780 would be checking all these other coins as well. And there were some concerns 00:07:25.780 --> 00:07:29.600 with that, that you're maybe overloading miners with too much work, making it 00:07:29.600 --> 00:07:32.740 more expensive to become a Bitcoin miner. So the blind part is kind of important 00:07:32.740 --> 00:07:37.870 in the sense that it allows anyone to create a block, not just miners. And miners 00:07:37.870 --> 00:07:42.170 still have to mine it, but through some mechanism, you're kind of compensating 00:07:42.170 --> 00:07:42.730 them for that. 00:07:43.070 --> 00:07:45.810 Yeah, and to be clear, when you mean block here, you mean a block on this 00:07:45.810 --> 00:07:50.660 alternative chain, on this new chain. Yeah, so... like any blockchain it consists 00:07:50.660 --> 00:07:55.820 of blocks and these blocks are hashed and each hash so each block is then 00:07:55.820 --> 00:08:01.120 included in the Bitcoin blockchain and users of this merged mine sidechain 00:08:01.120 --> 00:08:06.320 they actually check the Bitcoin blockchain to figure out what their own 00:08:06.320 --> 00:08:09.600 blockchain is in a way i'm calling it their own it's you know they're probably 00:08:09.600 --> 00:08:13.750 also Bitcoin users or but you know they're they're They're using the Bitcoin 00:08:13.750 --> 00:08:15.990 blockchain to figure out what the sidechain looks like. 00:08:17.750 --> 00:08:18.370 That's right. 00:08:20.530 --> 00:08:25.470 Concretely, if you're using transactions in this example, as a sidechain user, 00:08:25.670 --> 00:08:28.630 you're checking the Bitcoin blockchain and you're looking for a specific kind of 00:08:28.630 --> 00:08:32.870 transaction. And in that specific kind of transaction, you see a hash. and then 00:08:32.870 --> 00:08:36.610 you take a note of that hash, and then you start syncing your sidechain 00:08:36.610 --> 00:08:40.430 blockchain, and as soon as you see that hash that you were expecting, you're 00:08:40.430 --> 00:08:43.930 like, okay, this is a valid sidechain block. If you see a different hash, you 00:08:43.930 --> 00:08:44.570 just ignore it. 00:08:44.710 --> 00:08:45.290 That's correct. 00:08:45.450 --> 00:08:48.290 Yeah. Well, you're skipping ahead a bit now, Sjors, because that was... 00:08:48.290 --> 00:08:48.410 I'd like to. 00:08:49.310 --> 00:08:50.090 Yes, well... 00:08:50.090 --> 00:08:52.850 It's good. But it was a good explanation. Like, that's basically how you 00:08:52.850 --> 00:08:53.530 construct a blockchain. 00:08:53.770 --> 00:08:57.310 Okay, so where is this hash included then in the Bitcoin blockchain? Right. 00:08:57.630 --> 00:09:01.990 So the mechanism I came up with is kind of an alternative proposal to what Paul 00:09:01.990 --> 00:09:06.690 Sztorc proposed. He had an idea to do blind merged mining, which is related to 00:09:06.690 --> 00:09:12.350 his drive chains idea, which was basically a soft fork that would designate a 00:09:12.350 --> 00:09:17.890 space in Bitcoin's Coinbase to put a hash. And then anyone could kind of pay 00:09:17.890 --> 00:09:23.390 Bitcoins to miners to add their specific hash. to that Coinbase transaction. The 00:09:23.390 --> 00:09:26.450 downside to this proposal was that it would require soft fork. It was very 00:09:26.450 --> 00:09:30.890 specific to drive chains. It was not really a general method. And the method that 00:09:30.890 --> 00:09:31.490 I came up with... 00:09:31.490 --> 00:09:36.710 Hang on. So in drive chain, this hash that we discussed that forms the merge mine 00:09:36.710 --> 00:09:41.470 side chain that is included in the Coinbase transaction, which is the transaction 00:09:41.470 --> 00:09:46.010 that a miner includes in his block to pay himself the block subsidy and the fees. 00:09:46.250 --> 00:09:46.630 That's right. 00:09:46.770 --> 00:09:50.250 So it's included in that hash. That's what Paul Sztorc suggested. 00:09:50.490 --> 00:09:51.010 That's right. 00:09:51.130 --> 00:09:53.830 And you have a different idea. 00:09:54.170 --> 00:09:54.510 Yes. 00:09:54.850 --> 00:09:57.150 It still uses a hash, but it's included somewhere else. 00:09:57.270 --> 00:10:01.910 Exactly, yeah. So my method kind of generalizes that to something that is doable 00:10:01.910 --> 00:10:06.550 without a specific soft fork. It still requires the soft fork, but now we're 00:10:06.550 --> 00:10:12.330 using SIGHASH ANYPREVOUT. Just as an FYI, OP_CTV can also be used for this. So 00:10:12.330 --> 00:10:16.080 either one of those. proposals, if it makes it into Bitcoin as a soft fork, it 00:10:16.080 --> 00:10:17.780 enables what I'm about to talk about. 00:10:17.980 --> 00:10:22.480 Yes, ANYPREVOUT, sorry, ANYPREVOUT we have discussed in episode? 00:10:22.980 --> 00:10:25.120 Not yet. Coming soon, maybe. 00:10:25.360 --> 00:10:28.980 Oh. But we did discuss CTV, or did we? 00:10:29.200 --> 00:10:30.620 No, we've mentioned it. 00:10:30.980 --> 00:10:35.120 Oh, okay. Passing, okay. All right. So, okay. Also future episode. 00:10:35.360 --> 00:10:39.160 So I think it's fine to kind of keep that aspect about it high level, because 00:10:39.160 --> 00:10:44.330 it's not... integral to the idea. It's just what you got to know is that we 00:10:44.330 --> 00:10:48.770 create this string of transactions, one transaction after the other. With one 00:10:48.770 --> 00:10:52.630 input, one output, you're just moving a single Satoshi over every time. We use a 00:10:52.630 --> 00:10:56.770 relative time lock of one block, meaning that only one transaction per block gets 00:10:56.770 --> 00:11:01.950 into the Bitcoin blockchain. And we use that as a framework for other people to 00:11:01.950 --> 00:11:06.730 attach a hash to. So what anyone can do is take one of these transactions, add 00:11:06.730 --> 00:11:12.100 their own inputs and outputs. And with that, include a hash of a block they want 00:11:12.100 --> 00:11:17.460 to mine. And through replace by fee RBF, people can actually outbid each other 00:11:17.460 --> 00:11:22.480 for the privilege of being the one to add their secondary input and output and 00:11:22.480 --> 00:11:26.680 add that hash. And so what we've created is a kind of a fee bidding mechanism 00:11:26.680 --> 00:11:32.640 that kind of exploits or utilizes RBF to allow anyone to include their 00:11:32.640 --> 00:11:35.220 hash and therefore create a block on this other chain. 00:11:35.450 --> 00:11:40.350 right so what we have here is we've created at the at a point where we're 00:11:40.350 --> 00:11:45.910 basically launching this chain we create a whole series of transactions that all 00:11:45.910 --> 00:11:51.310 refer to the previous one right and all of these are unconfirmed they're 00:11:52.370 --> 00:11:58.350 broadcast somehow, but they cannot be included in the blockchain yet because of 00:11:58.350 --> 00:12:00.330 the time lock. Am I saying that right? 00:12:01.330 --> 00:12:05.030 It's a relative time lock of one block, meaning they can be included one at a 00:12:05.030 --> 00:12:09.150 time. And their fee is also zero. So somebody has to add an input and output and 00:12:09.150 --> 00:12:11.910 pay some kind of fee in order to have it appear in the blockchain. 00:12:12.350 --> 00:12:17.150 So if we do this before we launch the sidechain or at the point where we launch 00:12:17.150 --> 00:12:21.420 the sidechain, then how many of these transactions do we create at that? point in time 00:12:21.420 --> 00:12:25.800 yeah so there it is you can create an unlimited amount of transactions but 00:12:25.800 --> 00:12:30.320 everybody has to be aware of these transactions and know them so it is some kind 00:12:30.320 --> 00:12:34.600 of like upfront cost I don't know exactly what it comes down to but you could 00:12:34.600 --> 00:12:38.340 just create 100 years worth of these transactions and ensure that the blockchain 00:12:38.340 --> 00:12:42.220 will live for 100 years and then somewhere before it is 100 years you would have 00:12:42.220 --> 00:12:46.780 to have a hard fork in order to extend the chain beyond that so so it puts a 00:12:46.780 --> 00:12:50.820 limit on there but it's not It's not super, it's not really something that's 00:12:50.820 --> 00:12:52.280 practically going to be an issue. 00:12:52.440 --> 00:12:56.200 And so this is where the magic of SIGHASH ANYPREVOUT comes in, right? Because 00:12:56.200 --> 00:13:00.220 you're saying you've pre-generated all these transactions. Yeah. And so the 00:13:00.220 --> 00:13:03.640 astute listener would say, well, they all have a hash. So how can I change 00:13:03.640 --> 00:13:08.160 anything in that long chain? Because I would break the chain. Right. Well, you 00:13:08.160 --> 00:13:14.100 can do that because SIGHASH ANYPREVOUT allows you. to not refer to a specific 00:13:14.100 --> 00:13:19.180 transaction ID, but instead refer to a specific output script. And so you can 00:13:19.180 --> 00:13:22.580 start adding inputs to that transaction and outputs to the transaction as long as 00:13:22.580 --> 00:13:25.880 that one specific output script is still there. 00:13:26.140 --> 00:13:27.880 Yeah, that's exactly right. Yeah, 00:13:28.380 --> 00:13:33.800 so to put it in layman's terms. Usually, a transaction refers to the previous 00:13:33.800 --> 00:13:38.360 transaction basically as a whole. Through this soft fork, you can have a 00:13:38.360 --> 00:13:43.000 transaction that refers to a small part of a previous transaction, and thereby 00:13:43.000 --> 00:13:47.740 you can change that previous transaction in certain ways. You can add stuff to it. 00:13:47.920 --> 00:13:51.860 Yeah, that's exactly right. Thanks to SIGHASH ANYPREVOUT, it's kind of possible 00:13:51.860 --> 00:13:52.800 to do something like this. 00:13:52.940 --> 00:13:57.480 I think you mentioned this, so sorry for asking again, but does this require... 00:13:57.480 --> 00:14:01.760 ANYPREVOUT, or would it just improve it? Because it sounds like it would really 00:14:01.760 --> 00:14:02.440 require it. 00:14:02.640 --> 00:14:06.820 So either you have SIGHASH ANYPREVOUT, or you use OP_CTV. 00:14:07.000 --> 00:14:09.460 Okay, one of the two you really need. 00:14:09.580 --> 00:14:12.720 And there is a third method that Sjors kind of challenged me on, so I have to 00:14:12.720 --> 00:14:14.880 rethink that, but I think it's still possible. 00:14:16.000 --> 00:14:19.120 He challenged you on that before we started recording, to be clear. 00:14:19.280 --> 00:14:24.280 That's right. But I think it's still possible where you basically just create all 00:14:24.280 --> 00:14:28.480 these transactions ahead of time with a secret key. And then the person who 00:14:28.480 --> 00:14:32.100 creates it throws away the key afterwards, ensuring that these transactions can 00:14:32.100 --> 00:14:36.000 only be spent in one way. You will need kind of a different mechanism to include 00:14:36.000 --> 00:14:39.620 the hash because you can no longer. You no longer want to be able to change the 00:14:39.620 --> 00:14:42.380 transactions. You would have to have like a second output and then somebody 00:14:42.380 --> 00:14:45.940 should spend that second output to add the hash to it. So it would be possible. 00:14:46.080 --> 00:14:50.240 But the downside of that is it's kind of a trusted setup, right? Because there's 00:14:50.240 --> 00:14:53.560 somebody who has a key that they created all these transactions with. You hope 00:14:53.560 --> 00:14:56.340 that he threw away the key, but you're not certain whether or not he did. 00:14:56.480 --> 00:15:01.160 Although the downside is not that severe. So actually I'm not that opposed to 00:15:01.160 --> 00:15:05.260 trying it out before I get one of these soft forks. Because the worst thing that 00:15:05.260 --> 00:15:08.620 can happen is that the chain just halts because some unexpected transaction 00:15:08.620 --> 00:15:13.180 happens. And then it requires some kind of hard fork to get it started again, but 00:15:13.180 --> 00:15:15.480 nobody loses any value. So it's not terrible. 00:15:15.840 --> 00:15:20.260 Okay, let's assume ANYPREVOUT for now. So we've got this chain of transactions 00:15:20.260 --> 00:15:25.020 that are unconfirmed for now, and they're confirmed one block at a time, and this 00:15:25.020 --> 00:15:29.560 means a new block is found. But there is some sort of bidding process going on 00:15:29.560 --> 00:15:30.760 with RBF. 00:15:30.840 --> 00:15:31.340 That's right. 00:15:31.580 --> 00:15:37.500 Which... the reason someone would be willing to outbid someone else with 00:15:37.500 --> 00:15:43.240 a block is because that block would pay him more in the new 00:15:43.240 --> 00:15:49.150 coins that are on the sidechain which are in turn mining fees that 00:15:49.150 --> 00:15:54.830 users of this alternative chain are paying to have their transactions included in 00:15:54.830 --> 00:15:56.130 this alternative chain. 00:15:56.350 --> 00:16:01.050 Yeah, that's right. So it is very similar to how Bitcoin works. And obviously 00:16:01.050 --> 00:16:03.870 that's not a coincidence because it's really kind of emulating proof of work 00:16:03.870 --> 00:16:09.430 here. So the fees on, just like in Bitcoin, all the fees go to miners and that's 00:16:09.430 --> 00:16:13.150 what incentivizes miners to actually go and do all this hashing and create a 00:16:13.150 --> 00:16:19.090 block here. The miners, the blind Merge Mine miners, they take the fees from this 00:16:19.090 --> 00:16:24.810 blind Merge Mine chain and they utilize that to put in the hash in the Bitcoin 00:16:24.810 --> 00:16:28.250 blockchain and they pay roughly the equivalent of whatever they're being paid in 00:16:28.250 --> 00:16:32.330 these fees to the Bitcoin miners. So what it does, and that's kind of important 00:16:32.330 --> 00:16:37.810 to note, is that... Essentially, we are outsourcing the mining of this other 00:16:37.810 --> 00:16:41.690 chain to the Bitcoin miners because we're paying Bitcoin fees. And these Bitcoin 00:16:41.690 --> 00:16:46.270 miners will be competing over those Bitcoin fees through proof of work. So 00:16:46.270 --> 00:16:51.530 indirectly, it's still proof of work. But we're utilizing Bitcoin as a kind of 00:16:51.530 --> 00:16:52.210 step in between. 00:16:52.670 --> 00:16:58.170 Right. I'm thinking of 51% attacks. Could this system be 51% attacks in some way? 00:16:58.290 --> 00:17:03.250 Say you're willing to pay more fees in a competing block in the next Bitcoin 00:17:03.250 --> 00:17:06.810 block, or does the sidechain have these rules? I'm just calling it a sidechain. 00:17:06.950 --> 00:17:07.130 Sure. 00:17:07.210 --> 00:17:12.510 Does the sidechain have a sort of rule that it can't be 51% attacks compared to 00:17:12.510 --> 00:17:16.100 the Bitcoin blockchain? Because that's how it would... benefit from the Bitcoin 00:17:16.100 --> 00:17:17.160 security, right? I guess. 00:17:17.300 --> 00:17:21.920 Yeah. So I think it's always kind of a spurious claim to say that you're getting 00:17:21.920 --> 00:17:25.840 security from the Bitcoin blockchain, but there does seem to be, to some degree, 00:17:25.980 --> 00:17:30.740 that does seem to be happening. So just like to be very clear and practical about 00:17:30.740 --> 00:17:34.860 this, there is a way, like the difference with proof of work mining is that it's 00:17:34.860 --> 00:17:39.000 not a process where randomly a winner is selected. It's a process where whoever 00:17:39.000 --> 00:17:43.590 pays the most gets to create a block. So if you want to stop this chain, you 00:17:43.590 --> 00:17:48.170 could literally do so by just paying higher fees and creating a block that just 00:17:48.170 --> 00:17:52.230 contains nothing or even just an invalid block that's fine too that would just be 00:17:52.230 --> 00:17:57.070 ignored. But in doing so, what's interesting is that the fees will start to 00:17:57.070 --> 00:18:00.150 accumulate on the sidechain. Let's call it a sidechain. 00:18:01.400 --> 00:18:04.540 So this kind of creates fee pressure where for the next block, if you want to 00:18:04.540 --> 00:18:07.100 keep censoring it, you got to pay even more. For the next block, you got to pay 00:18:07.100 --> 00:18:10.720 even more. So there is this kind of like pressure where at the end of the day, it 00:18:10.720 --> 00:18:13.040 becomes quite similar to what Bitcoin does. 00:18:13.260 --> 00:18:16.000 Right. So, but that's a censorship 51% attack. 00:18:16.440 --> 00:18:16.620 Yes. 00:18:16.760 --> 00:18:20.100 What about double spend 51% attack? I'm guessing that... 00:18:20.100 --> 00:18:21.120 Like a reorg or... 00:18:21.120 --> 00:18:24.630 Yeah. Yeah. I guess that wouldn't be possible without actually re-orging the 00:18:24.630 --> 00:18:25.230 Bitcoin blockchain. 00:18:25.490 --> 00:18:28.910 So it is possible, but it would be a slow process. So that's kind of interesting. 00:18:29.190 --> 00:18:34.430 So let's say you want to just do a two-block re-org off the sidechain. So what 00:18:34.430 --> 00:18:40.170 happens is that you have to put a block that has a lower 00:18:40.170 --> 00:18:44.670 block height, you have to put that into the Bitcoin blockchain, the hash of that 00:18:44.670 --> 00:18:50.380 block. So what that means is for the longest sidechain, the longest chain, on the 00:18:50.380 --> 00:18:55.040 side chain, there's no block basically occurring, right? Because there's not as 00:18:55.040 --> 00:18:58.840 older block, it's not the longest chain. So basically nothing happens. For 10 00:18:58.840 --> 00:19:02.800 minutes, there's no new block. And then another block gets created. And then 00:19:02.800 --> 00:19:05.900 another block gets created. And now that shorter chain becomes the longer chain. 00:19:06.020 --> 00:19:11.340 So basically the longest chain halts while you're re-orging the chain. And 00:19:11.340 --> 00:19:15.490 that's... very unique to this proposal. And I think at the end of the day, that 00:19:15.490 --> 00:19:18.550 actually kind of ends up being a security benefit because it means that if you're 00:19:18.550 --> 00:19:22.270 a hundred blocks into the future, you know it's going to literally take a 00:19:22.270 --> 00:19:25.210 thousand minutes at least to reorg those blocks. 00:19:25.430 --> 00:19:29.740 Well, but you can't do anything in those thousand minutes, except... Make a phone call. 00:19:30.160 --> 00:19:35.840 Yeah, so the chain halts during that time, but that is also when the 00:19:35.840 --> 00:19:39.420 sidechain fees start to rise because people can't get their transactions in, 00:19:39.580 --> 00:19:43.680 which makes it even more difficult for that reorg to occur. There is an 00:19:43.680 --> 00:19:47.880 interesting mechanism there that seems to work out pretty well, but I do think it 00:19:47.880 --> 00:19:52.740 requires more deep thought and maybe just some experimentation to kind of see how 00:19:52.740 --> 00:19:53.480 it works out in practice. 00:19:53.660 --> 00:19:57.750 I guess another way to look at it is that if you want to annoy this sidechain, if 00:19:57.750 --> 00:20:02.530 we call it that way. We can edit it in post production. There's only one Bitcoin 00:20:02.530 --> 00:20:06.050 block or one Bitcoin transaction available every Bitcoin block where you can 00:20:06.050 --> 00:20:11.470 decide the next sidechain block. And so you can DOS that particular 00:20:11.470 --> 00:20:16.330 Bitcoin transaction for every sidechain block. And you can DOS it in different 00:20:16.330 --> 00:20:21.430 ways, right? You can create empty blocks on the main chain for the sidechain, or 00:20:21.430 --> 00:20:26.480 you can... Fork off a very old sidechain block or you can just put complete 00:20:26.480 --> 00:20:32.120 garbage in it. Yeah Yeah, but yeah, but as long as the fees on the sidechain 00:20:32.120 --> 00:20:35.840 represents some real value, they'll accumulate and eventually it'll get expensive 00:20:35.840 --> 00:20:36.500 for you to do this. 00:20:36.660 --> 00:20:37.320 That's right, yeah. 00:20:37.360 --> 00:20:39.900 But perhaps not prohibitively. Yeah. That's interesting. 00:20:40.080 --> 00:20:45.940 Yeah, but it is kind of similar to how in Bitcoin you could like 51% attack and 00:20:45.940 --> 00:20:50.860 create these bogus blocks all the time. But in Bitcoin, it's very obvious how 00:20:50.860 --> 00:20:54.460 expensive that is. And here, especially when you think about a low value 00:20:54.460 --> 00:20:59.030 sidechain, It's maybe not as obvious whether or not that's going to work out. And 00:20:59.030 --> 00:21:02.110 that's definitely a thing, right? Because with Bitcoin, we also have the benefit 00:21:02.110 --> 00:21:07.490 of having a block reward where every new block creates a new Bitcoins and that 00:21:07.490 --> 00:21:11.390 also moves things forward. And that's going to be different in this chain where 00:21:11.390 --> 00:21:16.190 we don't actually introduce a new coin, a new token. There are no coins being 00:21:16.190 --> 00:21:19.730 generated. So really everything has to come from fees. So that's not going to be 00:21:19.730 --> 00:21:20.590 exactly the same as Bitcoin. 00:21:20.810 --> 00:21:21.470 There's no subsidy. 00:21:21.770 --> 00:21:22.590 There's no subsidy. 00:21:22.810 --> 00:21:24.470 Okay, so that's the merged mine. 00:21:25.410 --> 00:21:25.850 Yes. 00:21:26.010 --> 00:21:28.510 I think that's pretty clear to me. Is it to you, Sjors? 00:21:28.670 --> 00:21:34.170 Almost, but I have one more advanced question. What is in this scaffold of 00:21:34.170 --> 00:21:37.610 transactions that we're talking about? Because like we said, we pre-generate a 00:21:37.610 --> 00:21:41.890 whole series of transactions for the next 10 years, and they each have one input 00:21:41.890 --> 00:21:47.610 and one output, and those will stay the same forever, but we can add inputs 00:21:47.610 --> 00:21:52.170 and outputs later to commit to blocks, et cetera. What is in these initial... 00:21:52.340 --> 00:21:57.400 inputs and outputs, and why can't I shuffle them around and do mean things with them? 00:21:57.620 --> 00:21:58.740 Right. So... 00:22:00.140 --> 00:22:05.760 This is actually a covenant. So a covenant is basically an enforcement of how an 00:22:05.760 --> 00:22:06.780 output is going to be spent. 00:22:06.940 --> 00:22:08.220 But Bitcoin doesn't have covenants. 00:22:08.440 --> 00:22:14.100 Bitcoin doesn't have covenants yet. But with ANYPREVOUT, actually, we'll be 00:22:14.100 --> 00:22:19.700 kind of incidentally introducing the equivalent to the OP_CTV covenants, which is 00:22:19.700 --> 00:22:23.940 something that Jeremy Rubin has been working on. And essentially what it is, is 00:22:23.940 --> 00:22:28.560 this is with OP_CTV, I guess it's easier to explain. It's basically a hash in the 00:22:28.560 --> 00:22:32.970 output. that determines what the next transaction is that is allowed to spend 00:22:32.970 --> 00:22:37.530 that output and what we do here is instead of the hash we actually put the 00:22:37.530 --> 00:22:41.870 signature in the output ahead of time so normally what you have is you have a you 00:22:41.870 --> 00:22:46.930 have a pub key or a pub key hash and then when you spend it you you create the 00:22:46.930 --> 00:22:51.050 signature for that pub key hash and what we do here is we actually have in the 00:22:51.050 --> 00:22:56.120 outputs the pub key hash plus the signature And it's all there already. So it's 00:22:56.120 --> 00:23:00.440 already predetermined how it's going to be spent. But this is only possible with 00:23:00.440 --> 00:23:05.460 a SIGHASH ANYPREVOUT because the signature kind of refers back to the transaction 00:23:05.460 --> 00:23:09.020 itself. And that will be kind of a circular reference. So with ANYPREVOUT, 00:23:09.100 --> 00:23:12.380 because you don't have to sign the transaction itself, the transaction that 00:23:12.380 --> 00:23:15.480 you're spending, or at least not the TXID, you don't have that issue. So it 00:23:15.480 --> 00:23:17.260 becomes possible to do a covenant like that. 00:23:17.380 --> 00:23:22.700 But the signature in transaction one refers to transaction two. Yeah. And the 00:23:22.700 --> 00:23:26.710 signature in transaction two. refers to transaction three because the signature 00:23:26.710 --> 00:23:27.630 is in the output now. 00:23:27.820 --> 00:23:28.340 That's right. 00:23:28.500 --> 00:23:30.620 Yeah, this is quite mind-boggling. 00:23:31.000 --> 00:23:35.600 That's right. Yeah, it is. It is a little, it's a little bit of a hack. And I 00:23:35.600 --> 00:23:37.760 guess we're going to have to wait and see kind of what the final version of 00:23:37.760 --> 00:23:41.960 ANYPREVOUT becomes. But it seems like this will be possible. It is less efficient 00:23:41.960 --> 00:23:46.080 than OP_CTV because with OP_CTV, it's literally a hash and here it's a signature. 00:23:46.340 --> 00:23:49.740 So a signature is kind of double the data roughly and you need to do a signature 00:23:49.740 --> 00:23:52.820 check. Just one little side note that's kind of funny is that the signature 00:23:52.820 --> 00:23:55.850 doesn't need to be secure. in the sense that it doesn't really matter what the 00:23:55.850 --> 00:23:59.830 private key is. So the most efficient way of doing it is actually using the 00:23:59.830 --> 00:24:04.950 generator G as the pub key that you're signing the signature with. And it doesn't 00:24:04.950 --> 00:24:08.930 matter because you're already committed to what transaction you're signing. So 00:24:08.930 --> 00:24:11.690 the fact that it's G and everybody knows it is kind of irrelevant. 00:24:12.110 --> 00:24:15.350 Doesn't something have to increment? Because otherwise all these transactions 00:24:15.350 --> 00:24:19.490 would be identical and I could still swap them out. Or is the recursion creating 00:24:19.490 --> 00:24:20.610 different hashes all the time? 00:24:20.690 --> 00:24:23.070 The recursion should be creating different hashes all the time, yeah. 00:24:24.280 --> 00:24:29.520