WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.210 --> 00:00:22.470 Live from Utrecht, this is Bitcoin. 00:00:23.150 --> 00:00:23.710 Explained. 00:00:24.330 --> 00:00:28.450 Sjors, you want to start the episode off with some boosts. Is that right? 00:00:28.790 --> 00:00:31.750 That's right. Well, yeah, we've only got a few. 00:00:32.130 --> 00:00:34.050 Remind the listeners of the context here. 00:00:34.470 --> 00:00:39.730 So boosts, if you're using a podcasting 2.0 application like Fountain and there's 00:00:39.730 --> 00:00:44.130 a couple of other ones, it can stream satoshis right to our Lightning node. 00:00:45.590 --> 00:00:47.690 And people can make comments apparently. 00:00:47.690 --> 00:00:51.630 Exactly you can also leave a comment and then you can attach satoshis to that 00:00:51.630 --> 00:00:54.310 comment and then there is a possibility that I'll read it. 00:00:54.310 --> 00:00:57.690 Do you have to attach satoshis to to leave a comment or… 00:00:57.690 --> 00:00:59.810 Yes but you can add like one satoshi. 00:00:59.810 --> 00:01:02.430 And they and these satoshis go right into our pocket. 00:01:02.490 --> 00:01:03.690 That's right 00:01:03.690 --> 00:01:05.230 Well your pocket. 00:01:05.230 --> 00:01:09.970 I'm still waiting for the last paycheck so where's my money? 00:01:05.360 --> 00:01:07.100 They go to my pocket, and then [unclear]… 00:01:10.410 --> 00:01:14.870 You need to run your own full-time node then it can stream directly to you. 00:01:14.870 --> 00:01:19.500 All right let's hear the best pay is this the best paying boost you're gonna read? 00:01:19.500 --> 00:01:24.820 Coincidentally yes. So this is the Makerman or Makerman I don't know. Hey guys 00:01:24.820 --> 00:01:28.620 love the podcast. Thank you been mostly listening to old episodes until now and 00:01:28.620 --> 00:01:34.260 saw your setup with podcasting 2.0 That's what we talk about. FYI, I could not 00:01:34.260 --> 00:01:38.700 find you in the Fountain search. If you're somehow having difficulty streaming 00:01:38.700 --> 00:01:44.060 sats, there is another alternative podcast link, but that URL is unpronounceable 00:01:44.060 --> 00:01:48.040 and very long. So if you find me on Twitter or something, I'll tell you what it is. 00:01:49.530 --> 00:01:52.450 All right. Well, thank you, Makerman. How much did Makerman pay us? 00:01:53.150 --> 00:01:54.830 10,000 satoshi. 00:01:55.210 --> 00:02:00.800 Nice. All right. Today, we're going to discuss time locks. This was actually a 00:02:00.800 --> 00:02:03.360 suggestion by a friend of the show, Ruben Somsen. 00:02:04.690 --> 00:02:09.270 As you are well aware, but probably our listeners as well at this point, we 00:02:09.270 --> 00:02:14.420 increasingly have to... Dig deeper and deeper to come up with subjects to discuss 00:02:14.420 --> 00:02:17.600 because we've almost explained all of Bitcoin at this point. We… 00:02:17.600 --> 00:02:20.940 Have explained all of Bitcoin except for a few things that take too much 00:02:20.940 --> 00:02:21.380 research. 00:02:21.380 --> 00:02:25.820 Yeah for which we would really like to have an expert on the actual podcast at 00:02:25.820 --> 00:02:30.140 some point but somehow we never had an episode on time locks yet so this was a 00:02:30.140 --> 00:02:31.480 pretty good suggestion I think. 00:02:32.310 --> 00:02:33.130 I think so too. 00:02:33.330 --> 00:02:38.050 So Sjors, we're going to discuss time locks. First of all, maybe as a very, you 00:02:38.050 --> 00:02:41.410 know, most of our listeners will know this, but let's just start with a very 00:02:41.410 --> 00:02:43.510 general, what is a time lock? 00:02:43.750 --> 00:02:44.650 What is time? Oh, okay. 00:02:45.070 --> 00:02:46.150 Yes, let's start there. 00:02:46.570 --> 00:02:51.070 Yeah, a time lock means that, so normally when you make a transaction, you know, 00:02:51.210 --> 00:02:55.450 you create it in your wallet, you send it out to a bunch of other peers in the 00:02:55.450 --> 00:02:59.330 network, and then eventually a miner will put it into a block, basically as soon 00:02:59.330 --> 00:03:03.050 as possible. But maybe there's a reason why you don't want that to happen 00:03:03.050 --> 00:03:08.090 immediately. You can use a time lock to prevent a transaction from being mined 00:03:08.090 --> 00:03:13.290 now, and it has to be mined after a certain date or a certain block height. 00:03:14.210 --> 00:03:18.630 Yeah, I guess the even shorter summary I would give, but maybe it's a little 00:03:18.630 --> 00:03:22.370 inaccurate if I make it this short, but we'll get into that a little later. But I 00:03:22.370 --> 00:03:26.690 would just say it's a way of locking bitcoins into the blockchain in a way that 00:03:26.690 --> 00:03:29.390 they cannot be spent yet, but they can be spent later. 00:03:29.770 --> 00:03:34.530 Well, that's not always true because you can also do it in a way that is not yet 00:03:34.530 --> 00:03:38.650 in the blockchain itself. So you can make a transaction that cannot be put into 00:03:38.650 --> 00:03:39.430 the blockchain at all. 00:03:39.800 --> 00:03:43.260 Right okay so I think that's the type of stuff we're going to get into exactly 00:03:43.260 --> 00:03:49.160 this episode so anyways, that's a general idea somehow you want to prevent 00:03:49.160 --> 00:03:52.480 bitcoins from being spent right now but they should be able to be spent later 00:03:52.480 --> 00:03:57.920 right that's the one sentence summary then I guess. Okay so has this always been 00:03:57.920 --> 00:03:59.760 an option in Bitcoin Sjors? 00:03:59.760 --> 00:04:05.360 No the very old version of Bitcoin did have a field that would suggest that but 00:04:05.360 --> 00:04:06.260 it didn't actually do it. 00:04:06.260 --> 00:04:07.580 Just one step back maybe we… 00:04:09.040 --> 00:04:14.240 Is it better to... Are there some examples of why you would want to do this? Or 00:04:14.240 --> 00:04:16.640 should we mention these throughout the episode as well? 00:04:16.820 --> 00:04:19.080 We can probably try to explain them as we come up with it. 00:04:19.640 --> 00:04:20.300 Okay, so... 00:04:21.660 --> 00:04:26.160 In that case, I interrupted you at a very bad time because you were given a great 00:04:26.160 --> 00:04:30.560 explanation of the history of time locks to start off with. And you said it 00:04:30.560 --> 00:04:31.700 wasn't always possible. 00:04:32.000 --> 00:04:36.760 No, it wasn't enforced. So in the original version of Bitcoin, what you could do 00:04:36.760 --> 00:04:40.500 is tell a transaction. You could tell a transaction that you didn't want it to be 00:04:40.500 --> 00:04:44.760 mined before a certain block, but this was a policy thing. So your peers might 00:04:44.760 --> 00:04:48.660 not relay it, but if it was in a block, you would still accept it. So in other 00:04:48.660 --> 00:04:50.480 words, you couldn't trust it for security purposes. 00:04:50.840 --> 00:04:56.180 Okay first question you say you can put it in a transaction like where is it how 00:04:56.180 --> 00:04:58.460 does it what does this actually look like in this case? 00:04:58.460 --> 00:05:03.840 Yeah so this early mechanism is called nLockTime so that is a transaction in a 00:05:03.840 --> 00:05:05.300 field all the way at the end of a transaction. 00:05:05.300 --> 00:05:08.980 Okay so you actually attach it? It's part of the actual transaction. 00:05:08.980 --> 00:05:10.940 Yeah it's part of the transaction hash as well and… 00:05:10.940 --> 00:05:15.140 In the very early days as you said if you put that in the transaction that would 00:05:15.140 --> 00:05:19.860 mean that Bitcoin nodes will not… If they receive the transaction over the 00:05:19.860 --> 00:05:20.760 peer-to-peer network... 00:05:20.760 --> 00:05:21.500 They'll ignore it. 00:05:21.560 --> 00:05:22.640 They will ignore it. And miners… 00:05:22.320 --> 00:05:23.700 But if it's in a block, they'll be fine. 00:05:23.980 --> 00:05:28.360 Right. So if some other miner somehow mines it, they'll still accept the block. 00:05:28.520 --> 00:05:33.320 So it wasn't a consensus rule. It was a peer-to-peer network rule, essentially. 00:05:33.580 --> 00:05:33.700 Yeah. 00:05:34.120 --> 00:05:36.240 It was a mempool policy, as you mentioned. 00:05:36.380 --> 00:05:36.940 A policy rule. Right, yeah. 00:05:37.980 --> 00:05:42.480 Okay, so this was... At the very beginning, it was there, but not as a consensus rule. 00:05:42.660 --> 00:05:46.420 Yeah. And then I think fairly quickly, but I forgot to check when exactly, maybe 00:05:46.420 --> 00:05:49.980 2012 or earlier, this was turned into a consensus rule. 00:05:50.000 --> 00:05:51.920 It was in the first year, I'm pretty sure. 00:05:52.120 --> 00:05:52.240 Yeah. 00:05:52.240 --> 00:05:57.600 Because I did check it. So unless my memory again is even worse than I think, I 00:05:57.600 --> 00:06:01.760 think this was... In the first or maybe the second year was made into an actual 00:06:01.760 --> 00:06:02.440 consensus rule. 00:06:02.680 --> 00:06:06.620 Well, and it was also improved. So the initial version, I believe, was only 00:06:06.620 --> 00:06:10.540 height. So you could only say, don't mine this before block height number 300, 00:06:10.560 --> 00:06:15.680 whatever. But this was improved to also allow you to specify a time. So you could 00:06:15.680 --> 00:06:19.580 say, well, don't mine this before the year 2020, because maybe blocks come in 00:06:19.580 --> 00:06:21.780 faster or slower. So you can choose. 00:06:23.320 --> 00:06:29.190 Right. Okay. So, year one let's say roughly it was there as a policy 00:06:29.190 --> 00:06:34.950 rule and then after from my memory about a year it was implemented 00:06:34.950 --> 00:06:40.210 as a consensus rule and that was nLockTime so that was one way of doing… 00:06:40.210 --> 00:06:46.090 okay so maybe here is a good point to ask why would anyone want to use this? 00:06:46.270 --> 00:06:51.090 Are there any practical examples of why someone would want to put this on their 00:06:51.090 --> 00:06:51.710 own transaction? 00:06:51.970 --> 00:06:57.750 I guess you could use it as some sort of dead man's switch. So maybe you create a 00:06:57.750 --> 00:07:02.110 wallet and you're not sure that you're going to hold on to the private keys very 00:07:02.110 --> 00:07:06.910 well. And you have a backup wallet somewhere else where you do think you'll hold 00:07:06.910 --> 00:07:10.210 on to the private keys very well. Now what you can do is you can make a 00:07:10.210 --> 00:07:14.720 transaction that goes from this your new wallet that you're not sure about back 00:07:14.720 --> 00:07:19.120 to your old wallet and you put a time lock in at 10 years in the future. And then 00:07:19.120 --> 00:07:22.360 maybe if you lose your keys, you can still take that transaction that you signed 00:07:22.360 --> 00:07:26.280 when you did have the keys and broadcast it then to get your money back to the 00:07:26.280 --> 00:07:30.680 safe space. So it's kind of like a dead-man’s switch because that transaction 00:07:30.680 --> 00:07:34.680 will, if you broadcast it, it eventually will happen. But if you just spend the 00:07:34.680 --> 00:07:36.460 coin somewhere else, then it won't happen. 00:07:38.540 --> 00:07:44.340 Just to be clear, so who's putting the time lock there in this? You are. So the 00:07:44.340 --> 00:07:48.780 creator of the transaction, that's the person that's putting the time lock there, right? 00:07:48.920 --> 00:07:49.120 Yes. 00:07:49.220 --> 00:07:53.560 Not the recipient. No. Because usually your recipient gives an address and the 00:07:53.560 --> 00:07:54.940 address contains all kinds… 00:07:55.020 --> 00:07:58.340 In this case, in this example we did, you are the recipient. But in any case, 00:07:58.520 --> 00:08:01.720 you're giving the recipient. Or maybe it's an inheritance thing, right? So you 00:08:01.720 --> 00:08:04.980 give a transaction to your children that you say, well, if you broadcast this 00:08:04.980 --> 00:08:09.680 thing you'll get my coins, but not before this year. And also not if I decide to 00:08:09.680 --> 00:08:12.640 move the coins in the meantime, because then that transaction will be unusable. 00:08:13.000 --> 00:08:17.480 Right. Well, that's kind of a clear example, I guess. Yeah. So you would give the 00:08:17.480 --> 00:08:21.400 actual transaction itself to you. So you're not sending them coins. 00:08:21.400 --> 00:08:23.380 You can give it to them very early because you're not giving them any private 00:08:23.380 --> 00:08:26.280 keys. You're just giving them these transactions. Well, if nothing else happens, 00:08:26.540 --> 00:08:31.520 these coins will be yours, assuming that the transaction goes to them. But I can 00:08:31.520 --> 00:08:32.040 change my mind. 00:08:32.810 --> 00:08:38.690 Right, okay. So this was essentially the first version of a time lock on 00:08:38.690 --> 00:08:44.250 Bitcoin. Now, I think from there on, the next step essentially 00:08:44.250 --> 00:08:47.510 was to actually enforce it on the blockchain, right? Am I saying that right? 00:08:48.110 --> 00:08:52.110 Yeah, that's what we talked about now as well. Well, so the difference is here 00:08:52.110 --> 00:08:55.050 you have a transaction that is not yet in the blockchain and you're preventing 00:08:55.050 --> 00:08:58.490 that transaction from being included. But the next thing that would happen is 00:08:58.490 --> 00:09:03.050 that a transaction would be in the blockchain, but your ability to spend it would 00:09:03.050 --> 00:09:07.450 be limited. So basically, you're constraining the output of a transaction. You're 00:09:07.450 --> 00:09:10.630 not constraining the whole transaction. You're just saying, well, this output is 00:09:10.630 --> 00:09:13.950 here on the blockchain, but you can't spend it until the year 2100. 00:09:14.250 --> 00:09:18.450 Right. So in the previous example, when you want to give something to your kids 00:09:18.450 --> 00:09:22.410 with nLockTime, you had to give them the actual transaction, which they would 00:09:22.410 --> 00:09:27.010 have to broadcast themselves later. And now we're moving to a situation or I mean 00:09:27.010 --> 00:09:29.750 Yeah now we're moving to a situation where you're sending them the coins on the 00:09:29.750 --> 00:09:33.290 blockchain but you're saying you know here they are but you can't spend them 00:09:33.290 --> 00:09:37.850 until the year 2100 but they are yours, like I can't take them back anymore. 00:09:37.850 --> 00:09:38.930 Okay so what is this? 00:09:38.930 --> 00:09:44.400 So this uses a mechanism called CheckLockTimeVerify. And what this really does 00:09:44.400 --> 00:09:49.160 under the hood is it says the output of the transaction is a script, right? Or a 00:09:49.160 --> 00:09:53.320 hash of a script. And the script says, like, the only transaction that can spend 00:09:53.320 --> 00:09:59.220 me is a transaction that has a high nLockTime. So the enforcement happens by 00:09:59.220 --> 00:10:03.540 saying, in order to spend it, you have to put in a very high nLockTime. And 00:10:03.540 --> 00:10:07.280 because the blockchain will make sure that the transaction with a high nLockTime 00:10:07.280 --> 00:10:12.060 is not included before the year 2100, this works. It's kind of a weird delegation 00:10:12.060 --> 00:10:12.760 of responsibility. 00:10:13.390 --> 00:10:18.710 Right, so this is CheckLockTimeVerify. This was implemented in Bitcoin in 00:10:18.710 --> 00:10:23.870 2015 through a soft fork. It's essentially, as you're explaining, it's still 00:10:23.870 --> 00:10:29.670 using nLockTime. It's still using what we discussed before, but now there's an 00:10:29.670 --> 00:10:35.520 extra step as a soft fork that actually requires... The next transaction when you 00:10:35.520 --> 00:10:40.800 want to spend the coins, it requires that transaction to have nLockTime. Am I 00:10:40.800 --> 00:10:41.240 saying this right? 00:10:41.320 --> 00:10:44.700 That's correct. Because usually when you're spending a transaction, the output 00:10:44.700 --> 00:10:50.370 script determines how it can be spent. Right but it only determines what the 00:10:50.370 --> 00:10:54.350 input should be because normally in the input you would put a signature or 00:10:54.350 --> 00:10:57.630 something like that but now it's saying it's not just the input that has to be a 00:10:57.630 --> 00:11:00.570 certain way the transaction itself has to have certain rules too. 00:11:00.570 --> 00:11:05.310 Yeah so I guess so one of the things this changes I just mentioned with nLockTime 00:11:05.310 --> 00:11:11.210 alone the person that adds the lock time is the sender of the transaction 00:11:11.210 --> 00:11:16.470 and now it's embedded also like the recipient has to first 00:11:17.740 --> 00:11:19.880 decides that it has to be locked right? 00:11:19.880 --> 00:11:23.320 Like yeah if you're trying to receive coins if you want to receive coins from 00:11:23.320 --> 00:11:26.480 somebody you have to give them the script that it goes through. So you're really 00:11:26.480 --> 00:11:30.120 constraining yourself in a way when you're doing this but in the inheritance 00:11:30.120 --> 00:11:34.720 scenario you would tell your kids like you know give me an address that has this 00:11:34.720 --> 00:11:38.640 script in it and your own public because otherwise of course you wouldn't do this 00:11:38.640 --> 00:11:42.000 and of course there are more complicated setups like Lightning things etc where 00:11:42.000 --> 00:11:43.760 you would want to use constructions like this. 00:11:46.440 --> 00:11:50.400 So you mentioned Lightning, but I don't think that's actually correct. Lightning 00:11:50.400 --> 00:11:54.300 doesn't use this. Lightning uses another time lock, which we're going to discuss 00:11:54.300 --> 00:11:59.280 next. But what are some examples for this CLTV type of 00:12:00.300 --> 00:12:04.920 time lock? Why would anyone want to use this? So we've discussed the inheritance 00:12:04.920 --> 00:12:10.640 example, which I think is valid. And are there other examples you can think of? 00:12:10.880 --> 00:12:11.460 I don't know. 00:12:11.900 --> 00:12:16.060 You yeah well there's this thing called fidelity bonds so that would be one 00:12:16.060 --> 00:12:20.680 example if you somehow want to prove that you're not a spammer of some kind then 00:12:20.680 --> 00:12:23.820 you have to actually lock up bitcoins and prove that you've done so. 00:12:23.820 --> 00:12:26.980 Yeah it's a way to publicly prove that you are locking up coins. 00:12:26.980 --> 00:12:30.560 That's true yeah so that's one example and I think another one is what's that 00:12:30.560 --> 00:12:35.480 called when you want to trustlessly exchange coins right you want to have some 00:12:35.480 --> 00:12:36.700 sort of trustless exchange. 00:12:36.700 --> 00:12:41.760 But then relative locks are probably better too. So we'll get to that. 00:12:42.180 --> 00:12:45.380 Yeah, well, so this one was rolled out first. And I definitely think this is one 00:12:45.380 --> 00:12:49.400 of the motivations at least end up at that point. What's this called? 00:12:50.300 --> 00:12:51.000 Atomic swaps. 00:12:51.140 --> 00:12:53.240 Atomic swaps. Thank you. That's what I was thinking of. Yeah. 00:12:53.660 --> 00:12:56.300 I mean, it's a bit risky because you're composing the transactions at a certain 00:12:56.300 --> 00:12:59.620 time, but you don't know when they're actually going to be put on the chain. So 00:12:59.620 --> 00:13:02.540 if you use an absolute date, you have to be careful with that sort of stuff. 00:13:02.700 --> 00:13:06.920 Right. Well, the idea with atomic swaps is that you basically publish 00:13:08.190 --> 00:13:11.290 a contract on the blockchain I'm gonna say that's right and then the other person 00:13:11.290 --> 00:13:17.070 can claim the coins if they fulfill if they send coins back on another… 00:13:17.070 --> 00:13:20.230 Yeah I guess in that case it's up to you how long you want to how long you want 00:13:20.230 --> 00:13:21.250 that contract to be open. 00:13:21.250 --> 00:13:24.850 Well the point is if the other person doesn't do that so that's where the time 00:13:24.850 --> 00:13:28.310 lock comes in and after a while you can claim the coins back so that's why there 00:13:28.310 --> 00:13:32.850 needs to be a time lock in these kinds of smart contracts so yeah time locks are 00:13:32.850 --> 00:13:37.830 very useful in many types of smart contracts. Probably their main use case right? 00:13:37.830 --> 00:13:43.010 Then so we come to Lightning and CheckSequenceVerify. 00:13:43.010 --> 00:13:47.810 Yeah well actually yeah I mean Lightning also required SegWit to really work but 00:13:47.810 --> 00:13:50.450 this is one of the first goals that was taken to help with Lightning. 00:13:50.450 --> 00:13:55.260 Okay so what's the difference between CheckLockTimeVerify and 00:13:55.260 --> 00:13:56.780 CheckSequenceVerify? 00:13:57.420 --> 00:14:01.440 So CheckLockTime, I mean, in terms of how you use it, the usage basically just 00:14:01.440 --> 00:14:06.100 means that you can do relative times. So you can say not at block 500,000, but 00:14:06.100 --> 00:14:11.930 you can say 10 blocks from now or 10 hours from now. That's basically 00:14:11.930 --> 00:14:16.730 the utility. And the way it's implemented is by something called nSequence. Or 00:14:16.730 --> 00:14:20.870 it's implemented as a two-step process. First, there was a BIP 68, which 00:14:20.870 --> 00:14:24.650 introduced nSequence. And nSequence is something you put on the input of a 00:14:24.650 --> 00:14:29.970 transaction. And it's similar to the nLockTime, which has a similar mechanic. So 00:14:29.970 --> 00:14:35.490 it's basically saying this input of this transaction can only be spent after five 00:14:35.490 --> 00:14:39.490 blocks. And that is five blocks after the output that it's spending. So an input 00:14:39.490 --> 00:14:45.230 always spends an output, and by setting an nSequence field on this input, you are 00:14:45.230 --> 00:14:50.940 saying this input can only spend an output that is at least 10 blocks old. And by 00:14:50.940 --> 00:14:55.920 itself, that's not very useful because you're just constraining yourself. But the 00:14:55.920 --> 00:15:01.520 code, the opcode, CheckSequenceVerify, in a similar way to what we discussed 00:15:01.520 --> 00:15:06.730 before, can say, well... You can only spend this output if you provide an input 00:15:06.730 --> 00:15:08.470 that has a certain nSequence in it. 00:15:11.740 --> 00:15:12.980 What is an nSequence? 00:15:13.840 --> 00:15:19.060 It's just a number. It's a number that is put in the transaction input. Just like 00:15:19.060 --> 00:15:24.250 the nLockTime is a number that you put on a transaction as a whole. And it's 00:15:24.250 --> 00:15:30.100 interpreted as either a time or a height. But like a relative time or a 00:15:30.100 --> 00:15:32.060 relative height. So seconds or... 00:15:32.520 --> 00:15:37.600 Right. So if I understand you correctly, nSequence was always in the Bitcoin 00:15:37.600 --> 00:15:40.540 protocol, but it was just a number that didn't actually mean anything? 00:15:40.800 --> 00:15:45.460 Yeah, exactly. It was meaningless. And so probably zero in most cases. And it was 00:15:45.460 --> 00:15:51.280 given a meaning in a soft fork. And the meaning is like you cannot put this 00:15:51.280 --> 00:15:55.400 input in a block. So the transaction as a whole, you can't put it in a block 00:15:55.400 --> 00:16:00.100 until this many blocks have gone by or this many seconds have gone by. 00:16:00.510 --> 00:16:04.930 Right. So this number that was always there is now interpreted by Bitcoin nodes 00:16:04.930 --> 00:16:07.010 to actually mean this is a time. 00:16:07.470 --> 00:16:07.650 Yes. 00:16:08.010 --> 00:16:12.770 Right. Okay. And then they will check if the time complies with the actual time 00:16:12.770 --> 00:16:16.090 in their computer clock to determine if enough time is passed. 00:16:16.090 --> 00:16:21.910 Not the computer clock, the time in the blocks. So to be accurate, the median 00:16:21.910 --> 00:16:26.750 time past. So take the timestamp that is in the last 11 blocks and you take the 00:16:26.750 --> 00:16:27.170 middle one. 00:16:28.350 --> 00:16:31.430 Well, if you're a miner, then you have to actually use your computer clock to 00:16:31.430 --> 00:16:33.830 determine if you include it in a block, I would assume, right? 00:16:35.090 --> 00:16:40.230 No, you can know this in advance because the way you do it is you look at the 00:16:40.230 --> 00:16:45.110 last block that you've received and then you do this calculation with the 11 most 00:16:45.110 --> 00:16:48.670 recent blocks and then you know what you can put in the mempool and what you can 00:16:48.670 --> 00:16:52.070 put in the mempool is what you can put in the block. So you don't have to look at 00:16:52.070 --> 00:16:55.270 your computer time. You look at your computer time in order to produce a block. 00:16:55.690 --> 00:16:58.930 But the miner that is making the block that's actually enforcing this rule 00:16:58.930 --> 00:17:02.130 doesn't have to worry about his computer time, only has to worry about what the 00:17:02.130 --> 00:17:03.470 last block is that he's working with. 00:17:03.870 --> 00:17:07.750 Oh, well, that's an interesting detail. So it's not actually checking for the 00:17:07.750 --> 00:17:11.630 time, it's checking for the time based on blocks that have come before it. 00:17:11.710 --> 00:17:14.730 Yeah, and that's exactly to prevent this type of confusion because what if your 00:17:14.730 --> 00:17:16.730 clocks are two seconds different or things like that? 00:17:17.580 --> 00:17:23.020 Oh yeah of course so it's so it uses a derivative of time really yeah okay so 00:17:23.020 --> 00:17:29.020 if I understand correctly CLTV was essentially building on nLockTime 00:17:29.020 --> 00:17:32.320 which we discussed at the start of the episode the first thing we discussed was 00:17:32.320 --> 00:17:37.460 nLockTime and CLTV CheckLockTimeVerify was in fact using that 00:17:37.460 --> 00:17:43.320 CheckSequenceVerify does not use nLockTime it 00:17:43.320 --> 00:17:47.100 instead uses nSequence. 00:17:47.500 --> 00:17:49.040 Yes. This is newly introduced. 00:17:49.200 --> 00:17:54.320 Right. So the nSequence, the sequence that's included in the new input for 00:17:54.320 --> 00:17:59.480 transaction. So if you want to create a new transaction, you have to include an 00:17:59.480 --> 00:18:05.220 nSequence number. And that sequence number has to correspond with the actual time 00:18:05.220 --> 00:18:06.820 or the actual block height. 00:18:07.060 --> 00:18:12.970 The relative time or the relative block height right, relative to when it 00:18:12.970 --> 00:18:13.450 was included 00:18:13.450 --> 00:18:18.810 When the output was being spent? Right okay well that's clear enough for me. I 00:18:18.810 --> 00:18:23.420 hope our listeners are keeping up as well or maybe they're way ahead of me maybe 00:18:23.420 --> 00:18:25.800 they already understood what I'm still trying to figure out… 00:18:25.800 --> 00:18:26.700 It’s fairly confusing. 00:18:26.700 --> 00:18:31.840 So okay so I think I understand that part I think my next question would be 00:18:31.840 --> 00:18:37.680 how then is the time actually embedded in the nSequence how is 00:18:37.680 --> 00:18:40.580 how does this like literally work? 00:18:40.580 --> 00:18:45.560 It's either a number of seconds I think or a number of blocks. 00:18:45.560 --> 00:18:48.640 Okay how do you know which one? How do you know which one? 00:18:48.640 --> 00:18:51.940 Yeah so there's a little trick there there's multiple ways you can do it right so 00:18:51.940 --> 00:18:55.900 we have this field that is left over from the olden days where it had no meaning 00:18:55.900 --> 00:19:00.680 and it was 32 bytes so as an engineer then you have to decide okay we have 32 00:19:00.680 --> 00:19:04.220 bytes and we want to use this for two different things so there are multiple ways 00:19:04.220 --> 00:19:07.900 you can do that I'll just go on a little bit of a tangent because we'll get to a 00:19:07.900 --> 00:19:12.450 certain bug or issue that uses this problem so how would you put that in there 00:19:12.450 --> 00:19:16.070 well one thing you can do is you can say well I want to be able to put in both a 00:19:16.070 --> 00:19:20.750 date and a number both of them so what I'm going to do is I'm going to take two 00:19:20.750 --> 00:19:24.150 bytes and I'm going to reserve that for if you want to put in a date and I'm 00:19:24.150 --> 00:19:26.590 going to use two bytes for a block 00:19:26.590 --> 00:19:29.330 Height… is what you mean? Yeah you want to put in both the data and block height 00:19:29.330 --> 00:19:30.710 you want to use the same number? 00:19:31.280 --> 00:19:36.620 I want to use the same, no, if I wanted to be able to specify both, because a 00:19:36.620 --> 00:19:40.440 script might ask either for a time or for a height, so naively you might say, 00:19:40.500 --> 00:19:43.600 well, I want to be able to do both. Let's just split the four bytes in half and 00:19:43.600 --> 00:19:45.840 use two bytes for one of them and the other two for the other one. 00:19:45.980 --> 00:19:49.760 Right, so if the first two bytes are used, that would mean time, for example, and 00:19:49.760 --> 00:19:51.680 if the other two are used, that would mean block. 00:19:51.860 --> 00:19:55.100 Yeah, or you can use both of them if it means both, right? Maybe you want to 00:19:55.100 --> 00:19:56.480 restrain both time and height. 00:19:57.050 --> 00:19:58.170 Sure. Yeah. Okay. 00:19:58.290 --> 00:20:02.910 But the problem with that approach would be that two bytes only gives you two to 00:20:02.910 --> 00:20:07.850 the power of 16 combinations, and that is about 65,000 00:20:07.850 --> 00:20:13.590 numbers. So that means you could only use it for 65,000 blocks or 65,000 seconds. 00:20:14.110 --> 00:20:17.550 And that 65,000 seconds is about a day. So, so basically it gives you very 00:20:17.550 --> 00:20:21.620 limited options. I mean, you could define it as Instead of seconds, you could say 00:20:21.620 --> 00:20:25.160 it's hours, etc. So you could do it this way, but it's not great. It doesn't give 00:20:25.160 --> 00:20:30.780 you a lot of room. So what you can do instead is you say, I'm going to take the 00:20:30.780 --> 00:20:36.400 first bit of this number. And if the first bit is 0, it means the rest, the other 00:20:36.400 --> 00:20:41.960 31 bits are a date. And if the first bit is a 1, the other 32 bits are a height. 00:20:42.620 --> 00:20:46.900 Then you have 2 to the power of 32 combinations, which is 2 billion different 00:20:46.900 --> 00:20:50.560 numbers that you can put in there. Now, that's actually not how it works because 00:20:50.560 --> 00:20:55.460 what it's using instead is saying if the number is more than 500 million, it is 00:20:55.460 --> 00:20:59.620 interpreted as a date. If the number is less than 500 million, it is interpreted 00:20:59.620 --> 00:21:02.620 as a height. But that's essentially the same. 00:21:02.840 --> 00:21:06.040 Do you know why it doesn't work in the way you explained first? That sounds 00:21:06.040 --> 00:21:06.980 cleaner to me somehow. 00:21:07.540 --> 00:21:08.180 I don't know. 00:21:08.260 --> 00:21:13.550 You don't know? Okay. So if the number is higher than, what did you say, 500,000? 00:21:13.710 --> 00:21:14.690 500 million, I think. 00:21:15.070 --> 00:21:18.310 Then it's a, which is which? 00:21:18.610 --> 00:21:22.710 If it's less than 500 million, it's interpreted as a number of blocks. 00:21:22.910 --> 00:21:23.290 Right. 00:21:23.470 --> 00:21:26.410 And if it's more than 500 million, it's interpreted as a timestamp. 00:21:26.670 --> 00:21:26.890 Okay. 00:21:27.490 --> 00:21:31.030 So yeah, I don't know why they didn't use the first bit. There may be some logic there. 00:21:32.340 --> 00:21:32.780 Right. 00:21:32.780 --> 00:21:36.760 Okay, well, that clears up that part for me. So that's how CheckSequenceVerify 00:21:36.760 --> 00:21:39.240 works. I guess I get that part. 00:21:39.240 --> 00:21:42.060 Yeah, I guess the other thing is, my guess is that it is identical to how 00:21:42.060 --> 00:21:46.440 nLockTime works. And that's just what whatever somebody or Satoshi did in the 00:21:46.440 --> 00:21:51.260 first year, right? To make that particular choice and not do it the other way. 00:21:51.790 --> 00:21:56.990 So CheckSequenceVerify was basically specifically implemented to 00:21:56.990 --> 00:22:02.970 better enable the Lightning network. This was in 2016. Do you 00:22:02.970 --> 00:22:05.210 know why this is better for the Lightning Network? 00:22:05.610 --> 00:22:08.910 Well, because it lets you do relative time locks. So that means that if you're 00:22:08.910 --> 00:22:13.370 opening a channel or closing a channel, whatever, you can say, well, the other 00:22:13.370 --> 00:22:17.830 side can, or if you're making a change inside the channel, you can say the other 00:22:17.830 --> 00:22:22.890 side can get my coins if they give me a pre-image of the hash. And if they don't 00:22:22.890 --> 00:22:26.590 give me a pre-image of the hash, I'm going to, after two weeks, I'm going to take 00:22:26.590 --> 00:22:31.150 my coins back. So it's basically a way to do a quick escrow where you say, either 00:22:31.150 --> 00:22:34.630 give me the pre-image so I can take the coins or I'm going to take the money 00:22:34.630 --> 00:22:37.850 back. Or so you can take the coins or I can take the money back. 00:22:38.510 --> 00:22:40.270 Wasn't it the case that under... 00:22:40.270 --> 00:22:42.610 The hash time lock contract, basically. 00:22:43.090 --> 00:22:48.830 Yeah, wasn't it the case that under CLTV, Lightning channels could only be open 00:22:48.830 --> 00:22:50.890 for a predetermined amount of time? 00:22:51.110 --> 00:22:52.130 Yeah, the problem is... 00:22:52.130 --> 00:22:52.490 Like a year or something? 00:22:52.710 --> 00:22:55.910 Exactly. If you don't use relative locks, you have to decide in advance... 00:22:56.820 --> 00:22:59.700 Basically, for everything in the channel, what's going to happen? You have to put 00:22:59.700 --> 00:23:03.360 actual deadlines in it. So by relative times, you get a lot more flexibility. 00:23:03.780 --> 00:23:06.100 Yeah, you can leave the channel open indefinitely, essentially. 00:23:06.380 --> 00:23:06.780 Yes. 00:23:06.880 --> 00:23:07.420 If you want to. 00:23:07.680 --> 00:23:07.960 Exactly. 00:23:08.360 --> 00:23:09.180 Yeah, okay. 00:23:09.380 --> 00:23:14.200 I think with absolute lock times, if my memory serves, what you would do is you 00:23:14.200 --> 00:23:18.460 would... The first time you make a transaction inside Lightning, because you're 00:23:18.460 --> 00:23:24.220 basically trading transactions with your counterparty, and you don't 00:23:24.220 --> 00:23:27.340 publish them on the blockchain. But those transactions, every time you change the 00:23:27.340 --> 00:23:30.720 channel, have to change a bit. And so I think without relative lock times, you 00:23:30.720 --> 00:23:35.100 would pick a date in the future, you'd say the year 2100, and then you would do 00:23:35.100 --> 00:23:37.960 one transaction, and you'd say, well, this one I can drop on the chain until the 00:23:37.960 --> 00:23:42.440 year 2100. But this new state that we've done or we agreed on, I can drop that on 00:23:42.440 --> 00:23:47.180 the chain until the year 2099. And then we do another one and say, no, I can drop 00:23:47.180 --> 00:23:51.880 this on the chain until 2098. And that way, the last state is the first thing you 00:23:51.880 --> 00:23:54.740 can put in the blockchain. But it's kind of tedious because you have to pick a 00:23:54.740 --> 00:23:57.420 final date and you want to pick that very far in the future. So you can do lots 00:23:57.420 --> 00:24:00.280 of transactions. But then if you want to close the channel, you have to wait 100 00:24:00.280 --> 00:24:03.440 years. So that was the problem with absolute times. 00:24:03.700 --> 00:24:08.940 Right. So that's why we got CheckSequenceVerify since 2016. All right. 00:24:09.360 --> 00:24:12.600 And again, that wasn't enough for Lightning because Lightning also needed SegWit 00:24:12.600 --> 00:24:15.160 to be practical. But it's definitely useful. 00:24:18.180 --> 00:24:24.100 Okay. So we started with nLockTime. Then we had CLTV in 2015. Then we had CSV in 00:24:24.100 --> 00:24:26.500 2016. What's the next time lock? 00:24:26.820 --> 00:24:28.040 There is no next time lock. 00:24:28.280 --> 00:24:29.080 Is it, Sjors? 00:24:29.320 --> 00:24:30.700 I think so, unless I missed something. 00:24:31.310 --> 00:24:36.090 Okay, and there was a bug you wanted to mention. There was something going on 00:24:36.090 --> 00:24:37.630 with CLTV and CSV. 00:24:38.130 --> 00:24:42.890 Yeah, so the folks at Blockstream seem to have discovered this bug, and they 00:24:42.890 --> 00:24:45.530 discovered it while working on Miniscript. And we've done an episode about 00:24:45.530 --> 00:24:50.840 Miniscript, so we won't talk about it here. But basically, you want to be very 00:24:50.840 --> 00:24:56.760 careful that you do not put a time and a 00:24:57.240 --> 00:25:02.760 height in the same script. Either a relative time and relative height or an 00:25:02.760 --> 00:25:05.100 absolute time and an absolute height. Don't combine those two. 00:25:05.200 --> 00:25:06.920 You can't use them both. You have to pick. 00:25:07.160 --> 00:25:11.380 Yeah, you can't use them both. So that means you can have a script like... Let's 00:25:11.380 --> 00:25:14.980