WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.780 --> 00:00:26.180 Live from Zurich, this is Bitcoin Explained. And with me today is not Aaron, 00:00:26.560 --> 00:00:28.260 again, it's Christian Decker. 00:00:28.640 --> 00:00:30.060 Hey, thank you for having me. 00:00:30.360 --> 00:00:33.840 Well, but nice, this small city, you're just here and you meet all these people. 00:00:35.680 --> 00:00:40.900 Yeah, so we're actually going to do sort of a retake of episode 35, 00:00:40.900 --> 00:00:46.520 in which we talked about SIGHASH ANYPREVOUT and eltoo. So if you want to prepare 00:00:46.520 --> 00:00:49.900 for this episode, you could listen to it, but you don't have to, because we're 00:00:49.900 --> 00:00:50.900 just going to explain it again. 00:00:51.200 --> 00:00:54.180 It's an excellent episode, by the way, so go listen to it. 00:00:54.360 --> 00:00:59.180 Okay, but I figured it's good if we have the expert and also the latest state of 00:00:59.180 --> 00:01:03.350 things. Yeah, before the episode, we were trying to figure out what we want to do 00:01:03.350 --> 00:01:07.730 first. If we want to talk about eltoo first, or if we want to talk about SIGHASH 00:01:07.730 --> 00:01:12.510 ANYPREVOUT, without even explaining what eltoo is. And my guess is the listener 00:01:12.510 --> 00:01:15.910 will be more motivated to understand SIGHASH ANYPREVOUT if they know what it's 00:01:15.910 --> 00:01:21.800 useful for. At least that tends to motivate me. So maybe, is that a good idea? 00:01:22.100 --> 00:01:22.900 Yeah, absolutely. 00:01:24.260 --> 00:01:29.340 SIGHASH_ANYPREVOUT, is basically what SIGHASH NOINPUT became 00:01:29.340 --> 00:01:34.900 after a couple of iterations of improving it. And SIGHASH 00:01:34.900 --> 00:01:40.100 NOINPUT was actually proposed by Joseph and Taj in the original lightning paper. 00:01:40.260 --> 00:01:41.080 I did not know that. 00:01:41.520 --> 00:01:46.980 And all I really did was pick up the idea and... 00:01:47.020 --> 00:01:52.840 basically run with it. And I wrote the BIP proposal, which then 00:01:52.840 --> 00:01:58.740 AJ wrote up. And it turns out that it enables quite a few interesting 00:01:58.740 --> 00:02:04.260 use cases that we currently cannot do on Bitcoin itself. And a whole 00:02:04.260 --> 00:02:10.080 bunch of other improvements were later proposed as 00:02:10.080 --> 00:02:14.060 alternatives or building on top of SIGHASH NOINPUT. 00:02:16.140 --> 00:02:21.900 The basic idea of eltoo is basically that in Lightning 00:02:21.900 --> 00:02:27.280 we have this mechanism where we penalize misbehavior. And we do so quite heavily. 00:02:27.580 --> 00:02:33.420 So if I have a channel with you and then I basically go 00:02:33.420 --> 00:02:37.340 back, then I give you the opportunity of stealing the entirety of my funds. 00:02:37.720 --> 00:02:37.900 Yeah. 00:02:38.280 --> 00:02:44.000 And so that has a whole bunch of implications. So for example, it makes it really 00:02:44.000 --> 00:02:49.830 hard for me to create backups and... and restore, because restoring 00:02:49.830 --> 00:02:55.650 basically means that I would go back in our history of agreements and I would 00:02:55.650 --> 00:02:56.950 then inadvertently cheat. 00:02:57.190 --> 00:03:00.810 Right, because restoring is indistinguishable from cheating, right? 00:03:01.050 --> 00:03:01.510 Exactly. 00:03:02.190 --> 00:03:07.150 So maybe a quick rehash of the Lightning channels, right? So what you do is you 00:03:07.150 --> 00:03:12.390 put coins into a shared address, so to speak, in a multisig address once, and 00:03:12.390 --> 00:03:15.790 then you also have a transaction that takes it out in the same distribution as 00:03:15.790 --> 00:03:19.630 how it went in. And then that transaction that takes it out, you're not putting 00:03:19.630 --> 00:03:23.090 that on the blockchain. You're holding on to that. And you're updating that 00:03:23.090 --> 00:03:25.910 between the two parties so that I can shift some money to you and you can shift 00:03:25.910 --> 00:03:29.190 some money to me. And every time we do that, we create a new transaction, which 00:03:29.190 --> 00:03:33.040 is a real Bitcoin transaction. But the fundamental problem that was very hard to 00:03:33.040 --> 00:03:38.060 solve is that, well, they're all real transactions. So how do you, the blockchain 00:03:38.060 --> 00:03:41.720 has no preference about which one it is. And I think Satoshi first tried to deal 00:03:41.720 --> 00:03:45.120 with that by having sequence numbers and just saying, well, the most recent 00:03:45.120 --> 00:03:49.940 sequence number is the one that's valid. But it turns out that miners can just 00:03:49.940 --> 00:03:55.780 ignore the sequence number. And also it requires you to be really quickly, 00:03:55.780 --> 00:04:00.900 I think, because if... So you have the mempool where somebody cheats, they put 00:04:00.900 --> 00:04:05.640 something in the mempool, and then it goes into a block, unless somebody else 00:04:05.640 --> 00:04:10.460 broadcasts a competing transaction that would go into the block. So if I were to 00:04:10.460 --> 00:04:15.800 cheat and you were to try and send the real one, but my transaction is confirmed 00:04:15.800 --> 00:04:20.920 in two seconds because I got lucky, then I just won. And you cannot undo what's 00:04:20.920 --> 00:04:22.960 already in a block. That would be very expensive. 00:04:23.540 --> 00:04:29.440 Exactly. So, yeah, the original nSequence scheme already contains the basic idea, 00:04:29.580 --> 00:04:34.320 right? Quickly iterating over what a transaction looks like and 00:04:34.320 --> 00:04:40.320 renegotiating what the distribution of funds is at the end of the lifetime of 00:04:40.320 --> 00:04:46.130 our channels. and basically having later versions override what prior 00:04:46.130 --> 00:04:50.850 versions were doing. With nSequence, it was replacing the entire transaction. 00:04:51.490 --> 00:04:57.250 And that turned out to be hard, not just from the user perspective, but 00:04:57.250 --> 00:05:02.110 there also is no way for us to prove that a miner... 00:05:03.030 --> 00:05:08.830 ignored a later sequence number because there is no sort of global knowledge 00:05:08.830 --> 00:05:13.390 that a later sequence number was even available when the miner mined their 00:05:13.390 --> 00:05:18.110 blocks. And so it's really hard to prove anything when you work with nSequence 00:05:18.110 --> 00:05:23.170 numbers. So miners could get incentivized to actually renege on this social 00:05:23.170 --> 00:05:27.340 contract of always using the latest sequence numbers. By basically me approaching 00:05:27.340 --> 00:05:31.420 them and saying, telling them, hey, I give you like 10% of whatever I'm about to 00:05:31.420 --> 00:05:36.300 steal from this guy. If instead you confirm an older version, right? 00:05:36.720 --> 00:05:36.980 Yeah. 00:05:37.400 --> 00:05:43.240 And the way that we later solve this in Lightning Penalty is 00:05:43.240 --> 00:05:47.120 exactly by basically allowing the 00:05:47.120 --> 00:05:52.600 settlement to be sort of split in two parts, right? There is the 00:05:52.600 --> 00:05:56.860 initial settlement where we send one of our 00:05:56.860 --> 00:06:02.320 agreements where we don't know yet whether it's the latest one or not to the 00:06:02.320 --> 00:06:08.200 blockchain. We allow it to be confirmed. And then we basically have a 00:06:08.200 --> 00:06:14.120 period where we allow the counterparty to react if we misbehaved, to basically 00:06:14.120 --> 00:06:19.720 present proof of that misbehavior to the blockchain, which in our case acts a bit 00:06:19.720 --> 00:06:25.460 like a judge. And when we present proof of this 00:06:25.460 --> 00:06:31.460 misbehavior, then we are allowed by the blockchain, the judge, to actually grab 00:06:31.460 --> 00:06:33.100 the funds from our counterparty. 00:06:33.710 --> 00:06:37.990 Yeah, which is, you know, I still think that's a pretty cool mechanism, at least 00:06:37.990 --> 00:06:42.010 to solve this particular problem. But it turns out there is a better way. 00:06:42.860 --> 00:06:46.330 Yeah, so, well, it's a different way. 00:06:47.570 --> 00:06:53.010 I don't know if it's strictly better, but I like it a bit more 00:06:53.010 --> 00:06:57.690 because it's sort of, it feels more correct to me. 00:06:58.960 --> 00:07:04.680 And the idea here is instead of having basically you misbehave and I 00:07:04.680 --> 00:07:09.360 punish you, I can basically go and 00:07:09.360 --> 00:07:15.040 present proof that there is a later state. There is a later 00:07:15.040 --> 00:07:20.200 agreement that we had and I can 00:07:20.200 --> 00:07:21.100 basically... 00:07:23.200 --> 00:07:29.160 present that to the judge, and then instead of the old revoked one, we are 00:07:29.160 --> 00:07:30.480 now working with the newer one. 00:07:31.180 --> 00:07:35.260 Right, so instead of there's no punishment there, you're just updating, you're 00:07:35.260 --> 00:07:36.500 just putting up a newer version. 00:07:36.880 --> 00:07:40.740 Exactly, so my basically correction is actually 00:07:40.740 --> 00:07:46.180 rectifying the misbehavior or the 00:07:46.180 --> 00:07:52.120 disagreement that we had, and we actually... move forwards towards the latest uh 00:07:52.120 --> 00:07:53.240 agreement that we had 00:07:53.240 --> 00:07:57.720 right and and you can skip any of the intermediate steps too right all you need 00:07:57.720 --> 00:07:58.880 to know is that it's more recent 00:07:58.880 --> 00:08:04.400 exactly and the the skipping part here is is the key to this whole puzzle where 00:08:04.400 --> 00:08:09.720 the ANYPREVOUT and NOINPUT and all of these proposals now come in um 00:08:09.720 --> 00:08:15.060 and uh that that allow us to make all of this basically really efficient 00:08:15.470 --> 00:08:19.870 Right, because in the original protocol, you have to, like this punishment 00:08:19.870 --> 00:08:23.810 transaction, you have to remember it for every previous state. Or not the whole 00:08:23.810 --> 00:08:27.310 transaction, but some sort of punishment secret for every previous state, even if 00:08:27.310 --> 00:08:30.750 you've done like a million transactions on your channel. You need to remember a 00:08:30.750 --> 00:08:34.590 million different ways that you can punish your opponent if they broadcast any of 00:08:34.590 --> 00:08:39.150 those earlier ones. And now with this magic that we'll explain in a bit, you 00:08:39.150 --> 00:08:43.310 don't. You just need to make sure you have the most recent one or a fairly recent 00:08:43.310 --> 00:08:47.610 one. in case of a backup like of course if it's not the most recent one it might 00:08:47.610 --> 00:08:51.070 not completely work to your advantage but it's okay if you lose some and it's 00:08:51.070 --> 00:08:55.740 okay if you broadcast one that's not super old so you don't get punished And you 00:08:55.740 --> 00:08:58.680 don't have to hold on to a whole bunch of state very carefully. 00:08:58.960 --> 00:09:04.620 Exactly. So the issue is that if we want to prove to the judge that a specific 00:09:04.620 --> 00:09:09.900 agreement was wrong, we have to have a tailor-made basically 00:09:09.900 --> 00:09:15.040 proof for that being wrong. And that is where the entire sort of 00:09:15.040 --> 00:09:20.840 idea comes from of having to remember every single revoked state in 00:09:20.840 --> 00:09:26.460 eternity until the channel is closed. that is a major downside of lightning 00:09:26.460 --> 00:09:31.620 penalty because you suddenly have to be able to produce those tailor-made 00:09:31.620 --> 00:09:37.520 proofs that my counterparty misbehaved on a whim and I 00:09:37.520 --> 00:09:43.240 have to have them ready and I might even have to sort of outsource those 00:09:43.240 --> 00:09:48.960 if I myself cannot be present all the time. So if, for example, you've run a 00:09:48.960 --> 00:09:54.880 watchtower, then you would actually have to remember a linear amount 00:09:54.880 --> 00:10:00.830 of data for the channel lifetime. Whereas with eltoo, what 00:10:00.830 --> 00:10:06.410 we have is basically we have this wildcard where a later 00:10:06.410 --> 00:10:11.790 state that we agreed upon can be attached to any of the prior ones, sort of 00:10:11.790 --> 00:10:15.870 directly jumping to the conclusion of what our current state is. 00:10:17.150 --> 00:10:23.110 But at the same time, it also doesn't mean to be the last state. So 00:10:23.110 --> 00:10:28.050 we could, for example, initiate a close with eltoo, but keep updating the 00:10:28.050 --> 00:10:33.870 channel until a different timeout runs out, or we 00:10:33.870 --> 00:10:39.030 basically don't want to speak to each other again, then we can just stop making 00:10:39.030 --> 00:10:43.450 updates. And it all just flows naturally onto the blockchain and gets all 00:10:43.450 --> 00:10:45.370 resolved without any issues. 00:10:45.550 --> 00:10:49.610 And the magic thing that kind of makes that possible is this proposed soft fork, 00:10:49.870 --> 00:10:55.490 I think, called SIGHASH_ANYPREVOUT. And if I understand it correctly, like, well, 00:10:55.610 --> 00:10:58.630 it's good to illustrate that normally with Bitcoin transactions, there's two 00:10:58.630 --> 00:11:03.170 things you're doing. You're saying I'm spending this previous transaction and 00:11:03.300 --> 00:11:06.340 you're saying, okay, here's the solution to the script of the previous 00:11:06.340 --> 00:11:11.380 transaction. So there's really two keys that you need to provide. And that's 00:11:11.380 --> 00:11:16.500 still true. But your signature, like normally your signature covers all those 00:11:16.500 --> 00:11:20.440 things. So if you've made a signature, you cannot then apply that to any other 00:11:20.440 --> 00:11:24.990 transaction. But with this proposal, the signature does not cover the link to the 00:11:24.990 --> 00:11:29.110 previous transaction. It just covers the script that you're doing. So you're kind 00:11:29.110 --> 00:11:33.450 of creating a signed Lego puzzle piece that you can put onto any other Lego 00:11:33.450 --> 00:11:37.770 puzzle piece. Well, any compatible Lego puzzle piece. Is that a good way to say it? 00:11:37.910 --> 00:11:43.750 Exactly. So in effect, what we do in the classical signatures, in a classical 00:11:43.750 --> 00:11:48.410 transaction scheme in Bitcoin, is we have this double linking between... 00:11:50.380 --> 00:11:55.880 output being spent and the transaction spending it and that is indeed done by 00:11:55.880 --> 00:12:00.480 basically pointing to where the funds come from and then providing a script that 00:12:00.480 --> 00:12:06.060 matches exactly the conditions that were set up when creating those outputs. 00:12:06.660 --> 00:12:12.400 So usually that would be in order to be spent I need a signature from pubkey xyz 00:12:12.400 --> 00:12:18.200 and once you create a 00:12:18.200 --> 00:12:23.400 signature that is specific to the output that you are spending. 00:12:24.320 --> 00:12:30.000 And what SIGHASH ANYPREVOUT does is it basically removes 00:12:30.000 --> 00:12:35.900 that tight coupling between signature and the specific funds that you're 00:12:35.900 --> 00:12:41.300 spending. But since the script is still there, you now rely on 00:12:41.300 --> 00:12:45.800 the pattern of the script still being compatible with the script that is spending 00:12:45.800 --> 00:12:51.500 it. but you can replace, you can swap out the actual funds that are being 00:12:51.500 --> 00:12:56.800 referenced in that. And so what happens is exactly as you point out, is now that 00:12:56.800 --> 00:13:02.560 we have this sort of generic pin where we can attach other Lego bricks to, Lego 00:13:02.560 --> 00:13:07.320 bricks in this case being the transactions, I like that similarity. I will use 00:13:07.320 --> 00:13:09.160 that in future as well. 00:13:10.680 --> 00:13:16.420 And by doing so, we can actually have the very nice 00:13:16.420 --> 00:13:21.440 properties that eltoo gives you, namely that we can skip intermediate states. 00:13:22.160 --> 00:13:27.750 Yeah. Right, you can skip them without having to have, yeah, basically 00:13:27.750 --> 00:13:31.470 the one transaction per thing that you can connect to. 00:13:32.120 --> 00:13:32.720 Exactly. 00:13:33.880 --> 00:13:38.440 So it might be fun to go into the nitty-gritty of what that script actually looks 00:13:38.440 --> 00:13:44.080 like. So if I understand it correctly, the script is saying I can spend anything 00:13:44.080 --> 00:13:46.500 that has a sequence number above... 00:13:47.840 --> 00:13:49.900 25 or something like that. Is that right? 00:13:50.700 --> 00:13:56.380 Yeah, so what we create basically with eltoo is a very long chain where 00:13:56.380 --> 00:14:01.040 each individual agreement is represented by what's called an update transaction. 00:14:01.280 --> 00:14:07.140 So every time we come to an agreement about what our 00:14:07.140 --> 00:14:11.200 next state should look like, for example, I'm sending you one Bitcoin, so your 00:14:11.200 --> 00:14:17.060 balance increases by one, mine decreases by one. We now attach a new 00:14:17.060 --> 00:14:22.660 update transaction to this very long chain of update transactions now 00:14:22.660 --> 00:14:28.060 if we were to basically just use that structure then we then we would have to 00:14:28.060 --> 00:14:32.760 replay all of these update transactions on chain when settling because from state 00:14:32.760 --> 00:14:38.020 zero we go to one to two to three to four and five so we wouldn't we wouldn't 00:14:38.020 --> 00:14:40.180 have earned anything, right? 00:14:40.340 --> 00:14:44.140 No, that defeats the whole purpose of doing things off-chain. 00:14:44.480 --> 00:14:50.180 Exactly. And so what we want to do is instead skip these intermediate 00:14:50.180 --> 00:14:55.520 transactions. And so each of the outputs that we create 00:14:55.520 --> 00:15:01.480 from those update transactions actually has a state 00:15:01.480 --> 00:15:07.060 number in it. So the first one is 0, 1, 2, 3, 4, 5. 00:15:07.530 --> 00:15:13.100 And what we do then is basically any 00:15:13.100 --> 00:15:19.100 update can be attached to any prior update. And so what we have 00:15:19.100 --> 00:15:24.820 in the transaction spending the output... 00:15:26.530 --> 00:15:32.130 we have a check that basically the sequence number that we are attaching to is 00:15:32.130 --> 00:15:38.070 smaller than our current state number. And that is basically the area 00:15:38.070 --> 00:15:43.850 so that I can't basically go back in time and apply something newer 00:15:43.850 --> 00:15:49.530 or older than what I'm supposed to. So you can't have a sequence like we're in 00:15:49.530 --> 00:15:55.050 state 100 and then I go to state 90 and since... all of those outputs look the 00:15:55.050 --> 00:16:00.030 same, I could theoretically take 90 and attach it to 100, thus going back 10 00:16:00.030 --> 00:16:01.970 steps in our history. 00:16:02.270 --> 00:16:05.270 Yeah, that'd be quite annoying, especially because then you could go back and forth. 00:16:06.200 --> 00:16:11.800 Exactly. We could have this infinite chain of going back and forth and never 00:16:11.800 --> 00:16:16.920 actually make any progress and settle things. We would just be spending loads of 00:16:16.920 --> 00:16:22.740 coins in on-chain fees because, well, I do something and then you 00:16:22.740 --> 00:16:27.240 have a favorite state where you had more money so you are applying that one and 00:16:27.240 --> 00:16:32.230 then I go back to my state where I had the most money. And so we have to make 00:16:32.230 --> 00:16:37.650 sure that there is this constant progression forward, and that's exactly where 00:16:37.650 --> 00:16:41.430 the state numbers come in, because we then can make sure that we can only attach 00:16:41.430 --> 00:16:45.430 later states to newer states, ensuring that eventually we get to the last one 00:16:45.430 --> 00:16:48.370 that we agreed upon, and that will eventually settle as well. 00:16:48.490 --> 00:16:52.150 Right, and the state number is just the, I think, the nSequence field that is 00:16:52.150 --> 00:16:55.450 part of a transaction, right? So, where is it? 00:16:56.770 --> 00:16:57.910 It's a bit more complex. 00:16:59.270 --> 00:17:01.330 Or is it specified in the output script? 00:17:01.630 --> 00:17:05.790 So in the output script, we can put the number directly because that is actually 00:17:05.790 --> 00:17:09.270 covered by the signature that created that transaction. 00:17:10.510 --> 00:17:15.350 For the input where we say, okay, I am actually state 100. I can attach to 00:17:15.350 --> 00:17:21.070 anything before 100. That would have to be in the 00:17:21.070 --> 00:17:26.280 input script. The problem is the input script containing the signature itself 00:17:26.280 --> 00:17:30.900 cannot be covered by the signature. Otherwise, we'd have this circular reference 00:17:30.900 --> 00:17:36.540 where I am trying to create an input script containing a signature which has to 00:17:36.540 --> 00:17:41.980 sign the input script. So that doesn't really work. And so we use a little 00:17:41.980 --> 00:17:46.580 trick where we say, okay, what parts of the transactions are actually covered by 00:17:46.580 --> 00:17:52.530 the signature? so that we don't have to put it into the script itself. And it 00:17:52.530 --> 00:17:57.320 turns out the nLockTime is. So the nLockTime is part of the transaction 00:17:57.320 --> 00:18:03.070 where we have a number which is covered by the signature. So 00:18:03.100 --> 00:18:08.900 any person cannot really modify that. And 00:18:08.900 --> 00:18:14.080 we can, with OP_CHECKLOCKTIMEVERIFY, we can do comparisons between numbers. 00:18:14.620 --> 00:18:20.420 And so what we do is basically state 100 as nLockTime 100, which 00:18:20.420 --> 00:18:26.420 is far, far, far in the past. So it doesn't really have its effect as 00:18:26.420 --> 00:18:28.540 locking for a certain time. 00:18:28.720 --> 00:18:29.900 Right, because it's like 1970. 00:18:30.200 --> 00:18:36.180 Exactly. But what we can do is, executing CHECKLOCKTIMEVERIFY will 00:18:36.180 --> 00:18:40.580 pull that onto the stack, and we can perform a comparison between two numbers. 00:18:41.040 --> 00:18:46.220 without anybody being able to unilaterally change those numbers. And that's how 00:18:46.220 --> 00:18:50.100 we enforce the ordering of transactions in all of this. 00:18:50.260 --> 00:18:55.960 Right, so one Lego block that represents the update state, I guess what it 00:18:55.960 --> 00:19:01.950 contains is, well, obviously the input doesn't have an amount, right? 00:19:02.030 --> 00:19:04.590 It just points to any previous version. 00:19:04.730 --> 00:19:05.010 Exactly. 00:19:05.190 --> 00:19:07.150 And then the output says, okay, this is the new amount. 00:19:07.470 --> 00:19:07.750 Yeah. 00:19:08.980 --> 00:19:10.160 And the minimum version. 00:19:10.380 --> 00:19:16.320 There is a bit of trickery going on here, of course, because if we were to 00:19:16.320 --> 00:19:21.900 pay any fees in these updates, we suddenly would have to ever decreasing 00:19:21.900 --> 00:19:27.880 amounts that are available to the outputs. And so even being 00:19:27.880 --> 00:19:32.280 able to skip the intermediate steps, we would slowly leak capacity of our 00:19:32.280 --> 00:19:38.260 channels. And so we have another trick there, which is actually what Rusty came 00:19:38.260 --> 00:19:43.200 up with. namely that these update transactions are single 00:19:43.200 --> 00:19:48.890 input, single output transactions. And so we can use SIGHASH_SINGLE to 00:19:48.890 --> 00:19:51.210 just sign that part of the transaction. 00:19:51.550 --> 00:19:54.830 Right, so SIGHASH_SINGLE, if I understand it correctly, the signature covers the 00:19:54.830 --> 00:20:00.370 input and, sorry, the first input and the first output, or the nth input and the 00:20:00.370 --> 00:20:00.830 nth output. 00:20:00.930 --> 00:20:05.970 Exactly, the corresponding ones at the same height. Yeah. And it leaves the rest 00:20:05.970 --> 00:20:10.330 of the transaction basically modifiable. The rest of the... 00:20:10.650 --> 00:20:14.050 Both the inputs and the outputs are modifiable. You can add more. 00:20:14.290 --> 00:20:18.970 Exactly. So you can add more. Particularly you can add fees. 00:20:22.200 --> 00:20:26.580 The update transactions themselves don't actually pay any fees, but we can modify 00:20:26.580 --> 00:20:31.360 them such that they can pay fees. And this is quite nice in practice, right? 00:20:31.460 --> 00:20:33.180 Because the fee weather is hard to predict. 00:20:33.940 --> 00:20:38.980 Oh, yes. One of the complications in Lightning is that you have to constantly 00:20:38.980 --> 00:20:42.860 agree on what fee to put on all these transactions that may not be broadcast for 00:20:42.860 --> 00:20:45.880 several months. And you have no idea what the fee weather is going to be in 00:20:45.880 --> 00:20:50.870 several months. So then you need to... basically agree on what you think the fee 00:20:50.870 --> 00:20:53.870 weather is going to be over its lifetime and i remember at least in the early 00:20:53.870 --> 00:20:58.270 days lightning channels would just spontaneously close because lightning nodes 00:20:58.270 --> 00:21:02.030 could not agree on what the fee weather would be in the future and so they would 00:21:02.030 --> 00:21:04.710 say well if we can't agree on what the future is going to bring then we should 00:21:04.710 --> 00:21:05.970 just close this channel right now 00:21:05.970 --> 00:21:06.770 exactly 00:21:06.770 --> 00:21:11.190 and that has been partially mitigated with all sorts of fancy things like 00:21:11.190 --> 00:21:12.550 anchoring outputs i think 00:21:15.180 --> 00:21:21.180 Yeah, so the anchor output is basically the idea of bring your own fees, 00:21:21.420 --> 00:21:26.360 backport it to the LN penalty mechanism. 00:21:26.500 --> 00:21:31.920 Why can't it use the same single, sorry, what was it, SIGHASH_SINGLE solution? 00:21:31.920 --> 00:21:34.660 SIGHASH_SINGLE, yeah. The issue is that... 00:21:36.670 --> 00:21:41.330 That basically requires you to have single input, single output transactions. 00:21:42.410 --> 00:21:47.660 And so it might work for HTLC transactions, but not really. 00:21:48.640 --> 00:21:52.800 And in particular, it doesn't work for commitment transactions because while you 00:21:52.800 --> 00:21:58.430 have a single input... the commitment transaction represents the full state of 00:21:58.430 --> 00:22:04.370 the agreement. And so it might have two outputs, one for you 00:22:04.370 --> 00:22:10.250 and one for me, plus any HTLC that we attach to it. Whereas the update 00:22:10.250 --> 00:22:14.710 in eltoo is really just there to ratchet forward and make sure that we are making 00:22:14.710 --> 00:22:18.810 progress in time. And the actual state is then represented by a settlement 00:22:18.810 --> 00:22:21.870 transaction that is separate from the updates. 00:22:22.510 --> 00:22:28.400 Okay, yeah. All right. So this sounds great. What needs to happen? 00:22:28.820 --> 00:22:30.040 This is a soft fork, right? 00:22:30.380 --> 00:22:30.540 Yeah. 00:22:30.740 --> 00:22:32.320 So it's a soft fork on top of Taproot now? 00:22:32.940 --> 00:22:37.920 Exactly. So it has always been a soft fork, though 00:22:37.920 --> 00:22:43.580 when I wrote the first version, back then still called NOINPUT, it 00:22:43.580 --> 00:22:48.740 was basically, it was not integrated with Taproot because back then we didn't 00:22:48.740 --> 00:22:52.920 know how long it would take to activate Taproot. Turns out we were really quick 00:22:52.920 --> 00:22:58.040 with that. And so AJ Towns came along and basically took 00:22:58.040 --> 00:23:03.180 the idea of no input, renamed it anyprevout, and 00:23:03.180 --> 00:23:07.600 integrated it closely with Taproot. So there is now a couple of features that are 00:23:07.600 --> 00:23:12.800 really nice that weren't present in the original proposal. 00:23:13.760 --> 00:23:19.640 Namely, you now have two sighash flags, which can turn on or off different parts 00:23:19.640 --> 00:23:23.430 of the transactions being covered by a signature. And so there is a lot of 00:23:23.430 --> 00:23:29.170 flexibility that we get from this soft fork. And we 00:23:29.170 --> 00:23:33.790 already have a couple of proposals of systems that we could build with that. 00:23:34.400 --> 00:23:39.140 Cool. Well, anything else you want to add to this brief explanation? 00:23:42.300 --> 00:23:48.110 Do you want to go into controversies or do you want to just stick to the 00:23:48.110 --> 00:23:49.550 explanation and we'll see how it goes? 00:23:50.180 --> 00:23:54.400 Yeah, I think in my mind, it is a 00:23:54.400 --> 00:24:00.260 much cleaner way to build off-chain contracts in general because 00:24:00.260 --> 00:24:05.880 it is a very clean update mechanism where we can just say, okay, we had an 00:24:05.880 --> 00:24:09.780 agreement, now we have a new one, and we invalidate the old one by basically 00:24:09.780 --> 00:24:15.720 overriding it or providing the ability to override when it comes to it. Lightning 00:24:15.720 --> 00:24:21.400 penalties might be attractive because it sort of has strong punishments for 00:24:21.400 --> 00:24:26.840 misbehavior. And so that's strong incentives to be well behaved. However... 00:24:26.890 --> 00:24:32.070 everybody likes to penalize until they're the ones being penalized, right? And so 00:24:32.070 --> 00:24:35.470 we often focus so much more on 00:24:35.470 --> 00:24:41.450 punishing the bad guys rather than helping people 00:24:41.450 --> 00:24:45.610 who are really just, well, they're trying to restore from a backup, which is 00:24:45.610 --> 00:24:50.890 already quite traumatic. And then we make them risk losing their funds as well. 00:24:51.510 --> 00:24:55.290 Yeah. Well, it sounds like it makes, in general, this change makes it a lot 00:24:55.290 --> 00:24:59.850 simpler. Like, also, you don't have double, like, normally when you have an 00:24:59.850 --> 00:25:02.910 update, I have a transaction and you have a transaction that are sort of each 00:25:02.910 --> 00:25:03.630 other's mirror image. 00:25:05.540 --> 00:25:08.960 And that goes away. Like, there's just one transaction. There's not a mirror of 00:25:08.960 --> 00:25:09.420 transactions. 00:25:10.800 --> 00:25:14.620 Yeah, you only need to store one piece of information, namely the latest state. 00:25:15.060 --> 00:25:18.680 And it's okay if you don't, yeah, exactly. So it sounds a lot simpler. The 00:25:18.680 --> 00:25:23.370 downside could be that this... Maybe this punishment is needed. Now, I do know, 00:25:23.570 --> 00:25:28.770 like, you know, I've worked on this forkmonitor.info website, and one of the 00:25:28.770 --> 00:25:32.590 things it tracks is penalty transactions on the Lightning Network. And they're 00:25:32.590 --> 00:25:37.130 very rare, and they're usually quite trivial amounts. So that, to me, suggests 00:25:37.130 --> 00:25:40.570 that the mechanism really has not ever been used. 00:25:42.320 --> 00:25:43.840 for serious retaliation? 00:25:44.160 --> 00:25:46.900 Well, it might be because it's a good threat, right? 00:25:47.080 --> 00:25:49.980 Yeah, so that's the question then. Is it because nobody wants to attack or 00:25:49.980 --> 00:25:54.250 because it's really... I mean, one, it could be very good protection indeed. It 00:25:54.250 --> 00:25:58.610 could also just be that we are now in a happy kumbaya state of things. You know, 00:25:59.230 --> 00:26:03.590 and maybe one day, you know, Bitcoin wants to assume that maybe one day we won't 00:26:03.590 --> 00:26:07.890 be in a kumbaya state and people will be trying to attack or at least, you know, 00:26:07.950 --> 00:26:13.290 either drain the resources of a node or otherwise misbehave. But my understanding 00:26:13.290 --> 00:26:17.010 is you could, in principle, still add a penalty mechanism on top of eltoo. 00:26:17.440 --> 00:26:22.300 Yeah, so I totally agree. We definitely shouldn't base our security on the 00:26:22.300 --> 00:26:26.080 assumption that everybody's well-behaved, because then, I mean, what's the point? 00:26:26.900 --> 00:26:32.120 We do have a tendency to be very sort of defensive thinkers, 00:26:32.240 --> 00:26:37.760 and I think that's when it comes to money and somebody's livelihood, 00:26:38.060 --> 00:26:43.230 that's probably the best way to approach it. It's not totally free to 00:26:43.230 --> 00:26:48.250 misbehave in eltoo either. Like I mentioned before, you actually have to bring 00:26:48.250 --> 00:26:53.190 your own fees whenever you perform any on-chain action. It's up to you to decide 00:26:53.190 --> 00:26:59.070 how much fees to attach and what your sort of time horizon is, and that 00:26:59.070 --> 00:27:04.350 will inform how many fees you attach. But you are the one that has to attach 00:27:04.350 --> 00:27:10.050 fees. So every time you try to do something, in eltoo that might 00:27:10.050 --> 00:27:15.480 have consequences, like going back in 00:27:15.480 --> 00:27:21.200 the history of our channel, you will have to bring fees with you and you will 00:27:21.200 --> 00:27:26.880 spend those fees to get your state started on the blockchain. 00:27:27.840 --> 00:27:32.800 But if it's not the latest state, you are basically already giving your opponent 00:27:32.800 --> 00:27:37.680 the opportunity to react to it. And what you've just done is waste a couple of 00:27:37.680 --> 00:27:43.580 fees and waste a couple of bytes in the blockchain for which the fee paid, right? 00:27:43.800 --> 00:27:48.220 And so you should always be incentivized to only ever produce the last state. 00:27:49.410 --> 00:27:55.230 And while not as deadly as LN penalty, where you lose all of your 00:27:55.230 --> 00:28:00.030 funds, a fee can still hurt, especially when we have congested mempools. 00:28:00.650 --> 00:28:04.950 Yeah, and unless you really know for sure that your opponent is offline, you 00:28:04.950 --> 00:28:08.790 probably are wasting that fee. If you're just arbitrarily trying this attack on 00:28:08.790 --> 00:28:12.690 everybody you know, it's kind of wasteful because you have to pay a fee every 00:28:12.690 --> 00:28:13.510 time you try to attack. 00:28:13.970 --> 00:28:18.670 Exactly. And I mean, since we make retaliation really, really cheap by basically 00:28:18.670 --> 00:28:24.270 making watchtowers constant memory. instead of this ever-increasing set of 00:28:24.270 --> 00:28:29.130 transactions a watchtower has to remember, we make it more likely that you might 00:28:29.130 --> 00:28:34.950 have a watchtower. And maybe that threat alone is enough to make it not 00:28:34.950 --> 00:28:40.750 worthwhile trying to even attempt a cheat. So, yeah. It's basically, 00:28:40.850 --> 00:28:46.450 I always compare it to being decapitated outright, which is LN penalty, versus 00:28:46.450 --> 00:28:52.420 death by a thousand cuts, which is... smaller, less hurtful, but it 00:28:52.420 --> 00:28:54.440 will still be deadly if you do it often enough. 00:28:55.510 --> 00:28:57.550 Yeah, that sounds about right. Okay. 00:28:58.830 --> 00:29:01.130 Okay, when is this going to launch? 00:29:02.070 --> 00:29:03.030 Two weeks, of course. 00:29:03.190 --> 00:29:07.250 Two weeks. All right, that sounds good. I think we can wrap it up with that. Do 00:29:07.250 --> 00:29:09.450 you want people to reach you or do you want people to leave you alone? 00:29:10.770 --> 00:29:16.260 Definitely reach me. I'm S-N-Y-K-E on Twitter, Snyke. and 00:29:16.260 --> 00:29:18.300 cdecker almost everywhere else. 00:29:18.600 --> 00:29:20.420 And you hang out on various mailing lists? 00:29:21.020 --> 00:29:26.690 All of them. Though I, like many others, keep lagging on reading those 00:29:26.690 --> 00:29:31.850 mailing lists. But if something catches my eyes, I will definitely jump in there 00:29:31.850 --> 00:29:32.370 and reply. 00:29:32.890 --> 00:29:38.360 Okay, because where would you say the development is happening now? Is it just 00:29:38.360 --> 00:29:42.080 updating the BIP or arguing about the BIP? 00:29:42.840 --> 00:29:48.700 So I mostly spend my time on the Lightning specification. So that's the Lightning 00:29:48.700 --> 00:29:53.700 mailing list, the GitHub for the Lightning spec, and of course our various 00:29:53.700 --> 00:29:59.420 implementations. And the anyprevout discussion is mostly 00:29:59.420 --> 00:30:03.460 happening on the BIP itself. So BIP 118. 00:30:04.750 --> 00:30:09.370 And of course, if you have an idea and just want to bounce that idea off of 00:30:09.370 --> 00:30:14.450 people, the mailing list is always a good place to sort of learn about prior art 00:30:14.450 --> 00:30:17.450 or get feedback about how to structure it better. 00:30:17.790 --> 00:30:19.430 This is the Bitcoin Dev mailing list. 00:30:19.530 --> 00:30:20.690 The Bitcoin Dev mailing list, yeah. 00:30:20.910 --> 00:30:25.370 All right. Well then, thanks for joining me. And thank you for listening to 00:30:25.370 --> 00:30:26.390 Bitcoin Explained. 00:30:26.610 --> 00:30:27.110 Thank you.