WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:07.310 --> 00:00:10.570 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:10.830 --> 00:00:12.090 Hello, happy new year. 00:00:12.430 --> 00:00:15.620 Happy new year, Sjors. Happy all-time high again. 00:00:16.080 --> 00:00:17.840 Indeed, even against gold, I heard. 00:00:18.060 --> 00:00:19.980 We are at an all-time high in gold now. 00:00:20.920 --> 00:00:21.640 That's what I hear. 00:00:21.640 --> 00:00:23.060 What does that mean? You mean… 00:00:23.060 --> 00:00:27.500 It means the number of grams of gold that you can buy for one Bitcoin is now 00:00:27.500 --> 00:00:28.120 higher than ever. 00:00:28.460 --> 00:00:30.100 Sure, of course, that's what it means. 00:00:30.260 --> 00:00:32.000 Yeah, we don't know the market cap of gold, though. 00:00:32.500 --> 00:00:37.040 Yeah, that's what I was wondering. How much longer until we reach the market cap of gold? 00:00:38.450 --> 00:00:40.810 Approximately. Is it like 10x or something? 00:00:41.500 --> 00:00:44.960 Could be, but we really don't know the market cap of gold because we don't know 00:00:44.960 --> 00:00:45.800 how much gold there is. 00:00:46.100 --> 00:00:46.740 Also true. 00:00:47.180 --> 00:00:48.740 And, you know, there's these asteroids 00:00:49.690 --> 00:00:53.390 Out there. Sjors, we haven't made an episode on Lightning yet. 00:00:53.570 --> 00:00:55.610 We have not. We have mentioned it a few times. 00:00:55.810 --> 00:00:58.270 Yeah, so I think it's time to make an episode on Lightning. 00:00:58.570 --> 00:00:58.970 Cool. 00:00:59.270 --> 00:01:04.130 The Lightning network. Now the Lightning Network has all sorts of complexities 00:01:04.130 --> 00:01:09.690 and cool new features and improvements, and all sorts of complex stuff. 00:01:09.930 --> 00:01:13.110 But today we're going to start with a basic episode on the Lightning Network. 00:01:13.310 --> 00:01:13.810 That's right. 00:01:13.990 --> 00:01:16.310 Just the Lightning Network. What is it? How does it work? 00:01:17.540 --> 00:01:18.040 All right. 00:01:18.240 --> 00:01:23.500 Okay, so first of all, I think the problem, why, the reason that the Lightning 00:01:23.500 --> 00:01:28.610 Network was invented is pretty evident right now. The main reason, Sjors, is 00:01:28.610 --> 00:01:31.030 because fees tend to get high sometimes. 00:01:31.670 --> 00:01:32.070 That's right. 00:01:33.770 --> 00:01:38.970 Yeah. Basically, you know, if you can't make blocks bigger, then how are you 00:01:38.970 --> 00:01:43.970 going to squeeze more transactions in the same amount of time? And that's what 00:01:43.970 --> 00:01:44.870 Lightning tries to solve. 00:01:45.190 --> 00:01:50.530 Yeah. It's a layer two solution for Bitcoin, for smaller payments, I guess, 00:01:50.730 --> 00:01:55.110 faster payments as well, instant confirmations, and also more privacy as a bonus. 00:01:55.390 --> 00:01:59.710 Hopefully, yes. At least it's a very different privacy model because, you never 00:01:59.710 --> 00:02:03.090 know what the long-term problems are going to be with privacy. At least it 00:02:03.090 --> 00:02:05.890 doesn't show… The transactions you're making don't show up on a blockchain. 00:02:06.790 --> 00:02:09.190 Yeah, potentially better privacy. 00:02:09.900 --> 00:02:10.560 I think so. 00:02:10.760 --> 00:02:14.700 Okay, so the first… I think the main important… the main thing about the 00:02:14.700 --> 00:02:18.020 Lightning Network and the first thing we're going to tackle are Lightning 00:02:18.020 --> 00:02:19.600 Channels. Payment Channels. 00:02:19.600 --> 00:02:20.540 Yeah, Payment Channels. 00:02:20.640 --> 00:02:21.380 Payment Channels. 00:02:21.540 --> 00:02:24.580 Yeah, we'll explain how the Lightning Network comes out of Payment Channels. But 00:02:24.580 --> 00:02:30.240 the Payment channel, the idea is just you have… you take two people and you take 00:02:30.240 --> 00:02:36.020 coins from both of you or from one side and you put it in essentially a 00:02:36.020 --> 00:02:40.020 multi-signature address, which means that both parties need to sign in order to 00:02:40.020 --> 00:02:45.940 get it out. And then you start basically reassigning the amount on 00:02:45.940 --> 00:02:49.220 each side as you go. And there's very different ways of doing that. 00:02:49.440 --> 00:02:53.980 Yeah, you basically both have a balance in this channel and you keep track of the 00:02:53.980 --> 00:02:59.700 balance. So let's say Sjors and I, we both put one Bitcoin into a channel. Now we 00:02:59.700 --> 00:03:00.920 have a channel of two Bitcoin. 00:03:01.180 --> 00:03:02.300 Maybe a little bit less. 00:03:02.480 --> 00:03:04.740 I'm just using round amounts because it's easy. 00:03:04.900 --> 00:03:05.020 Yeah. 00:03:05.510 --> 00:03:06.850 But maybe… 00:03:06.850 --> 00:03:08.530 Yeah, let's put one Bitcoin in the channel. 00:03:08.850 --> 00:03:09.410 Two Bitcoin. 00:03:09.710 --> 00:03:10.050 Yeah. 00:03:10.470 --> 00:03:16.430 Okay, now I'm paying Sjors 0.1 Bitcoin. That means that in the channel, I now 00:03:16.430 --> 00:03:22.380 have… 0.9 Bitcoin and Sjors has 1.1 Bitcoin. But this is basically something, 00:03:22.380 --> 00:03:26.260 Sjors and I know, but the rest of the world doesn't know. The multisig address, 00:03:26.440 --> 00:03:30.060 the Bitcoin address still just has two Bitcoin in them. Okay, so now the balance 00:03:30.060 --> 00:03:35.540 between us in our channel is I have 0.9, you have 1.1 Bitcoin. 00:03:35.860 --> 00:03:41.140 Now you can pay me again. So let's say you want to pay me 0.2 Bitcoin. 00:03:42.220 --> 00:03:48.120 Now the new balance is I have 1.1, you have 0.9. You can pay me again. This time, 00:03:48.220 --> 00:03:53.880 let's say you pay me 0.1 again. So now your balance is 0.8, my balance is 1.2. 00:03:54.060 --> 00:03:58.740 We can keep going on and we can keep updating the balance. Essentially, we keep 00:03:58.740 --> 00:04:03.040 paying each other, but the rest of the world never actually knows any of this. 00:04:03.500 --> 00:04:08.820 Now, at the end of all of this, we know our balances. So let's say the last 00:04:08.820 --> 00:04:14.600 balance was 0.8 versus 1.2. We both know this. We create a new 00:04:14.600 --> 00:04:19.620 transaction from the original transaction where we both send one Bitcoin to the 00:04:19.620 --> 00:04:23.640 channel. That's from that transaction. That's the only transaction the rest of 00:04:23.640 --> 00:04:28.100 the world knows about. From that transaction, we now cooperate on a new 00:04:28.100 --> 00:04:33.200 transaction that sends me 1.2 and you, Sjors, 0.8. 00:04:33.910 --> 00:04:38.670 This transaction we broadcast to the network. So at this point, the whole world 00:04:38.670 --> 00:04:40.170 saw two transactions. 00:04:41.450 --> 00:04:45.390 One transaction going into the multisig address, one transaction going out of the 00:04:45.390 --> 00:04:46.030 multisig address. 00:04:46.170 --> 00:04:51.990 Exactly. While actually we may have done 10 or 100 or 1,000 transactions. So 00:04:51.990 --> 00:04:53.570 that's how we're saving on block space. 00:04:53.850 --> 00:04:58.210 Yeah, but of course there's a problem here because we've actually been making 00:04:58.210 --> 00:05:02.070 these transactions all along, right? We've been making transactions out of the 00:05:02.070 --> 00:05:06.570 multisig since the beginning and we kept making a new transaction to reflect a 00:05:06.570 --> 00:05:11.130 different balance. But the outside world does not know what the most recent one 00:05:11.130 --> 00:05:16.150 is. Or maybe they do know, but the blockchain doesn't care about it. Because all 00:05:16.150 --> 00:05:17.190 these transactions are valid. 00:05:17.390 --> 00:05:17.730 Yeah. 00:05:17.930 --> 00:05:19.530 So what do we do about that? 00:05:19.670 --> 00:05:25.550 The question is, why don't you cheat? Once the balance between us, 00:05:25.650 --> 00:05:31.650 the last balance was 1.2 for me, 0.8 for Sjors, why doesn't Sjors at any 00:05:31.650 --> 00:05:37.490 point just claim this 1.1 that we started with after the first transaction we 00:05:37.490 --> 00:05:42.090 made between us? Why doesn't Sjors just claim 1.1 even though he should only be 00:05:42.090 --> 00:05:43.890 able to claim 0.8? 00:05:44.060 --> 00:05:48.340 Exactly. Or even there might have been another more favorable state somewhere in 00:05:48.340 --> 00:05:54.240 this exchange that I still have the transaction for. So that's a problem. And I 00:05:54.240 --> 00:05:59.260 believe Satoshi originally roughly thought about just give every transaction a 00:05:59.260 --> 00:06:04.520 sequence number. So the highest sequence number goes first. But the blockchain 00:06:04.520 --> 00:06:06.560 wasn't really able to enforce that. 00:06:06.920 --> 00:06:10.000 Yeah. So Satoshi's idea was, okay, let's say… 00:06:10.000 --> 00:06:13.520 Yeah, let's say the first transaction has sequence number one. The second 00:06:13.520 --> 00:06:17.500 transaction, where we move coins as sequence number two. And so at the end, you 00:06:17.500 --> 00:06:22.120 know we have sequence number 15. And the idea would have been, okay, if you 00:06:22.120 --> 00:06:26.980 broadcast sequence number five, but I broadcast sequence number 15, then number 00:06:26.980 --> 00:06:30.700 15 is going to win. Yeah, but that was the idea. But there was nothing that 00:06:30.700 --> 00:06:33.180 would… in the protocol that would force that to happen. 00:06:33.980 --> 00:06:37.960 Right. In the end, miners still decide which transaction they put into a block. 00:06:38.000 --> 00:06:43.560 So if they can choose between transactions with different version numbers, they 00:06:43.560 --> 00:06:47.540 might include the last version number or they might not. It's up to them in the end. 00:06:47.620 --> 00:06:50.920 And it could be a very short time, right? Because we talked about the mempool in 00:06:50.920 --> 00:06:54.520 an earlier episode, this place where transactions fly around before they go into 00:06:54.520 --> 00:07:00.360 a block. And so, yeah, I might suddenly broadcast this number 00:07:00.360 --> 00:07:04.530 five transaction and it's going to be in a mempool for a while. And then it's 00:07:04.530 --> 00:07:07.230 going to be in a block and it's too late because a transaction can't be double 00:07:07.230 --> 00:07:11.670 spent once it's in a block. So you would have to broadcast number 15 very, very 00:07:11.670 --> 00:07:16.080 quickly when you see it in a mempool. And that's, of course, quite dangerous 00:07:16.080 --> 00:07:18.000 because that might just be a matter of minutes or seconds. 00:07:18.720 --> 00:07:24.120 Right. Okay. So summarizing, a payment channel or Lightning channel is like a 00:07:24.120 --> 00:07:28.860 multisig address. In this case, between Sjors and me. We send our coins to that 00:07:28.860 --> 00:07:33.640 address. Then we create new transactions from that address, sending coins from 00:07:33.640 --> 00:07:38.200 that address. And in these new transactions, the balances are different. We don't 00:07:38.200 --> 00:07:43.540 broadcast these transactions to the network, except the last one, ideally. We 00:07:43.540 --> 00:07:48.660 only broadcast the last transaction to the network, which pays us both what we 00:07:48.660 --> 00:07:51.120 should be able to get from the channel. 00:07:51.400 --> 00:07:55.630 Yeah. But from Bitcoin's point of view, all these transactions are the same, from 00:07:55.630 --> 00:07:58.470 the blockchain's point of view. They're all the same. They might have a different 00:07:58.470 --> 00:08:02.450 sequence number or something like, as we discussed, but that doesn't really matter. 00:08:02.690 --> 00:08:05.170 So we need a way to actually enforce this. 00:08:05.430 --> 00:08:05.830 Yes. 00:08:05.950 --> 00:08:08.660 And that's what Lightning channels are. 00:08:09.900 --> 00:08:12.560 That's the big innovation of a Lightning network, I would say. 00:08:12.700 --> 00:08:15.620 I would say that's one of the two big innovations of the Lightning network, yeah. 00:08:15.980 --> 00:08:17.860 Okay, so how do we enforce this? 00:08:18.540 --> 00:08:23.780 We add some punishments. And basically, the punishment 00:08:23.780 --> 00:08:29.480 is kind of tricky to explain. But the idea here is that when we create 00:08:29.480 --> 00:08:35.040 a new version, so we were at 15, we're going to make number 16. This 00:08:35.040 --> 00:08:40.680 transaction actually has two paths, right? So scripts can have multiple 00:08:40.680 --> 00:08:44.620 paths, can have an if and else in it, for example. And one path is the happy 00:08:44.620 --> 00:08:50.040 path, where indeed the money just goes to you and me the way we agreed. The other 00:08:50.040 --> 00:08:56.010 is the unhappy path, which says that if I release an earlier version of this 00:08:56.010 --> 00:09:01.900 thing, so if I release number 15, then you're going to get all the money. 00:09:02.060 --> 00:09:02.920 Does that make sense? 00:09:03.400 --> 00:09:05.680 Yeah. Well, you're simplifying a bit now. 00:09:05.860 --> 00:09:06.480 A lot. 00:09:06.680 --> 00:09:07.000 Yes. 00:09:07.180 --> 00:09:10.920 Yeah, but the idea there is in every transaction, actually, you're already doing 00:09:10.920 --> 00:09:15.180 this, right? So we can start all the way at the beginning. So the first 00:09:15.180 --> 00:09:18.720 transaction that goes out of the multisig already has these two conditions. 00:09:20.670 --> 00:09:25.190 One where you're actually getting it back the way you expected, and the other is 00:09:25.190 --> 00:09:30.280 saying, well, if you know this punishment secret, you can take all the money. So 00:09:30.280 --> 00:09:33.420 it doesn't contain the punishment secret, but it says, if you know the punishment 00:09:33.420 --> 00:09:37.280 secret, you can get all the money. And then the second transaction refers to the 00:09:37.280 --> 00:09:40.820 first one and says, well, here's the punishment secret for the first transaction. 00:09:41.140 --> 00:09:46.440 So now, if somebody broadcasts this first transaction, well, you know the 00:09:46.440 --> 00:09:49.260 punishment secret. So you can actually take all the money from me. 00:09:49.680 --> 00:09:55.340 Yeah. To clarify, we both have different transactions, 00:09:55.620 --> 00:09:58.770 don't we? And different punishments, so to say. 00:09:59.130 --> 00:09:59.710 Yes. 00:09:59.930 --> 00:10:05.660 So either of us at any point [unclear] broadcast any channel state, 00:10:05.660 --> 00:10:11.440 essentially. And then we immediately give our counterparty what 00:10:11.440 --> 00:10:17.380 they should get from that… from the payment channel. Our own… funds 00:10:17.380 --> 00:10:20.800 from the payment payment channel, we're getting it as well, but we have to wait, 00:10:20.800 --> 00:10:26.360 and during this wait the other person, the counterparty, can use 00:10:26.360 --> 00:10:30.020 a secret to claim the rest of the money if he has that secret. 00:10:30.020 --> 00:10:34.240 Yeah, so Lightning tends to use two transactions for every time you update. 00:10:34.240 --> 00:10:40.240 Exactly. So one transaction is from my point of view, indeed, 00:10:40.240 --> 00:10:44.610 you're getting your money immediately, I'm getting my money with the delay. And 00:10:44.610 --> 00:10:49.210 you're having the exact opposite transaction where I get my money immediately and 00:10:49.210 --> 00:10:50.190 you get it with a delay. 00:10:50.490 --> 00:10:50.590 Yeah. 00:10:51.130 --> 00:10:54.210 And then the idea is that this delay while the transaction is sitting there, 00:10:54.450 --> 00:10:58.130 either of us can see that old transaction. And if we see that, hey, that's an old 00:10:58.130 --> 00:11:02.400 state, well, we have this punishment secret. So we can actually take all the 00:11:02.400 --> 00:11:04.180 money immediately while you're waiting. 00:11:04.380 --> 00:11:08.000 And we have the punishment secrets because it's an older state that was 00:11:08.000 --> 00:11:10.460 broadcasted. We only have that for the older states. 00:11:10.600 --> 00:11:16.570 Yeah. When we create a new state, a new state in the channel, we kind 00:11:16.570 --> 00:11:19.750 of exchange a couple of things. We exchange those two new transactions and we 00:11:19.750 --> 00:11:23.550 exchange the punishment secrets. And it all has to go sort of in the right 00:11:23.550 --> 00:11:27.450 sequence and making sure that we know that we both have the new version. 00:11:27.810 --> 00:11:33.180 Yeah. So if the latest channel state is broadcast… In that case, so let's say I 00:11:33.180 --> 00:11:37.700 broadcast the latest channel state. In that case, you [unclear], get your money 00:11:37.700 --> 00:11:41.940 immediately, and I will definitely get my money as well because you don't have 00:11:41.940 --> 00:11:45.860 that secret because it's the latest channel state. I do have to wait a little 00:11:45.860 --> 00:11:49.860 while. It's a little bit of a pain, but I will get the money for sure. 00:11:50.200 --> 00:11:55.020 Yeah, and the nice thing is there that if we are both online and we both agree to 00:11:55.020 --> 00:11:59.970 close the channel, we can create a new final state, which does not involve any waiting. 00:12:00.370 --> 00:12:05.990 Yeah, because if I broadcast my channel, then I am guaranteed to get my money. 00:12:06.690 --> 00:12:10.990 And you know that, Sjors. You know that I'll get my money anyways. So you might 00:12:10.990 --> 00:12:14.770 as well just cooperate and help me get my money immediately and get you your 00:12:14.770 --> 00:12:18.590 money immediately and just have it all finished without any more hassle. 00:12:18.790 --> 00:12:19.070 Exactly. 00:12:19.950 --> 00:12:21.670 So that's the idea of a payment channel. 00:12:22.670 --> 00:12:23.950 Yeah, sounds simple, right? 00:12:24.030 --> 00:12:24.730 That covers it, right? 00:12:24.930 --> 00:12:30.810 Yeah, so that covers one amazing aspect of Lightning. And the second 00:12:30.810 --> 00:12:35.490 amazing aspect of Lightning is that you can combine multiple channels. 00:12:36.070 --> 00:12:41.870 Yeah, so if you and I, if we want to pay each other very often, then one payment 00:12:41.870 --> 00:12:47.570 channel is enough. But you do need a payment channel in order to pay someone. 00:12:47.930 --> 00:12:50.990 So the Lightning Network has this alternative solution, this added solution, 00:12:50.990 --> 00:12:55.610 where we can pay other people through other people, so to say. 00:12:55.770 --> 00:13:00.550 Exactly. So if you go to a supermarket and you pay that supermarket, you can open 00:13:00.550 --> 00:13:05.090 a channel to it. But now let's say I have a channel open with you and I go to 00:13:05.090 --> 00:13:09.510 that supermarket. Now I don't have to open a channel to the supermarket. I'm just 00:13:09.510 --> 00:13:11.390 going to pay you and you're going to pay the supermarket. 00:13:11.670 --> 00:13:11.850 Yeah. 00:13:12.050 --> 00:13:16.130 And again, we have this gimmickry, with the right penalties, et cetera, to make 00:13:16.130 --> 00:13:19.770 sure that you don't steal my money when I'm paying the supermarket. 00:13:20.110 --> 00:13:25.210 Yeah, and the idea with this, this is what makes a Lightning network a network. 00:13:25.590 --> 00:13:30.870 You've got this six degrees of separation idea that within a few steps, you 00:13:30.870 --> 00:13:35.110 should be able to pay everyone because there's always a few steps to get to 00:13:35.110 --> 00:13:37.130 anyone through a couple of other people. 00:13:37.650 --> 00:13:38.730 Yes, exactly. 00:13:39.680 --> 00:13:44.500 But yeah, you mentioned, okay, so this is the next challenge. So you're paying 00:13:44.500 --> 00:13:49.940 the supermarket. Now you want to make sure that I'm not going to keep the money. 00:13:50.120 --> 00:13:53.960 You want to make a payment to the supermarket. So you pay me and then I'm 00:13:53.960 --> 00:13:58.140 supposed to pay the supermarket. But you don't want to have to trust me to 00:13:58.140 --> 00:14:00.220 actually pay the supermarket once you've paid me. 00:14:01.480 --> 00:14:06.060 Also… Perhaps the supermarket is being dishonest and they'll just claim they've 00:14:06.060 --> 00:14:10.380 never been paid even though they have been paid by me. And now you don't know 00:14:10.380 --> 00:14:14.040 who's lying. It's either me or the supermarket. So somehow we need to make sure 00:14:14.040 --> 00:14:18.760 that if you pay me, then I'd also definitely also pay the supermarket. 00:14:19.120 --> 00:14:24.850 Yeah. And so the way that works, and it's always very confusing, so I'll try to 00:14:24.850 --> 00:14:30.740 explain it, is the supermarket who is showing me an invoice. Now that invoice 00:14:30.740 --> 00:14:36.670 contains not a secret, but a hash of a secret. And I take the 00:14:36.670 --> 00:14:41.660 hash of that secret and I create a transaction to you and a transaction from you 00:14:41.660 --> 00:14:46.630 to the supermarket. And then I say, I might actually not make the second 00:14:46.630 --> 00:14:48.590 transaction. You might make that second transaction yourself. 00:14:48.750 --> 00:14:49.050 I think so. 00:14:49.290 --> 00:14:52.430 Yeah. But basically what that transaction says is that if you can give me the 00:14:52.430 --> 00:14:58.240 secret, I'll give you the money. So now I have a transaction that says to you: if 00:14:58.240 --> 00:15:00.800 you give me the secret, I give you the money. And you have a transaction with the 00:15:00.800 --> 00:15:04.300 supermarket that says, if you give me the secret, I'll give you the money. 00:15:04.580 --> 00:15:07.680 Yeah. To be clear, this is all cryptographically enforced. 00:15:08.180 --> 00:15:13.940 Yes. And then what the supermarket does is it releases the 00:15:13.940 --> 00:15:19.540 secret to you. So you're happy. And then you give the secret to me. 00:15:19.900 --> 00:15:23.180 And then the whole chain is complete and we've paid. 00:15:23.400 --> 00:15:28.620 Yeah. Essentially, the supermarket is giving me the secrets by… producing another 00:15:28.620 --> 00:15:34.620 transaction that's, again, unconfirmed. It's part of the whole transaction we 00:15:34.620 --> 00:15:39.340 just described just a minute ago. It's even more… 00:15:39.340 --> 00:15:43.860 It's more complicated. Yeah, exactly. This is where both of us get really 00:15:43.860 --> 00:15:49.360 confused. The concept is called the HTLC, the hash time-lock contract. So I've 00:15:49.360 --> 00:15:52.940 just crafted these transactions that give you the money if I get the secret. But 00:15:52.940 --> 00:15:56.460 it's not just that… If I get the secret within a reasonable amount of time. And 00:15:56.460 --> 00:15:59.020 if I don't get the secret within a reasonable amount of time, then the whole 00:15:59.020 --> 00:16:03.860 thing expires. And I guess once that secret has been revealed, we update the 00:16:03.860 --> 00:16:09.360 balances and all the channels have the new balances, right? Because I've moved 00:16:09.360 --> 00:16:15.060 0.1 Bitcoin to you and you've moved 0.1 Bitcoin to the supermarket. So all those 00:16:15.060 --> 00:16:18.100 channels have updated and we live in a glorious future. 00:16:18.680 --> 00:16:24.340 Yeah, this is another one of these examples where it's kind of complex, but then 00:16:24.340 --> 00:16:29.900 once the complexity works, you can sort of shift to a less complex 00:16:29.900 --> 00:16:34.280 version because we both know we're both guaranteed to get the money. Just like 00:16:34.280 --> 00:16:40.210 before when we wanted to close the channel, we don't actually have to broadcast 00:16:40.210 --> 00:16:43.910 this thing where one of us is to wait or we can just skip that because we both 00:16:43.910 --> 00:16:48.490 know that for sure we'll get the money so we can just make it easier. And it's 00:16:48.490 --> 00:16:54.250 sort of the same thing with this HTLCs where… It's a little bit more 00:16:54.250 --> 00:16:58.510 complex to guarantee that no one's going to be cheated, but once we have that 00:16:58.510 --> 00:17:02.630 guarantee, we can switch to a more simpler version of the channel state. 00:17:02.830 --> 00:17:08.810 I think so, yeah. But basically, the Lightning standard is fairly complicated, 00:17:08.810 --> 00:17:13.250 but you can study it and eventually understand it, and there's different pieces 00:17:13.250 --> 00:17:17.790 of software that implement it. But there are edge cases you need to think about. 00:17:17.950 --> 00:17:22.660 There's complexities around fees, etc. But the good news is there's applications 00:17:22.660 --> 00:17:24.120 and nodes that take care of it. 00:17:25.810 --> 00:17:26.250 Yeah. 00:17:26.250 --> 00:17:27.690 You don't have to do any of this. 00:17:28.090 --> 00:17:32.410 No, but you do, as we talked about in the importance of open source, you do have 00:17:32.410 --> 00:17:35.290 to make sure there are people who are critically looking at this stuff and 00:17:35.290 --> 00:17:37.030 finding bugs because people find bugs. 00:17:37.310 --> 00:17:37.750 Sure. 00:17:38.490 --> 00:17:43.370 They did find bugs quite, I think, half a year ago or something, some pretty bad 00:17:43.370 --> 00:17:46.040 ones, where you could just grab money. 00:17:47.850 --> 00:17:52.550 So if listeners are still listening, do you think they now understand how the 00:17:52.550 --> 00:17:53.430 Lightning Network works? 00:17:53.670 --> 00:17:59.190 No, but the thing about Lightning is you need to hear at least three or four 00:17:59.190 --> 00:18:03.230 different explanations by different people. And so we're contributing to that. 00:18:03.470 --> 00:18:08.110 Yeah, we'll put my Bitcoin Magazine Lightning Explainer article series in the 00:18:08.110 --> 00:18:08.630 show notes. 00:18:09.190 --> 00:18:09.630 Yeah. 00:18:09.970 --> 00:18:14.030 These help me when I want to remember how the Lightning Network works. I just 00:18:14.030 --> 00:18:14.970 read my own articles. 00:18:15.110 --> 00:18:15.670 That's a good one. 00:18:15.790 --> 00:18:16.330 That sometimes helps. 00:18:16.610 --> 00:18:20.390 There's a bunch of people who do good explainers of these things. Yeah, a couple 00:18:20.390 --> 00:18:24.550 of caveats we can probably briefly mention. We mentioned channels. So the 00:18:24.550 --> 00:18:28.870 question is, who do you open a channel to? That's something you can think about. 00:18:29.310 --> 00:18:35.260 And then the other thing is that when I've paid you, one Bitcoin, and 00:18:35.260 --> 00:18:39.940 now I can't pay you any more because all the money is now on your side of the channel. 00:18:40.220 --> 00:18:45.780 Yeah, we start with the example of one each. So a channel with two in total. And 00:18:45.780 --> 00:18:50.420 then if you pay me a lot more than I pay you, then at some point, both bitcoins 00:18:50.420 --> 00:18:53.620 are going to be sitting at my side of the channel. So now you can't pay me any 00:18:53.620 --> 00:18:54.080 more Bitcoin. 00:18:54.440 --> 00:18:58.020 Right. And there's various magic proposals out there. And I think actual 00:18:58.020 --> 00:19:01.930 implementations that would help you move that money back with an on-chain 00:19:01.930 --> 00:19:05.310 transaction. So the money is on one side of the channel again. And again, this is 00:19:05.310 --> 00:19:08.970 the sort of stuff, ideally, your software automates for you. So you don't have to 00:19:08.970 --> 00:19:13.710 worry about it. You know, it sounds complicated. But then I would recommend that 00:19:13.710 --> 00:19:18.610 you read up on exactly how credit cards processing works and how the SWIFT 00:19:18.610 --> 00:19:23.310 payment system works. And you may discover that, you know, that's probably more 00:19:23.310 --> 00:19:23.810 complicated. 00:19:24.250 --> 00:19:28.070 Okay, so let's say people want to use Lightning, Sjors? What do they do? What do 00:19:28.070 --> 00:19:28.490 you recommend? 00:19:29.020 --> 00:19:33.440 Yeah, so it kind of depends on your skill level and your enthusiasm. I would say 00:19:33.440 --> 00:19:38.900 on the very user-friendly side, if you want to try it on mobile, consider 00:19:38.900 --> 00:19:44.460 Breez for iOS or Phoenix for Android. Those wallets 00:19:44.460 --> 00:19:49.620 really try to just show you a number that's your Bitcoin, and then you scan 00:19:49.620 --> 00:19:53.860 something and you hit pay, and it pays. And under the hood, it does a whole bunch 00:19:53.860 --> 00:19:59.690 of magic. But it still has the keys that are on your phone, and there's 00:19:59.690 --> 00:20:04.430 actually sort of a node running on your phone. Although the node uses filters, 00:20:04.450 --> 00:20:07.890 and it uses the server for some things. 00:20:09.350 --> 00:20:13.630 So there are some trade-offs there, but I think it's pretty good. So it's not a 00:20:13.630 --> 00:20:17.750 custodial solution, basically, but it's sort of pushing towards that in some 00:20:17.750 --> 00:20:22.210 trade-offs. Then on the other extreme, if you don't mind using Linux, you can 00:20:22.210 --> 00:20:25.830 install C-Lightning. You install Bitcoin Core and then you install C-Lightning 00:20:25.830 --> 00:20:29.850 and then you can really manually open your channels and manage all that stuff. 00:20:30.370 --> 00:20:35.130 LND is another implementation that you can also just install. It comes with a 00:20:35.130 --> 00:20:41.030 desktop support in the form of Zap, I think, among other applications. 00:20:41.350 --> 00:20:45.110 So you can have a graphical interface, but still manually control your channels. 00:20:45.330 --> 00:20:50.390 But it also has some magic autopilot stuff. So it's kind of in between there. 00:20:51.050 --> 00:20:52.580 Yeah. I mean, have fun. 00:20:52.800 --> 00:20:53.880 I've been using Eclair. 00:20:54.760 --> 00:21:00.300 Yeah, so Eclair is by the same company that made Phoenix. And it is actually, it 00:21:00.300 --> 00:21:05.850 runs on your Android phone, and it is a full Lightning node, but it's not a full 00:21:05.850 --> 00:21:08.550 Bitcoin node. It is a lightweight Bitcoin node. 00:21:08.750 --> 00:21:08.910 Yeah. 00:21:09.170 --> 00:21:12.810 It uses Electrum servers. But other than that, it's a full Lightning node, and it 00:21:12.810 --> 00:21:13.310 works great. 00:21:13.510 --> 00:21:13.930 It works. 00:21:14.630 --> 00:21:16.930 So, yeah. Lots of things you can do. 00:21:18.140 --> 00:21:23.360 Yeah. And as mentioned, there's lots more complexities and interesting new 00:21:23.360 --> 00:21:27.260 features and improvements and all these kinds of things. But we're not going to 00:21:27.260 --> 00:21:28.640 touch on any of these now. 00:21:29.060 --> 00:21:33.400 No. And I think another thing to bear in mind is that, I mean, it'd be nice if 00:21:33.400 --> 00:21:37.640 there was a simpler solution. But you know, the universe just puts a certain 00:21:37.640 --> 00:21:41.160 constraint on what is possible. Like, if if we decide that… 00:21:41.160 --> 00:21:41.720 Damn universe. 00:21:41.720 --> 00:21:46.010 We you know, we want to be able to verify everything that's happening on Bitcoin 00:21:46.010 --> 00:21:49.530 because we don't want people to cheat. We don't want to trust people. So we have 00:21:49.530 --> 00:21:52.850 to be able to verify all these blocks so the blocks can be a lot bigger than they 00:21:52.850 --> 00:21:58.450 are, at least not in the short run. And then what's the next solution that does 00:21:58.450 --> 00:22:03.660 not involve handing your keys to somebody else? It looks like that's probably 00:22:03.660 --> 00:22:07.140 Lightning. I haven't seen anything that's simpler, although we're going to talk 00:22:07.140 --> 00:22:09.400 about some other concept next week, perhaps. 00:22:09.720 --> 00:22:13.480 I keep reading on like Bitcoin Cash websites that Lightning doesn't work. 00:22:14.920 --> 00:22:16.800 Yeah, well, I feel really sorry for them. 00:22:16.960 --> 00:22:20.600 I don't understand why because it's working fine as far as I can tell. 00:22:20.740 --> 00:22:21.100 I think so too. 00:22:21.100 --> 00:22:21.900 I use it all the time. 00:22:22.040 --> 00:22:26.700 There's an interesting stat on a site that I work on, called 00:22:26.700 --> 00:22:32.640 forkmonitor.info. It's by BitMEX Research, but I work on it. And 00:22:32.640 --> 00:22:37.820 it has a tab called Lightning. And what it shows you is the justice transactions. 00:22:38.640 --> 00:22:39.960 And so there have been… 00:22:39.960 --> 00:22:44.140 Right. So these are the transactions: If someone tries to cheat, they have to 00:22:44.140 --> 00:22:47.640 wait. And during that waiting time, you can claim all the funds. 00:22:47.980 --> 00:22:52.460 Exactly. And this is called justice transaction. Although it could also be, you 00:22:52.460 --> 00:22:56.800 know, oops, I screwed up my backup transaction. Yeah. 00:22:56.920 --> 00:22:58.960 Sometimes it's also called a penalty transaction. 00:22:59.300 --> 00:22:59.740 Yeah. 00:22:59.880 --> 00:23:01.320 Or that's what it was used to call it. 00:23:02.570 --> 00:23:06.230 People call it different things. But anyway, there's only been 300 in the history 00:23:06.230 --> 00:23:09.720 of Lightning and they're all tiny. So what that tells me… 00:23:09.670 --> 00:23:13.160 So that means there's either not a lot of cheating going on, cheating attempts, 00:23:13.360 --> 00:23:16.200 or they aren't [unclear] if they happen. 00:23:16.420 --> 00:23:19.500 So there is quite a bit of money in Lightning channels. We don't know the full 00:23:19.500 --> 00:23:23.260 amount because a lot of Lightning channels are private, so you can't see it. But 00:23:23.260 --> 00:23:29.180 there is significant amounts of money in Lightning that might be worth stealing, 00:23:29.480 --> 00:23:34.260 yet doesn't look like that's happened. At least it hasn't happened through this 00:23:34.260 --> 00:23:38.810 cheating approach. You know, somebody might hack your node and just take all the 00:23:38.810 --> 00:23:42.930 money without cheating from a Lightning point of view. But I think that's a sign 00:23:42.930 --> 00:23:46.810 that it is working. But of course, you could also say, well, Lightning only 00:23:46.810 --> 00:23:49.350 launched in 2017, 00:23:50.740 --> 00:23:51.500 the end of 2017. 00:23:52.740 --> 00:23:58.240 So maybe everybody's still very kumbaya. That's three years of kumbaya, maybe. 00:23:58.640 --> 00:24:02.220 Maybe it'll completely collapse. But so far, people are making channels. People 00:24:02.220 --> 00:24:03.800 are making payments. Yeah. 00:24:04.580 --> 00:24:04.960 Good. 00:24:05.860 --> 00:24:09.500 Yeah. All right. So I'm sure we'll come back to this topic some other time. 00:24:09.660 --> 00:24:10.180 I think so too. 00:24:10.420 --> 00:24:12.680 Thank you for listening to the Van Wirdum Sjorsnado. 00:24:13.080 --> 00:24:13.700 There you go.