WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:07.380 --> 00:00:10.740 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:10.940 --> 00:00:11.180 Hello. 00:00:11.820 --> 00:00:12.200 Hey, Sjors. 00:00:12.560 --> 00:00:13.060 What's up? 00:00:13.620 --> 00:00:13.940 What's up? 00:00:14.850 --> 00:00:15.370 Not much. 00:00:15.920 --> 00:00:21.280 Not much here either. Our topic today is SIGHASH_NOINPUT. 00:00:22.090 --> 00:00:26.790 Also known as SIGHASH_ANYPREVOUT or SIGHASH_ANYPREVOUTANYSCRIPT 00:00:26.790 --> 00:00:30.830 Yeah I guess it's ANYPREVOUT now I'm just using an old name aren't I? 00:00:30.830 --> 00:00:31.630 You are. 00:00:31.630 --> 00:00:37.010 Yeah I I wrote an article I guess a couple years ago by now and uh even at that 00:00:37.010 --> 00:00:42.830 point ANYPREVOUT was a thing but no input was earlier so I kind of 00:00:42.830 --> 00:00:45.430 decided to go with the no input class. 00:00:45.430 --> 00:00:47.970 It had Lindy because the name was changing all the time. 00:00:47.970 --> 00:00:53.760 So uh yeah, so okay… Sorry, actually, so I guess the episode is about 00:00:53.760 --> 00:00:54.380 ANYPREVOUT. 00:00:54.560 --> 00:00:55.060 That's right. 00:00:56.560 --> 00:01:01.000 And that's a proposed new SIGHASH flag. 00:01:01.480 --> 00:01:01.980 Yep. 00:01:02.850 --> 00:01:08.390 And it's being, I think it was originally, so I guess it was originally 00:01:08.390 --> 00:01:14.130 proposed by Anthony Towns, but it was based on work by 00:01:14.130 --> 00:01:19.180 Christian Decker and Rusty Russell. And even before that, I think it was 00:01:19.180 --> 00:01:20.880 mentioned in the Lightning White Paper. 00:01:22.980 --> 00:01:24.560 Am I saying that right? I think so, right? 00:01:24.620 --> 00:01:26.440 I think so. The BIP says it. 00:01:27.690 --> 00:01:28.630 What's the BIP number? 00:01:29.610 --> 00:01:32.430 BIP number 118, 118. 00:01:32.970 --> 00:01:34.770 Okay. ANYPREVOUT? 00:01:35.390 --> 00:01:39.630 Actually, if you go to BIP 118, you'll find, I think, there's still the 00:01:39.630 --> 00:01:43.910 SIGHASH_NOINPUT. So if you Google around a bit or look in the show notes, 00:01:44.070 --> 00:01:48.870 there'll be a link to a pull request slash branch that is the new version. 00:01:49.400 --> 00:01:51.780 Right, okay, yeah. So just to be clear... 00:01:51.780 --> 00:01:53.460 It's in flux, but that's the new name. 00:01:53.900 --> 00:01:56.060 We're calling it ANYPREVOUT today, I think, right? 00:01:56.340 --> 00:01:56.640 Yes. 00:01:57.360 --> 00:01:59.840 Okay, so it's a new type of SIGHASH flag. 00:02:01.220 --> 00:02:02.700 So what is a SIGHASH flag? 00:02:03.550 --> 00:02:09.450 Okay, so when you sign a Bitcoin transaction, the question is, what are 00:02:09.450 --> 00:02:14.210 you actually signing, right? You're signing a message that says, send coins from 00:02:14.210 --> 00:02:20.050 A to B. And what a SIGHASH flag does is normally you would just sign 00:02:20.050 --> 00:02:25.510 that entire message. So you would sign a message sent from A to B. But 00:02:25.510 --> 00:02:31.310 what you can do with SIGHASH… SIGHASH flags is to 00:02:31.310 --> 00:02:36.670 say, well, I'm going to sign only part of this transaction and leave the rest as 00:02:36.670 --> 00:02:42.050 a blank check, basically. Well, not necessarily a blank check. Because a blank 00:02:42.050 --> 00:02:46.290 check means you can send it to anyone. That's usually not what you would do. But 00:02:46.290 --> 00:02:50.190 the other side might be blank. So you might sign a transaction saying, well, 00:02:50.410 --> 00:02:56.130 here's one Bitcoin from me and send two Bitcoin to 00:02:56.130 --> 00:03:01.700 this other guy. And I'm going to sign that part, 00:03:01.700 --> 00:03:07.340 but I'm going to leave open extra inputs. So I believe that is called 00:03:07.340 --> 00:03:12.470 SIGHASH anyone can spend. No, ANYONECANPAY. 00:03:12.810 --> 00:03:17.950 Yeah, there are a bunch of different SIGHASH flags and the SIGHASH flags specify 00:03:17.950 --> 00:03:23.470 which part of the transaction is actually being signed. And that means that other 00:03:23.470 --> 00:03:26.050 parts of the transaction can potentially be changed. 00:03:26.350 --> 00:03:32.030 That's right. Because remember when you sign the transaction, well, 00:03:32.130 --> 00:03:37.150 that's... Then you can't really change it anymore, right, normally. But if 00:03:37.150 --> 00:03:41.270 somebody else wants to add an input, well, then they would sign their input, but 00:03:41.270 --> 00:03:45.950 now your signature is no longer correct. So you'd have to do another signature, 00:03:45.950 --> 00:03:48.910 which includes their input. And so to prevent that, you have the SIGHASH flags. 00:03:49.190 --> 00:03:53.650 So you sign your input with just saying, only look at my input, and they sign 00:03:53.650 --> 00:03:58.910 their input saying, only look at my input. And then you can basically, anyone can 00:03:58.910 --> 00:04:02.360 combine these transactions. You can combine these inputs and it still works. 00:04:02.700 --> 00:04:07.380 Yeah. I just realized in case there are sort of really beginners listening, the 00:04:07.380 --> 00:04:12.280 thing is that with the cryptographic signature, it's really unique to whatever 00:04:12.280 --> 00:04:17.450 you're signing, while a regular signature just looks the same on every document. 00:04:17.730 --> 00:04:18.130 Yes. 00:04:18.270 --> 00:04:22.090 But in the case of a cryptographic signature, it's very unique to the specific 00:04:22.090 --> 00:04:22.910 thing you're signing. 00:04:23.190 --> 00:04:27.130 Yeah, because it uses a hash. You're signing a hash, essentially. So we talked 00:04:27.130 --> 00:04:33.090 about hashes before. A hash is just a piece of text that you hash. 00:04:33.310 --> 00:04:37.310 And so this piece of text would not include the other inputs, for example, or it 00:04:37.310 --> 00:04:38.410 would include the other inputs. 00:04:38.610 --> 00:04:42.610 Right. So a SIGHASH flag, it specifies which part of a transaction you're 00:04:42.610 --> 00:04:47.470 signing. You can either sign the whole transaction, excluding the signature 00:04:47.470 --> 00:04:52.470 itself in that case. Or you can sign a part of a transaction. 00:04:52.850 --> 00:04:55.910 Well, yeah, you're always signing part of the transaction because you're not 00:04:55.910 --> 00:04:56.950 signing the signature itself. 00:04:57.230 --> 00:05:01.550 Yeah, I guess that's even more accurate. You're just specifying which part of the 00:05:01.550 --> 00:05:06.570 signature you're signing. Okay, then... So there are a bunch of these already, 00:05:06.570 --> 00:05:10.610 and now a new proposal is SIGHASH_ANYPREVOUT. 00:05:10.970 --> 00:05:11.270 Yep. 00:05:11.610 --> 00:05:16.110 So which part of the transaction are you signing in the case of ANYPREVOUT? 00:05:17.280 --> 00:05:20.120 Well, more… more importantly, which parts are you not signing? 00:05:20.120 --> 00:05:21.800 That… that would be another way to ask. 00:05:21.910 --> 00:05:25.080 Right. So, what you're not… what you're usually… what are your… transaction 00:05:25.080 --> 00:05:29.850 always… you know, a transaction always refers to the thing it's spending. So a 00:05:29.850 --> 00:05:32.710 transaction says, I am spending this earlier transaction. 00:05:34.730 --> 00:05:39.730 Well, that's called a prevout. And so with this new flag, you don't sign that 00:05:39.730 --> 00:05:43.960 bit. So basically, somebody else can create a whole new transaction 00:05:43.960 --> 00:05:49.740 and take your signature, and it's pointing to a different original 00:05:49.740 --> 00:05:55.300 transaction, but the signature is still valid. Because the signature does not say 00:05:55.300 --> 00:05:57.160 which other transaction you're spending. 00:05:58.600 --> 00:06:03.880 Yeah let me try to rephrase that: so every transaction has sort of the input 00:06:03.880 --> 00:06:09.760 part, and the output part. The input part refers to a previous transaction and 00:06:09.760 --> 00:06:15.650 then an output part that's that specifies how the coins can be spent again in the 00:06:15.650 --> 00:06:21.570 next transaction. Okay. If you're not signing the input, 00:06:21.770 --> 00:06:27.730 which is the case with ANYPREVOUT, that means the signature doesn't specify to 00:06:27.730 --> 00:06:33.270 which previous transaction it's referring. The signature doesn't. The transaction 00:06:33.270 --> 00:06:38.040 itself still does, of course, but the signature doesn't. The reason, 00:06:38.840 --> 00:06:44.500 let me say if I'm saying this right. Yeah, of course, the signature still 00:06:44.500 --> 00:06:48.280 needs to be valid compared to the previous transaction. 00:06:50.280 --> 00:06:55.700 You're still signing with the public key from that previous transaction. 00:06:55.940 --> 00:07:00.060 Yeah, so to put it another way, I guess, again, is that a transaction input 00:07:00.060 --> 00:07:04.680 refers to a previous transaction. This previous transaction has a script that has 00:07:04.680 --> 00:07:08.400 to be satisfied. And as we talked about, that script could be as simple as give 00:07:08.400 --> 00:07:12.690 me a signature for this public key, but the script could be anything. But for the 00:07:12.690 --> 00:07:15.290 simplicity, we say, okay, the script just wants a signature. 00:07:16.550 --> 00:07:21.300 And now... And so when you're spending a transaction, that's important that 00:07:21.300 --> 00:07:23.720 you're actually satisfying that script. 00:07:24.960 --> 00:07:29.000 But you're also saying this transaction actually needs to point to that original 00:07:29.000 --> 00:07:34.220 transaction. So that's a double thing. It's kind of a double check. You don't 00:07:34.220 --> 00:07:37.560 just satisfy the script. You also make sure that you're pointing to the previous 00:07:37.560 --> 00:07:40.090 transaction. And you don't have to sign that part. 00:07:40.720 --> 00:07:46.520 Yeah, I'll briefly mention why I'm sort of re-explaining this. It's 00:07:46.520 --> 00:07:49.280 because when I was first learning about this... 00:07:49.280 --> 00:07:51.480 I also find this confusing. Don't worry. 00:07:51.500 --> 00:07:56.260 I was incredibly confused about the fact that you could sort of change inputs 00:07:56.260 --> 00:08:01.590 because I figured... How can it be possible? That could mean you can spend 00:08:01.590 --> 00:08:07.150 any coins on the blockchain, but that's not the case. The signature still needs 00:08:07.150 --> 00:08:11.190 to match with the previous transaction, with specific coins that it needs to 00:08:11.190 --> 00:08:14.970 match. With the transaction, it's just that you're not signing the specific 00:08:14.970 --> 00:08:19.960 input. That's sort of the only difference. Am I saying this right now? I think 00:08:19.960 --> 00:08:20.380 so, right? 00:08:21.020 --> 00:08:26.820 Yeah, exactly. So the signature still has to, indeed, you still have to 00:08:26.820 --> 00:08:31.060 satisfy the script. The script says, I want a signature for this public key. You 00:08:31.060 --> 00:08:34.920 have to give it a signature for that public key. But the thing is what Bitcoin is 00:08:34.920 --> 00:08:39.680 doing is really two things with these signatures. One is it's using signatures to 00:08:39.680 --> 00:08:43.640 prove that indeed you have a private key, but it is also using signatures to 00:08:43.640 --> 00:08:44.620 commit to a hash. 00:08:46.520 --> 00:08:50.300 So that's kind of where the confusion comes from. So the committing to a hash is 00:08:50.300 --> 00:08:54.020 the part where you're saying, this signature, when I set it, when I made the 00:08:54.020 --> 00:08:57.640 signature, it can't just be moved around. This really belongs to this specific 00:08:57.640 --> 00:09:00.460 transaction. That's one thing you're doing with the signature. The other thing 00:09:00.460 --> 00:09:03.840 you're doing with the signature is saying, yes, I actually own this private key. 00:09:05.240 --> 00:09:11.160 And so the SIGHASH_ANYPREVOUT proposal does not change that 00:09:11.160 --> 00:09:16.030 first property. You really do have to satisfy whatever condition, which might not 00:09:16.030 --> 00:09:20.150 be any signature. Of course, then it doesn't work, but yeah. 00:09:20.330 --> 00:09:21.570 How do you think it's gone so far? 00:09:22.330 --> 00:09:25.450 I think this is amazing. Everybody totally understands it. Maybe we should 00:09:25.450 --> 00:09:31.390 actually go through a much more practical example of why this is useful, 00:09:31.390 --> 00:09:34.150 and that might even help clarify what it actually is. 00:09:34.330 --> 00:09:38.950 Actually, I have an alternative proposal. Let me first explain the problem with 00:09:38.950 --> 00:09:39.410 this 00:09:42.080 --> 00:09:48.080 with ANYPREVOUT, like a reason how it could go wrong… Okay, that's fine. That 00:09:48.080 --> 00:09:52.580 that helps me understand. So, let's see if it might help others. Okay, so 00:09:53.630 --> 00:09:58.910 let's say someone is reusing an address 00:09:58.910 --> 00:10:04.230 which is recommended against. This is something people shouldn't be doing, but 00:10:04.230 --> 00:10:08.130 let's say you're reusing an address, so you know it's like a donation address or 00:10:08.130 --> 00:10:14.130 something. Okay. People send money to this address. So we're just going 00:10:14.130 --> 00:10:20.050 to use round coins, which are worth an all-time high today, 00:10:20.230 --> 00:10:22.910 I guess, right? $60,000 or whatever. 00:10:23.210 --> 00:10:25.050 I'm sure one Bitcoin is worth one Bitcoin. 00:10:25.410 --> 00:10:26.170 You're right. 00:10:28.600 --> 00:10:34.300 Okay, so I'm receiving Bitcoins on this one address. Now, 00:10:34.500 --> 00:10:38.800 at some point, I decide to spend one of these Bitcoins. 00:10:41.320 --> 00:10:47.230 And I do it using ANYPREVOUT. Which is a problem. Or it was 00:10:47.230 --> 00:10:51.090 an even bigger problem for no input for very technical reasons, I think. But 00:10:51.090 --> 00:10:56.530 let's ignore that. Okay, now I'm sending this coin to you, Sjors. So I'm 00:10:56.530 --> 00:10:59.250 signing the transaction, but not the input. 00:11:00.450 --> 00:11:06.110 The transaction is still valid. It's a valid signature from my Bitcoin. And 00:11:06.110 --> 00:11:10.970 the transaction is valid. All the scripts are satisfied. So you get that Bitcoin. 00:11:11.290 --> 00:11:16.370 However, what you can do now... Is you can copy the transaction and 00:11:16.630 --> 00:11:21.850 so now there are two transactions and they look exactly the same and you 00:11:21.850 --> 00:11:27.810 swap in another one of my coins from itself at the same address. 00:11:27.810 --> 00:11:28.170 Yep. 00:11:28.850 --> 00:11:34.050 And also transmit that to the blockchain. And that will confirm as well. So now 00:11:34.050 --> 00:11:38.010 all of a sudden, even though I sent you only one transaction, you were able to 00:11:38.010 --> 00:11:43.830 claim two coins. And the reason both of them are valid is because 00:11:43.830 --> 00:11:49.490 they're both secured by the same private key. So the signature matches. And I'm 00:11:49.490 --> 00:11:54.480 only signing the part of the transaction. That doesn't include the input, so the 00:11:54.480 --> 00:11:55.500 inputs can be swapped. 00:11:56.140 --> 00:12:01.220 Yeah, or to reverse this argument is why do transactions commit to their input in 00:12:01.220 --> 00:12:04.760 the first place? Why do signatures commit to the input in the first place? That's 00:12:04.760 --> 00:12:05.480 to prevent this. 00:12:05.820 --> 00:12:06.040 Right. 00:12:06.660 --> 00:12:10.080 Because, of course, [unclear], you know, it's… it's impossible to prevent. 00:12:11.280 --> 00:12:17.130 Yeah, so that's sort of... For me, this is how I understood 00:12:17.130 --> 00:12:22.210 it. This was what I needed to hear, to understand. So maybe this would have 00:12:22.210 --> 00:12:23.390 helped someone else by now. 00:12:23.550 --> 00:12:28.850 Yeah, so maybe now some of our listeners are jumping with the Eureka and others 00:12:28.850 --> 00:12:29.870 may still be confused. 00:12:30.250 --> 00:12:35.470 That's almost certainly going to be the case. Okay, now let's get to an example 00:12:35.470 --> 00:12:40.910 where this actually is useful, which is why we're discussing this. And I think 00:12:40.910 --> 00:12:44.370 the most obvious example... Is eltoo. 00:12:44.370 --> 00:12:44.990 Yep. 00:12:44.990 --> 00:12:50.950 Which is a confusing name in itself. It's uh, to explain that real brief, it's 00:12:50.950 --> 00:12:55.990 just a new Lightning network version protocol. 00:12:55.990 --> 00:13:01.490 Yeah it's spelled E-L-T-O-O, right? It's pronounced as L2. 00:13:02.360 --> 00:13:07.800 Which also means Layer 2. Exactly. And it is also a Layer 2 thing. It's 00:13:07.800 --> 00:13:08.200 brilliant. 00:13:10.220 --> 00:13:14.200 Eltoo, you could arguably say that it is a simplification of the Lightning 00:13:14.200 --> 00:13:19.930 Protocol. Exactly, yeah. So the Lightning Protocol exists. I think most [unclear] 00:13:19.930 --> 00:13:24.530 will know that. And eltoo is a proposed simplification of it. 00:13:24.750 --> 00:13:26.550 Yeah, and it uses this new technology. 00:13:26.770 --> 00:13:32.230 Yeah, and I think the main benefit of it is... 00:13:32.580 --> 00:13:37.140 You can correct me if I'm... No, I'm pretty sure I'm right, actually. The main 00:13:37.140 --> 00:13:43.100 benefit is that it's... Right now, the way Lightning works is it uses 00:13:43.100 --> 00:13:45.020 something called penalty transactions. 00:13:45.400 --> 00:13:45.560 Yep. 00:13:46.090 --> 00:13:49.910 And it means that both parties in a payment channel, 00:13:50.090 --> 00:13:56.070 they're both stacking up 00:13:56.070 --> 00:14:01.690 unconfirmed transactions, basically. If one of them sends an old transaction, so 00:14:01.690 --> 00:14:07.650 an old channel state, then that allows the other channel partner to use 00:14:07.650 --> 00:14:12.840 their penalty transaction to claim all coins from the channel. So that keeps 00:14:12.840 --> 00:14:17.640 everyone honest. That ensures that everyone, both parties in the channel, will 00:14:17.640 --> 00:14:23.550 only ever broadcast the latest channel state. The problem is 00:14:23.550 --> 00:14:29.400 that sometimes... Code is buggy, or you know, 00:14:29.400 --> 00:14:34.860 someone accidentally messed up a backup of his wallet or something, 00:14:34.860 --> 00:14:40.680 happens that wasn't you know, ill intended. It was just a small accident, 00:14:40.680 --> 00:14:46.620 and now all of a sudden all that person's coins are gone so eltoo offers a 00:14:46.620 --> 00:14:49.430 solution that isn't so harsh. 00:14:49.910 --> 00:14:53.650 Yeah, basically there's two problems, right? One is that you have to hold on to a 00:14:53.650 --> 00:14:58.810 lot of material. If the other side is cheating, then you have to remember a lot 00:14:58.810 --> 00:15:01.410 of different things to make sure that you can actually punish them when they're 00:15:01.410 --> 00:15:06.470 cheating. And the other is if you have toxic waste, as it's called. So if you 00:15:06.470 --> 00:15:11.650 accidentally publish any of that material too early or at the wrong time, maybe 00:15:11.650 --> 00:15:15.430 because you lost an update and you think you have the latest state. You will lose 00:15:15.430 --> 00:15:19.530 all your money. So it's scary in both directions. You have to remember a lot of 00:15:19.530 --> 00:15:22.510 stuff, otherwise you lose your money. You have to not leak a lot of stuff, 00:15:22.630 --> 00:15:23.490 otherwise you lose your money. 00:15:23.690 --> 00:15:27.910 Right, yeah. So these are some complications with the current Lightning protocol. 00:15:28.250 --> 00:15:33.330 So eltoo is a proposal to simplify and improve on this. 00:15:33.750 --> 00:15:34.750 Yeah, much easier. 00:15:34.910 --> 00:15:35.730 Do you want to give it a go? 00:15:36.090 --> 00:15:41.890 Yeah, I'll try. So in both protocols, the first step is both parties put 00:15:41.890 --> 00:15:44.330 some money into a multisig address. 00:15:46.300 --> 00:15:52.160 And then before they do that, so they'll draft it. But 00:15:52.160 --> 00:15:55.200 before they actually sign that and put it on a blockchain, they make a 00:15:55.200 --> 00:16:00.000 transaction that takes it out of the multisig address or at least that 00:16:00.000 --> 00:16:01.280 redistributes it. 00:16:02.540 --> 00:16:06.660 And that is called basically the settlement transaction. So yeah, you're taking 00:16:06.660 --> 00:16:07.880 it out of the multisig address. 00:16:09.080 --> 00:16:13.960 And then once you've signed... The way out, you publish the way in so that you 00:16:13.960 --> 00:16:16.860 know for sure that the coins are going to come out to you. That's the first step. 00:16:18.790 --> 00:16:22.770 Yeah, so let's say we're both going to put 10 coins into a Lightning channel. 00:16:23.010 --> 00:16:25.990 You really like these very large channels. All right. 00:16:27.010 --> 00:16:32.530 Then the first settlement transaction, am I saying it right? I get confused about it. 00:16:32.530 --> 00:16:35.650 Yeah, the funding transaction puts 10 Bitcoin in, 10 Bitcoin out, and the 00:16:35.650 --> 00:16:40.210 settlement transaction takes 10 Bitcoin out. For each of us. 00:16:40.310 --> 00:16:41.030 Yeah, exactly. 00:16:41.250 --> 00:16:47.070 Back where we started. Now, if we wanted to start using this channel, what we 00:16:47.070 --> 00:16:52.040 do is we have this thing called an update transaction. And this update 00:16:52.040 --> 00:16:54.920 transaction, and now we're just talking about eltoo, but Lightning works 00:16:54.920 --> 00:16:55.380 similarly. 00:16:56.800 --> 00:17:01.240 The update transaction just says, okay, now nine Bitcoins go to me and 11 00:17:01.240 --> 00:17:02.960 Bitcoins go to you or the other way around. 00:17:03.200 --> 00:17:07.440 Yeah, that meant you gave me a payment. You made a payment of one Bitcoin to me. 00:17:07.680 --> 00:17:12.140 Exactly. And at the same time we do that, we also, at least in this eltoo 00:17:12.140 --> 00:17:16.760 protocol, we also create a new settlement transaction. That takes the money out 00:17:16.760 --> 00:17:20.340 of that update transaction and really gives it back. So it's kind of a double 00:17:20.340 --> 00:17:20.820 transaction. 00:17:22.040 --> 00:17:25.900 So, yeah, an update transaction and a settlement transaction. 00:17:26.360 --> 00:17:26.720 Right. 00:17:26.960 --> 00:17:32.910 And then we make more payments. For every time we make a new payment, we create a 00:17:32.910 --> 00:17:37.010 new update transaction. We do not send it to the blockchain. But here's the 00:17:37.010 --> 00:17:41.250 magic. Whereas with Lightning, you have to remember all of these. With eltoo, you 00:17:41.250 --> 00:17:46.760 only have to remember the most recent one. So that means that if you 00:17:46.760 --> 00:17:51.950 publish an older update transaction, then I can simply publish 00:17:51.950 --> 00:17:57.660 a more recent update transaction and then the final settlement transaction. 00:17:58.580 --> 00:18:02.440 So there's no punishment, but there's also no toxic material. 00:18:03.320 --> 00:18:08.880 Right. Yeah. So you could argue that this 00:18:08.880 --> 00:18:14.740 is already possible under the current Bitcoin protocol in a way. Uh 00:18:14.740 --> 00:18:18.980 in a complicated way, in a not useful way, but I'm just going to explain real 00:18:18.980 --> 00:18:24.560 brief, to understand the idea. So the idea then is 00:18:24.560 --> 00:18:29.920 um we have transaction number one transaction number two transaction number three 00:18:29.920 --> 00:18:35.630 you know these are all updates going up to transaction 100 That's the most 00:18:35.630 --> 00:18:41.250 recent channel state. Now, at some point, you try to cheat on me and 00:18:41.250 --> 00:18:46.170 you broadcast transaction 13 to the blockchain because that 00:18:46.170 --> 00:18:51.450 was the point in time where you owned most of the channel. 00:18:51.750 --> 00:18:56.330 Now, the way for me to counter that in a naive way is to 00:18:56.840 --> 00:19:02.830 then broadcast transaction number 14, which sends 00:19:02.830 --> 00:19:06.150 the... Did we cover this already? Am I skipping ahead? 00:19:07.090 --> 00:19:07.570 No, that's fine. 00:19:09.510 --> 00:19:15.420 Transaction 13 sends coins to transaction number 14, and then I broadcast 00:19:15.420 --> 00:19:20.160 transaction number 15 and 16, and I do this all the way until 100, until we get 00:19:20.160 --> 00:19:23.290 to the honest point of the channel. 00:19:23.690 --> 00:19:23.810 Yeah. 00:19:24.130 --> 00:19:30.130 So that would be my way to counter. Your attempted theft is to just publish 00:19:30.130 --> 00:19:35.030 everything that happened on the channel so the blockchain will sort of run its 00:19:35.030 --> 00:19:40.930 course and I get my money. Yeah, what eltoo does is it says okay, 00:19:40.930 --> 00:19:46.110 you don't need to publish all 87 newer transactions 00:19:46.110 --> 00:19:51.430 any newer transaction will do. So you transmit 00:19:51.430 --> 00:19:53.970 transaction number, what was my example, 13? 00:19:54.290 --> 00:19:54.690 Yep. 00:19:55.130 --> 00:20:00.790 You broadcast transaction number 13, and then I immediately broadcast 00:20:00.790 --> 00:20:05.310 transaction number 100, and now the blockchain will check, yep, 100 is newer than 00:20:05.310 --> 00:20:06.530 13, so it's valid. 00:20:07.010 --> 00:20:10.250 Exactly. So you do not have to broadcast all the intermediate update 00:20:10.250 --> 00:20:13.770 transactions. And then, of course, the question is, was that possible? 00:20:13.790 --> 00:20:19.190 What could also happen is you try to cheat with number 13, And my highest, 00:20:19.530 --> 00:20:25.410 you know, my most beneficial state was 67. So I tried to counter 00:20:25.410 --> 00:20:30.050 with 67. But then you, after that, you know, okay, let's settle on 100 and then 00:20:30.050 --> 00:20:30.870 you broadcast 100. 00:20:31.150 --> 00:20:31.610 Yes. 00:20:31.750 --> 00:20:35.430 We'll always get to the most honest state probably as long as we're both paying 00:20:35.430 --> 00:20:35.870 attention. 00:20:36.110 --> 00:20:37.310 Yeah, to the last state. Exactly. 00:20:37.650 --> 00:20:38.150 The last state. 00:20:38.150 --> 00:20:44.120 So there's a little gotcha there with this publishing. There's a time limit. So 00:20:44.120 --> 00:20:49.840 when you cheat, I have so-and-so many blocks to respond to that. 00:20:49.980 --> 00:20:54.520 And that's because every transaction essentially has a switch statement in it 00:20:54.520 --> 00:21:00.180 where it says there's two possibilities. Either you wait 100 blocks, 00:21:00.180 --> 00:21:06.130 and then you can take the money, or you actually 00:21:06.130 --> 00:21:09.470 show me a new update transaction, which you can do immediately. 00:21:10.680 --> 00:21:14.660 So if we're at update number 13, if I have update number 14, I can just put that 00:21:14.660 --> 00:21:17.580 on the chain immediately. But if I actually want to take the money out of the 00:21:17.580 --> 00:21:21.800 update transaction with a settlement, then I have to wait 100 blocks. And this 00:21:21.800 --> 00:21:25.560 guarantees or basically says that, you know, you can try to cheat, but I'm just 00:21:25.560 --> 00:21:28.380 going to publish the new version and the new version and the new version. And I 00:21:28.380 --> 00:21:31.840 can always do that immediately. Whereas, you know, if you want to take the money 00:21:31.840 --> 00:21:35.360 out, you have to wait. That's still with the original protocol. And that's 00:21:35.360 --> 00:21:40.040 actually the same with eltoo. But now the question is, what is the magic that 00:21:40.040 --> 00:21:43.260 lets us skip these intermediate transactions? 00:21:45.020 --> 00:21:50.480 Yeah, so to first... Very briefly reiterate this, the benefits of using this 00:21:50.480 --> 00:21:55.480 system is that we don't need to store all the other transactions. We just publish 00:21:55.480 --> 00:22:00.640 the latest one, and we're not punishing the counterparty too severely, because 00:22:00.640 --> 00:22:04.600 we're just going to the latest state and we both get what we deserved. We both 00:22:04.600 --> 00:22:06.600 get our latest channel… 00:22:06.600 --> 00:22:11.100 Yeah, and there's also there's no toxic waste right? Um… 00:22:11.760 --> 00:22:17.540 Okay, so I think that makes it clear what eltoo is, at least for some listeners, 00:22:17.560 --> 00:22:22.880 hopefully. And I think, hopefully, for some reason, listeners, it was 00:22:22.880 --> 00:22:28.840 clear what ANYPREVOUT was. So I think now the last 00:22:28.840 --> 00:22:32.780 step is to sort of connect. How does ANYPREVOUT actually make eltoo possible? 00:22:33.220 --> 00:22:38.420 Yeah, because normally when I, you know, you published version number 13. 00:22:39.290 --> 00:22:44.730 And we previously signed update number 14. And when we signed update number 14, 00:22:45.030 --> 00:22:48.850 well, we only knew about number 13. So we created the transaction that referred 00:22:48.850 --> 00:22:54.550 to number 13. The signature was committing to the hash. Sorry, it was committing 00:22:54.550 --> 00:23:00.440 to that specific input. And so what this ANYPREVOUT thing lets us do is 00:23:00.440 --> 00:23:05.200 we say we don't commit to this specific input anymore. We just say that any 00:23:05.200 --> 00:23:10.930 transaction that looks like this, we can spend. And it gets even better 00:23:10.930 --> 00:23:16.550 because, well, yeah, I think that would be the first step to 00:23:16.550 --> 00:23:22.150 explain. So that means that update 15 will work, update 16 will work. Basically, 00:23:22.250 --> 00:23:27.330 any of them will work because we're actually skipping two things. That is 00:23:27.330 --> 00:23:31.490 important to say now, I think. We are not committing to the previous transaction. 00:23:31.710 --> 00:23:36.150 We are also not committing to the script that we're spending. So these 00:23:36.150 --> 00:23:36.790 transactions... 00:23:38.070 --> 00:23:41.530 These update number 13 and 14 and 15, they all pay to a slightly different 00:23:41.530 --> 00:23:46.700 script. And I can spend from them all, as long as I can satisfy that script, that 00:23:46.700 --> 00:23:50.500 is. This is very powerful, but there's a problem. And I think you can guess what 00:23:50.500 --> 00:23:51.040 the problem is. 00:23:53.070 --> 00:23:56.090 I cannot guess what the problem is you have in mind right now. 00:23:56.250 --> 00:24:02.040 So if transaction number 13 is on the blockchain and I want 00:24:02.040 --> 00:24:07.220 to spend it, and we've signed this transaction number 13 to say you can spend 00:24:07.220 --> 00:24:07.920 this with... 00:24:10.090 --> 00:24:14.770 Basically, you don't have to commit to the script and you don't have to commit to 00:24:14.770 --> 00:24:19.750 the input. So that means I can put any update transaction on top of that, 00:24:20.560 --> 00:24:22.180 including earlier ones. 00:24:22.360 --> 00:24:23.540 Right, sure. Okay, sure. 00:24:23.940 --> 00:24:29.300 So that's not good. And this is why the 00:24:30.710 --> 00:24:36.570 input script actually uses a little trick itself, which is to commit 00:24:36.570 --> 00:24:40.910 to a block height. Not a block height, but just to a number, to an nVersion. 00:24:41.130 --> 00:24:41.530 Right. 00:24:41.920 --> 00:24:46.660 Is it [unclear]… nSequence, sorry. So basically what it is, what the input 00:24:46.660 --> 00:24:50.180 script… because remember, we don't have to commit to the input script, but we do 00:24:50.180 --> 00:24:55.180 have to satisfy the input script. That's a little tricky confusion there. So we 00:24:55.180 --> 00:24:58.260 can't just take any… any coins we want. We do actually have to satisfy the 00:24:58.260 --> 00:25:02.100 script. And what the script says is, well, your sequence number must be higher 00:25:02.100 --> 00:25:07.890 than this… Must be high… Say, must be higher than 13. And so the only way my 00:25:07.890 --> 00:25:11.200 sequence number can be higher than 13 is you know, if it's… if it's a newer 00:25:11.200 --> 00:25:16.760 update. So, this is how we guarantee… how eltoo guarantees that you can only 00:25:16.760 --> 00:25:21.310 spend… you can only publish a newer version. Otherwise, you keep going in 00:25:21.310 --> 00:25:26.970 circles. Because you would publish 13, I would publish 5, you would publish 00:25:26.970 --> 00:25:32.870 20, and I would go back to 18. No, you have to go up because of this trick. And 00:25:32.870 --> 00:25:38.750 then basically... So the update transactions don't commit to the input 00:25:38.750 --> 00:25:42.150 and they don't commit to the script, whereas the settlement transaction, which 00:25:42.150 --> 00:25:45.450 there's one settlement transaction for every update transaction that we signed at 00:25:45.450 --> 00:25:51.350 the same time, this commits to specifically one input. It 00:25:51.350 --> 00:25:53.450 does commit to one script. 00:25:54.690 --> 00:25:59.190 So it commits to the script that says, well, it has to be number 14 or it has to 00:25:59.190 --> 00:25:59.730 be number 20. 00:26:03.070 --> 00:26:05.150 So this should make your head spin a little bit. 00:26:07.430 --> 00:26:13.430 I understand it, but even for me, it gets pretty complex with these kinds of 00:26:13.430 --> 00:26:16.010 topics, doesn't it, Sjors? Or is it just me? 00:26:16.230 --> 00:26:20.050 No, no, it quickly does. I have to say, actually, I've read the eltoo proposal 00:26:20.050 --> 00:26:23.630 several times in the last few years, and I think I understand it better today 00:26:23.630 --> 00:26:28.760 than I did yesterday. So this will take some iterations and it's quite hard to 00:26:28.760 --> 00:26:29.620 explain over audio. 00:26:29.940 --> 00:26:34.220 Yeah, it is. One of the takeaways, and maybe this is obvious for some and maybe 00:26:34.220 --> 00:26:39.800 it's not for others, but one of the reasons this works, 00:26:40.020 --> 00:26:45.520 especially in the context of something like Lightning or eltoo, is that each 00:26:45.520 --> 00:26:50.460 update transaction needs the same signature because the coins are always stuck in 00:26:50.460 --> 00:26:54.770 the same multi-address. That's always what you're spending. So it always needs 00:26:54.770 --> 00:26:59.390 the same signature. So therefore, if you can just swap the inputs, you can keep 00:26:59.390 --> 00:26:59.870 updating. 00:27:01.700 --> 00:27:06.730 Yeah, pretty much. Exactly. So we've made the signature once when we updated the 00:27:06.730 --> 00:27:10.570 channel, and then we assume we might not see each other again. So that signature 00:27:10.570 --> 00:27:14.370 still has to be valid. And now that's good because I can actually tweak the 00:27:14.370 --> 00:27:18.510 transaction to point to our newer state. And even that newer state, even though 00:27:18.510 --> 00:27:21.170 that newer state has a different script because it requires a higher version 00:27:21.170 --> 00:27:26.590 number, and that requirement is in the script, I can still do that. Because the 00:27:26.590 --> 00:27:32.130 real cool thing is not just SIGHASH_ANYPREVOUT, so any previous input. It is 00:27:32.130 --> 00:27:38.110 SIGHASH_ANYPREVOUTANYSCRIPT. So I can, yeah, I can change everything. 00:27:38.270 --> 00:27:39.690 Well, not everything, those things. 00:27:41.420 --> 00:27:45.980 Okay, do you think that covers that part? 00:27:46.840 --> 00:27:52.660 Did we just cover how eltoo is enabled by ANYPREVOUT? 00:27:52.800 --> 00:27:53.580 I think we did. 00:27:53.940 --> 00:27:59.500 Okay, then I want to briefly get into the watchtower part because that's another 00:27:59.500 --> 00:28:01.280 big benefit of... 00:28:02.570 --> 00:28:05.070 ANYPREVOUT and eltoo itself right? 00:28:05.070 --> 00:28:09.330 Yeah, it sounds to me like you would not have to store as much stuff when you're 00:28:09.330 --> 00:28:10.070 building a watchtower. 00:28:10.070 --> 00:28:15.750