WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:18.100 --> 00:00:20.260 Live from Utrecht, this is Bitcoin. 00:00:21.040 --> 00:00:21.640 Explained. 00:00:22.340 --> 00:00:23.620 Sjors, I have a problem. 00:00:24.600 --> 00:00:25.200 You have a problem? 00:00:25.340 --> 00:00:30.040 I have Bitcoins laying around everywhere. Bitcoins on exchanges, Bitcoins in hot 00:00:30.040 --> 00:00:32.320 wallets, Bitcoins in paper wallets, 00:00:32.460 --> 00:00:33.580 Bitcoins in ETFs. 00:00:33.980 --> 00:00:37.120 Is there a safe place to store my Bitcoin, Sjors? 00:00:37.320 --> 00:00:41.480 There might be, because we have a sponsor, and they're called Coinkite. 00:00:42.320 --> 00:00:44.900 And they produce the COLDCARD, I heard. 00:00:45.060 --> 00:00:45.460 That's right. 00:00:45.660 --> 00:00:47.980 A hardware wallet for your Bitcoins. 00:00:48.300 --> 00:00:53.210 And it supports PSBT, partially signed Bitcoin transactions. 00:00:54.200 --> 00:00:59.620 Great. Okay, Sjors and dear listener. So we've been getting 00:00:59.620 --> 00:01:05.320 requests over the past years, basically to sometimes make more 00:01:05.320 --> 00:01:06.820 Lightning-specific episodes. 00:01:07.220 --> 00:01:10.280 Indeed. Although we know that Lightning is dead. 00:01:11.280 --> 00:01:12.080 Is it? 00:01:12.480 --> 00:01:13.700 That's what Twitter says. 00:01:14.360 --> 00:01:16.240 What do they say? Why is it that? 00:01:16.580 --> 00:01:17.240 I don't know. 00:01:19.160 --> 00:01:22.180 I used it today. It worked. It worked for me. 00:01:23.360 --> 00:01:23.840 Okay. 00:01:24.620 --> 00:01:30.320 Good. So the request is to make Lightning-specific episodes sometimes. 00:01:30.660 --> 00:01:36.560 However, Sjors and I both kind of feel out of our depth when it comes to at 00:01:36.560 --> 00:01:41.440 least more advanced Lightning topics. We've discussed this in the episode before 00:01:41.440 --> 00:01:46.000 where you can really sort of see that the development communities of Bitcoin and 00:01:46.000 --> 00:01:50.740 Lightning are kind of starting to separate a bit, specialize a bit. There's 00:01:50.740 --> 00:01:56.460 overlap, obviously, but there's definitely sort of more. Bitcoin-focused, you 00:01:56.460 --> 00:02:00.140 know, technological experts and developers and those that focus more on 00:02:00.140 --> 00:02:04.970 Lightning. But we do want to incorporate more Lightning topics in our episodes. 00:02:05.530 --> 00:02:10.700 So we're happy that today we have a special guest. Jesse. 00:02:11.360 --> 00:02:12.300 Good to be here. 00:02:12.420 --> 00:02:13.100 How are you, Jesse? 00:02:13.890 --> 00:02:15.110 Good, good. 00:02:15.310 --> 00:02:16.030 Now, who are you? 00:02:16.270 --> 00:02:22.330 Who am I? I'm a Lightning developer, and I work for Breez. My name is Jesse de Wit. 00:02:22.990 --> 00:02:23.770 Jesse de Wit. 00:02:23.870 --> 00:02:28.280 Jesse de Wit. It's an impossible name to pronounce in English. 00:02:29.480 --> 00:02:33.810 I just did pronounce it in English. Anyways, never mind. Move on. 00:02:34.150 --> 00:02:39.990 Okay. Yeah, so I work on Lightning for Breez, mostly working on 00:02:39.990 --> 00:02:45.830 Lightning service provider stuff and also Breez SDK. And yeah, I'm quite well 00:02:45.830 --> 00:02:48.390 read into the Lightning specifics these days. 00:02:48.670 --> 00:02:53.970 Awesome. Yeah. So thanks a lot for coming on. So yeah, we had sort of a list of 00:02:53.970 --> 00:02:58.810 Lightning topics that we wanted to cover at some point. And earlier this week, we 00:02:58.810 --> 00:03:03.610 read this list to you. And the one that sort of sprung out for you to cover is 00:03:03.610 --> 00:03:05.150 asynchronous payments. 00:03:05.570 --> 00:03:05.850 Exactly. 00:03:06.210 --> 00:03:11.760 And the nice thing about that is you mentioned if we... cover asynchronous 00:03:11.760 --> 00:03:15.720 payments, then we sort of at the same time also tackle two other topics that were 00:03:15.720 --> 00:03:20.620 already on our list that we can sort of all wrap into one episode, basically, 00:03:20.840 --> 00:03:23.000 because it sort of supports each other, right? 00:03:24.140 --> 00:03:29.060 Yes. Yeah, and we'll touch on the topics later on, I suppose, when we cover async 00:03:29.060 --> 00:03:29.460 payments. 00:03:30.060 --> 00:03:33.380 Yeah, well, I'll spoil this. So the other two that we're sort of going to touch 00:03:33.380 --> 00:03:37.450 on are PTLCs, and trampoline payments are also gonna… 00:03:37.450 --> 00:03:42.130 Yes, we'll touch on them, uh briefly. We'll not go into depth, like exactly how 00:03:42.130 --> 00:03:45.750 they work, but uh yeah, they definitely are necessary for asynchronous payments. 00:03:45.750 --> 00:03:51.710 Okay, awesome. So asynchronous payments I guess the first the 00:03:51.710 --> 00:03:56.690 starting point is what is it or maybe why is it needed like what are we talking about? 00:03:56.690 --> 00:04:02.100 Yeah, so in the Lightning network um if Alice is trying to pay Bob 00:04:02.870 --> 00:04:06.510 They both have to be online at the same time in order for a Lightning payment to 00:04:06.510 --> 00:04:12.070 settle. And users are just not used to that these days anymore, right? People use 00:04:12.070 --> 00:04:17.770 texts and every communication now happens asynchronously. So in Lightning 00:04:17.770 --> 00:04:21.510 payments, users just expect it to work asynchronously as well. 00:04:21.770 --> 00:04:25.790 And in Bitcoin, they're also used to... payments being asynchronous, right? You 00:04:25.790 --> 00:04:28.670 have an address, you send money to it whenever you want. 00:04:28.950 --> 00:04:32.630 Exactly, yeah. So you don't have to be online at the same time for that. 00:04:32.990 --> 00:04:36.690 Yeah, so to give a very concrete example of something that happened to me this 00:04:36.690 --> 00:04:40.290 week and also allows me one more option to show my book. 00:04:40.830 --> 00:04:41.450 That's all right. 00:04:41.890 --> 00:04:45.490 Yeah, so someone wanted to buy the Genesis book from me, like an autographed 00:04:45.490 --> 00:04:49.330 version, and then he emailed me and he wanted to pay in Lightning. And I said, 00:04:49.390 --> 00:04:53.420 yeah, sure, that's fine. And then I sent him back, using the Breez wallet 00:04:53.420 --> 00:04:58.000 actually, a Lightning address. But obviously then I have to keep my wallet open 00:04:58.000 --> 00:05:02.400 and I don't know for how long before he's going to make the payment. So that kind 00:05:02.400 --> 00:05:05.700 of stuff is just very complicated with Lightning. So in the end, I sent him an 00:05:05.700 --> 00:05:10.160 on-chain address because that way he can just send whenever he wants. So 00:05:10.160 --> 00:05:16.040 essentially that is what we, you Lightning developers, are trying to achieve 00:05:18.180 --> 00:05:23.380 With Lightning as well, you can send an invoice that can be paid at any point. Is 00:05:23.380 --> 00:05:24.760 that even the right way of framing it? 00:05:24.800 --> 00:05:29.640 Yeah, so maybe you can walk into the problem that you had first because, well, 00:05:29.700 --> 00:05:35.220 first of all, your app has to be running. It needs CPU time in order to sign 00:05:35.220 --> 00:05:37.860 messages for receiving the Lightning payment. 00:05:38.580 --> 00:05:40.340 And it needs to receive data, right? 00:05:40.640 --> 00:05:44.340 Yeah, it needs to receive data and it needs to sign messages, exactly. 00:05:46.350 --> 00:05:49.810 So if you're not online, well, you won't be able to do that, and so you won't be 00:05:49.810 --> 00:05:55.530 able to receive the payment. But if, let's say, Alice 00:05:55.530 --> 00:06:01.430 is trying to send a payment and she's sending it to you, then Alice is 00:06:01.430 --> 00:06:05.910 going to find a route over the Lightning Network. And a naive thing you could try 00:06:05.910 --> 00:06:11.870 to do is just the last hop, which for you was the Breez LSP, Breez Lightning 00:06:11.870 --> 00:06:15.130 Service Provider, which is the node that you are connected to. 00:06:16.980 --> 00:06:22.620 could hold the payment until you come online and then forward the payment to you. 00:06:23.720 --> 00:06:28.680 That would be a naive approach in trying to solve that Alice and you don't have 00:06:28.680 --> 00:06:29.900 to be online at the same time. 00:06:30.120 --> 00:06:34.280 And it's naive, I would assume, because in that case, Breez can steal my money? 00:06:34.540 --> 00:06:38.180 No, it definitely [unclear] steal your money. But the problem is we're locking 00:06:38.180 --> 00:06:44.090 liquidity in the network right now if we do this. So because Alice 00:06:44.090 --> 00:06:48.910 is her payment, maybe we can explain a little bit what a Lightning payment is 00:06:48.910 --> 00:06:54.630 first. So first you allocate, you find a route through the network. So you go, 00:06:55.390 --> 00:07:00.510 yeah, you find a path over different nodes, over different channels. 00:07:00.850 --> 00:07:06.170 And then when sending a payment, first you're going to allocate liquidity in each 00:07:06.170 --> 00:07:11.440 of these channels that's sort of locked. 00:07:13.340 --> 00:07:19.290 until you get the pre-image back that comes from you whenever you settle 00:07:19.290 --> 00:07:23.630 the payment. Pre-image comes back to Alice, and only then are the funds released. 00:07:24.260 --> 00:07:28.740 Yeah, so I guess another way to describe it is there's a secret at the end of the 00:07:28.740 --> 00:07:34.600 tunnel, essentially. So the payee, the person receiving the payment, has a 00:07:34.600 --> 00:07:40.580 secret. and the person making the payment has to allocate 00:07:40.580 --> 00:07:44.940 liquidity, and then every hop does the same thing, and then the last hop gets the 00:07:44.940 --> 00:07:49.860 secret, and then sends it back to the payer. So there's information that goes 00:07:49.860 --> 00:07:54.440 from the sender to the recipient, and then this information has to go back from 00:07:54.440 --> 00:07:59.290 the recipient to the sender. And as long as that information has not made the 00:07:59.290 --> 00:08:03.190 full return trip, the liquidity is locked up all over the channel. 00:08:03.530 --> 00:08:08.950 Yeah, so all over the network, the liquidity will be locked. And well, that's 00:08:08.950 --> 00:08:12.410 something we don't want in the Lightning Network. Usually when a payment is 00:08:12.410 --> 00:08:18.310 happy, in a happy flow, these payments settle within a second, right? But if 00:08:18.310 --> 00:08:23.190 you just turn your phone off for a day, then liquidity is suddenly locked for an 00:08:23.190 --> 00:08:23.710 entire day. 00:08:24.350 --> 00:08:25.850 Why is this a problem? 00:08:26.380 --> 00:08:31.640 Yeah, it's a problem because of that feature I just described. Yeah, you would 00:08:31.640 --> 00:08:36.880 expect the liquidity to settle very quickly over the Lightning Network. So if you 00:08:36.880 --> 00:08:42.240 lock this liquidity for a long time, you're locking it in multiple channels as 00:08:42.240 --> 00:08:48.120 well. So the amount of your payment is locked over multiple channels. you 00:08:48.120 --> 00:08:53.380 exponentially degrade the ability of the Lightning Network to be able to forward 00:08:53.380 --> 00:08:54.140 payments this way. 00:08:54.240 --> 00:08:58.960 It basically means you need bigger channels, right? Because if you're only using 00:08:58.960 --> 00:09:04.710 channels one second at a time, then maybe a one Bitcoin channel is enough. But if 00:09:04.710 --> 00:09:09.450 that one Bitcoin is just locked up for two weeks, then you need a much bigger channel. 00:09:09.990 --> 00:09:14.230 Okay, and just from my understanding, is this the only problem we're trying to 00:09:14.230 --> 00:09:18.590 solve? Let's say we would all use bigger channels. Would that just sort of also 00:09:18.590 --> 00:09:19.950 solve the problem in that sense? 00:09:20.230 --> 00:09:25.110 No, if people start sending more payments, then bigger channels are no longer an 00:09:25.110 --> 00:09:28.410 option anymore. Or no longer work. 00:09:28.790 --> 00:09:34.140 Okay, and is this... Is this the problem we're trying to solve or are there other 00:09:34.140 --> 00:09:35.640 problems involved as well? 00:09:36.100 --> 00:09:41.660 Yeah, so there's two aspects of this. One of them is that we don't want to lock 00:09:41.660 --> 00:09:45.780 this liquidity in the network while the payment is in flight. And the other one 00:09:45.780 --> 00:09:49.880 also has to do with the invoice generation. 00:09:51.600 --> 00:09:56.580 Because Alice and Bob presumably are not online at the same time, they maybe 00:09:56.580 --> 00:10:02.580 won't exchange an invoice. So Alice needs a way to statically create an invoice. 00:10:03.120 --> 00:10:07.860 Right, because an example of your book, you created an invoice, but only once you 00:10:07.860 --> 00:10:12.620 saw the email. So whoever wanted to buy the book had to wait for you to do that. 00:10:12.820 --> 00:10:16.440 And it'd be better if the person who wants to buy the book does not have to wait 00:10:16.440 --> 00:10:20.000 for you to make an invoice. But then the problem is that standard Lightning 00:10:20.000 --> 00:10:25.480 invoices, the BOLT 11 format, you can pay them once. So 00:10:25.480 --> 00:10:28.980 you can make an invoice and say, well, whoever is the first person to buy my book 00:10:28.980 --> 00:10:32.640 paid this invoice. But now if you want to scale that and you want to sell 00:10:32.640 --> 00:10:36.300 multiple books, well, you probably have to make multiple invoices and put them on 00:10:36.300 --> 00:10:40.120 your website and tell people to pick which one. I don't know. 00:10:40.400 --> 00:10:45.300 Okay, so let's cover that problem first. I need a way to sort of automatically 00:10:45.300 --> 00:10:48.400 generate invoices even though my phone is switched off, I guess. 00:10:48.800 --> 00:10:54.350 Yeah, so if you would currently create a BOLT 11 00:10:54.350 --> 00:10:57.350 invoice, which is the invoice format we use on the Lightning Network today, 00:10:58.670 --> 00:11:03.090 If you get that invoice paid, then you release the pre-image, which is your 00:11:03.090 --> 00:11:09.080 secret, which is the payment secret. And so nobody else 00:11:09.080 --> 00:11:12.800 will be able to pay that again because an intermediate node would be able to 00:11:12.800 --> 00:11:17.340 intercept. your payment and settle the payment without the payment ever arriving 00:11:17.340 --> 00:11:19.780 to you because he already knows the secret. 00:11:20.060 --> 00:11:24.420 Yeah, the secret can only be used once for one payment flow, essentially. 00:11:24.760 --> 00:11:28.220 Yeah, so the secret can only be used once, which means the invoice can only be used. 00:11:28.300 --> 00:11:32.660 And this is a secret that I'm generating on my Breez wallet app. 00:11:32.760 --> 00:11:33.880 Yeah, basically a random number. 00:11:34.100 --> 00:11:34.480 Yeah. 00:11:36.740 --> 00:11:41.260 So first we need to tackle that. And the best way to do that is to create an 00:11:41.260 --> 00:11:44.120 actually a static invoice, which would be reusable. 00:11:45.580 --> 00:11:50.420 So you could just post that on your website, say, well, a book costs this and 00:11:50.420 --> 00:11:55.780 this much money. And senders would be able to pay to this invoice an infinite 00:11:55.780 --> 00:12:01.720 amount of times. And for that we... We need a different model, and this 00:12:01.720 --> 00:12:07.620 different model works with PTLCs. So currently, the way we described, you've 00:12:07.620 --> 00:12:11.960 got a secret, and this secret is hashed into the invoice, 00:12:12.670 --> 00:12:18.390 and then HTLCs are sent over the Lightning Network. I think you've covered this 00:12:18.390 --> 00:12:19.350 in Lightning episodes. 00:12:19.970 --> 00:12:25.830 We have previously tried to explain, but we generally also explained what hashes are. 00:12:27.320 --> 00:12:32.340 We definitely had a basic Lightning explainer episode at one point, and I'm sure 00:12:32.340 --> 00:12:35.460 we must have covered this, yeah. It was a couple of years ago, so I don't 00:12:35.460 --> 00:12:37.360 remember exactly, but presumably, yes. 00:12:37.660 --> 00:12:41.620 But the hash of the secret, that's what you're sending to the other side, and the 00:12:41.620 --> 00:12:45.060 other side says, please give me the secret that belongs to this hash, and that's 00:12:45.060 --> 00:12:47.300 really the message you're forwarding along all these channels. 00:12:48.880 --> 00:12:52.380 Right, so that's called an HTLC. So what is a PTLC? 00:12:52.800 --> 00:12:57.800 Yeah, it's basically sort of the same construct, only instead of having a 00:12:57.800 --> 00:13:02.980 pre-image and a hash, you have a private key and a public key, which is called a 00:13:02.980 --> 00:13:07.480 payment point. And that's why it's called a point time lock contract. So it's not 00:13:07.480 --> 00:13:12.340 a hash time lock contract, but a point time lock contract. And the trick with 00:13:12.340 --> 00:13:15.500 these public keys is that you can tweak them. 00:13:18.010 --> 00:13:23.410 And you can basically derive as much keys as you want from a single public key, 00:13:23.670 --> 00:13:27.910 which you can make an infinite amount of secrets from. 00:13:28.150 --> 00:13:32.330 Yeah, one of our very first episodes talked about Taproot and why Taproot is so 00:13:32.330 --> 00:13:37.990 cool. And one of the aspects of it is that it's very easy to add a number to a 00:13:37.990 --> 00:13:42.410 private key and then add essentially the same number to the public key. 00:13:43.230 --> 00:13:44.750 Well, that's Schnorr, basically, right? 00:13:44.930 --> 00:13:49.750 Yes, and that's already possible with the CDH, but it's just much, much easier 00:13:49.750 --> 00:13:55.690 with Schnorr. And this PTLC construct makes use of that. The ability to 00:13:55.690 --> 00:14:01.630 add some random number to a private key, and the other side can do that to 00:14:01.630 --> 00:14:04.530 the public key. So even if you don't have the public key, you know how to tweak 00:14:04.530 --> 00:14:08.530 it. And you cannot do that with hashes. Because if it hashes, if you take the 00:14:08.530 --> 00:14:13.710 letter A, For example, when you hash it, you get some large number. Then if you 00:14:13.710 --> 00:14:17.890 say, oh, I'm just going to change A to B, well, the other side has no idea. You 00:14:17.890 --> 00:14:21.090 cannot just take the hash of A and then take the hash of B and add them together. 00:14:21.090 --> 00:14:23.210 That's not going to give you the same result. 00:14:24.160 --> 00:14:29.800 Yeah, so it does work with points, with payment points. 00:14:30.000 --> 00:14:35.870 And so what a sender can do is it's going to, for each intermediate hop, generate 00:14:35.870 --> 00:14:40.810 a different secret, basically. So each intermediate hop is going to think that 00:14:40.810 --> 00:14:45.970 it's a different secret than the one the recipient actually created. 00:14:46.490 --> 00:14:51.770 So each intermediate hop won't ever learn the actual secret 00:14:51.770 --> 00:14:54.410 from the payee. 00:14:54.610 --> 00:14:59.150 But how does that work if you're making two payments through the same route? 00:14:59.550 --> 00:15:03.270 Because what is it that makes the second payment different from the first payment? 00:15:03.930 --> 00:15:09.910 So the trick is that Alice, which is the sender, she generates 00:15:09.910 --> 00:15:14.630 a random number as well, which tweaks the public key. 00:15:16.450 --> 00:15:20.930 And the intermediate nodes, they use this tweaked public key 00:15:20.930 --> 00:15:26.890 in order to learn the secret, basically. 00:15:27.410 --> 00:15:29.190 Yeah, so it's never the same secret. 00:15:29.270 --> 00:15:32.230 It's never the same secret, and not for any intermediate hop as well. 00:15:32.490 --> 00:15:37.580 Yeah. So even if two different people make a payment, the sender picks the random 00:15:37.580 --> 00:15:41.520 number, so the recipient doesn't have to do anything. As long as each sender 00:15:41.520 --> 00:15:43.880 picks a random number, they cannot reuse the same secret. 00:15:44.760 --> 00:15:48.600 Yeah, and it's in the best interest of the sender to pick a random number then, 00:15:48.780 --> 00:15:51.960 because it's his payment that will be stolen otherwise. 00:15:53.160 --> 00:15:58.860 Okay, so in this case, I'm trying to sell the Genesis book to 00:15:58.860 --> 00:16:04.010 someone, so I got to generate an invoice. who's generating, 00:16:04.390 --> 00:16:07.650 where does this generation happen? What happens exactly? 00:16:07.750 --> 00:16:12.990 Yeah, so you create an invoice and it's got a payment point inside of your 00:16:12.990 --> 00:16:17.330 invoice and you just put that up on your website. I'm a sender, I scan your 00:16:17.330 --> 00:16:22.490 invoice and I'm going to tweak your payment points with random numbers 00:16:22.490 --> 00:16:28.310 along the route so nobody learns about the actual secret when the secret 00:16:28.310 --> 00:16:30.310 comes back to the sender. 00:16:30.470 --> 00:16:33.730 Right. Okay, got it. That part makes sense to me. 00:16:34.190 --> 00:16:39.110 So that removes the interactivity from you having to make an invoice. But in this 00:16:39.110 --> 00:16:44.610 scenario, you're still online because you are clearly receiving the payment and 00:16:44.610 --> 00:16:46.730 sending back the secret every time somebody makes a payment. 00:16:46.990 --> 00:16:50.390 Yeah, so that was the second part of the problem I think we're trying to solve, 00:16:50.510 --> 00:16:54.710 right? Now my phone is, you know, I emailed this guy back or whatever. My phone 00:16:54.710 --> 00:16:58.500 is switched off and now I still need to receive. the payment without locking 00:16:58.500 --> 00:17:01.880 these funds along all these channels because that screws up. 00:17:02.040 --> 00:17:04.780 So your friend has downloaded the invoice from your website instead of having to 00:17:04.780 --> 00:17:09.560 send you an email. But in this, so far, we've still reached the point where, 00:17:09.600 --> 00:17:12.720 okay, they don't have to email you anymore. They just make the payment, but your 00:17:12.720 --> 00:17:14.480 wallet still needs to be online to receive the payment. 00:17:14.720 --> 00:17:17.480 Yes. Okay, so how do we solve this problem, Jesse? 00:17:17.680 --> 00:17:22.980 Okay, let's go over how async payments works then. So Alice is going to pay Bob 00:17:22.980 --> 00:17:28.970 and Alice is going to be connected to the Lightning Network through 00:17:28.970 --> 00:17:33.650 a Lightning service provider. And Bob is going to be connected to the Lightning 00:17:33.650 --> 00:17:38.730 network through a Lightning service provider. Where a Lightning service provider 00:17:38.730 --> 00:17:44.570 is basically just a node that you're connected to the Lightning network. 00:17:46.090 --> 00:17:48.490 And this node is well connected to the Lightning network. 00:17:48.850 --> 00:17:52.490 Yeah, so the concrete example here would be, for example, Breez I think, right? 00:17:52.630 --> 00:17:57.930 Like my wallet is not a full node. It just connects to Breez's full node. 00:17:58.190 --> 00:18:04.150 Yeah. And Breez's full node is tolerant of you being offline a 00:18:04.150 --> 00:18:07.490 lot, which is why we call this a Lightning service provider. But it could 00:18:07.490 --> 00:18:09.590 basically be any node that's tolerant to that. 00:18:11.560 --> 00:18:16.960 And what Alice is going to do, it's going to 00:18:17.500 --> 00:18:23.250 send the payment to Bob, but it's going to tell 00:18:23.250 --> 00:18:26.730 her LSP, please hold this payment. 00:18:28.230 --> 00:18:30.670 until you receive a message that you can release it. 00:18:31.090 --> 00:18:32.750 She's telling her own LSP that. 00:18:32.830 --> 00:18:36.870 She's telling her own LSP that. And the reason she does that... 00:18:36.870 --> 00:18:41.750 Otherwise, it's a regular Lightning payment with a PTLC then. It's normal. She 00:18:41.750 --> 00:18:45.230 just says to her own service provider, don't send this yet. 00:18:45.630 --> 00:18:48.370 Yeah, exactly. And this message is inside the payment itself. 00:18:49.610 --> 00:18:51.770 So basically, it's a regular Lightning payment. 00:18:52.220 --> 00:18:56.540 And so at this point, Alice's LSP cannot steal the money, right? It's not that 00:18:56.540 --> 00:19:01.440 she's making a payment to her LSP. She is doing the first step of the payment, 00:19:01.680 --> 00:19:06.480 which is giving the pre-image. No, not the pre-image, giving the point. 00:19:07.580 --> 00:19:13.460 basically the public thing of the secret to her payment 00:19:13.460 --> 00:19:18.100 provider who cannot take the money unless they get the secret. And in order to 00:19:18.100 --> 00:19:21.580 get the secret, they have to forward it. But all Alice is doing is saying, oh, 00:19:21.720 --> 00:19:25.040 wait a minute, don't forward it just yet because Bob might not be online. 00:19:25.480 --> 00:19:30.160 Exactly. So we know the reason why she— why the LSP is not forwarding it. 00:19:31.290 --> 00:19:36.920 And what Alice is going to do as well... She's going to send an onion message 00:19:36.920 --> 00:19:42.810 to Bob saying, hey, there's a pending payment here. If you 00:19:42.810 --> 00:19:48.530 want to release that whenever you're online, send a message back along this 00:19:48.530 --> 00:19:52.230 path over here. And there's an encrypted path inside this message as well. 00:19:52.410 --> 00:19:55.010 When you say onion message, what do you mean by that? 00:19:55.210 --> 00:20:01.130 An onion message is, so over the Lightning Network, we route payments over onions 00:20:01.130 --> 00:20:03.530 as well, basically meaning that every hop, 00:20:05.110 --> 00:20:11.110 where this message is routed over, is encrypted. So it sort of becomes an onion 00:20:11.110 --> 00:20:13.850 of encryption, where onions have layers. 00:20:14.170 --> 00:20:19.550 So every point in a route can only see which point is coming next or which 00:20:19.550 --> 00:20:24.480 node is coming next and which node came before it, but cannot see further. In 00:20:24.480 --> 00:20:28.300 either direction. Which we explained a bit in our episode about BOLT 12. 00:20:28.900 --> 00:20:33.500 Yeah, and you can basically send arbitrary messages over this construction, over 00:20:33.500 --> 00:20:35.020 the Lightning Network then. Right. 00:20:36.380 --> 00:20:41.040 And she's going to send this to Bob and with a reply path then to her LSP. 00:20:42.480 --> 00:20:48.000 So Bob will be able to unlock the payment so it actually becomes forwarded. 00:20:48.180 --> 00:20:53.610 But Bob is offline, of course. So the LSP of Bob will hold this Onion message 00:20:53.610 --> 00:20:58.330 until Bob is online. Right? Because the LSP knows, well, I have to forward this 00:20:58.330 --> 00:21:02.210 to Bob. Bob is not there. So I'm just going to wait until Bob is online. 00:21:02.430 --> 00:21:02.670 Right. 00:21:03.030 --> 00:21:06.330 And the LSP cannot read what is in the message. Just knows, like, I have a 00:21:06.330 --> 00:21:09.350 message for Bob. I don't know where it came from, but I'll give it to Bob when 00:21:09.350 --> 00:21:09.930 Bob is online. 00:21:10.590 --> 00:21:13.990 Yeah, and in this case, it's obviously not a problem because no funds are being 00:21:13.990 --> 00:21:15.310 locked up. It's just a message. 00:21:15.670 --> 00:21:15.810 Yeah. 00:21:16.190 --> 00:21:16.270 Yeah. 00:21:16.870 --> 00:21:22.230 Okay, so that's the onion message. Goes first to Bob's service provider, and he 00:21:22.230 --> 00:21:26.110 will forward that to Bob. Bob's gone online. Bob comes online, turns his phone 00:21:26.110 --> 00:21:31.530 on. or Breez app or whatever Lightning app he has sees this message, or probably 00:21:31.530 --> 00:21:33.750 his wallet just responds to the message, I would assume. 00:21:33.970 --> 00:21:34.350 Yeah, yeah, yeah. 00:21:34.370 --> 00:21:35.970 He doesn't have to actually see it. 00:21:36.090 --> 00:21:40.370 Yeah, this all goes automatic, but we will say that his wallet sees the message 00:21:40.370 --> 00:21:44.430 and then is going to reply over that reply path. So he doesn't really know where 00:21:44.430 --> 00:21:48.710 the message is coming from. He just knows that he has to send an onion message 00:21:48.710 --> 00:21:49.910 there in order to unlock it. 00:21:51.570 --> 00:21:56.950 And then, so Alice's LSP, who's still holding that payment right now, 00:21:58.110 --> 00:22:04.010 By the way, Alice, after she sent the onion message to Bob, was able to go 00:22:04.010 --> 00:22:08.810 offline. She could put her phone back in your pocket. It's an important part that 00:22:08.810 --> 00:22:10.290 they don't have to be online at the same time. 00:22:11.790 --> 00:22:16.470 Yeah, because Alice's LSP now has the money in a way. 00:22:16.790 --> 00:22:21.550 Yeah, has the money in a way. And now, so we're now at the point where Alice's 00:22:21.550 --> 00:22:26.670 LSP received the onion message from Bob saying, please forward this payment. Then 00:22:26.670 --> 00:22:31.290 the LSP forwards the payment to Bob, and Bob is online now. So he's able to 00:22:31.290 --> 00:22:36.290 settle the payment. So he's going to release the pre-image. 00:22:37.130 --> 00:22:42.190 The pre-image goes back all the way to Alice's LSP. 00:22:43.800 --> 00:22:48.700 And Alice's LSP, whenever Alice comes online, is able to settle the last piece 00:22:48.700 --> 00:22:53.960 between her and Alice. Because only her channel with Alice is now still in a 00:22:53.960 --> 00:22:56.250 state where funds are... In Limbo. 00:22:56.510 --> 00:22:56.870 Right. 00:22:57.050 --> 00:23:01.590 Yeah, so I guess the only player in this story that needs to hold funds in Limbo 00:23:01.590 --> 00:23:05.970 in a channel longer than you'd normally want to do is the channel between Alice 00:23:05.970 --> 00:23:09.990 and her Lightning service provider. So obviously the Lightning service provider 00:23:09.990 --> 00:23:15.390 will want to be compensated for that in a way. But if Alice is a mobile node, 00:23:15.670 --> 00:23:19.550 then that money is probably going to be stuck, kind of stuck anyway, because if 00:23:19.550 --> 00:23:23.130 she's not online, they can't route through it and she probably doesn't have any 00:23:23.130 --> 00:23:25.920 other channels. It's not a routing node anyway. 00:23:26.140 --> 00:23:30.400 And LSP will already allocate liquidity towards these users. 00:23:31.940 --> 00:23:35.980 So I don't think there will be any specific compensation for this, just probably 00:23:35.980 --> 00:23:39.200 for the fact of being a Lightning service provider and allocating liquidity. 00:23:39.660 --> 00:23:41.080 Maybe you'll pay something for that. 00:23:42.240 --> 00:23:46.640 We promised, or I promised, that we would also cover trampoline payments. Where 00:23:46.640 --> 00:23:47.460 does this come in? 00:23:48.220 --> 00:23:51.060 In some situations, it would just work this way, right? 00:23:51.280 --> 00:23:55.580 In some situations, it would just work. But there is actually a problem, because 00:23:55.580 --> 00:24:00.340 if Alice finds a route for this payment over the Lightning network to Bob, 00:24:01.810 --> 00:24:06.290 Usually in Lightning, what happens is you find a route, you try the route, and 00:24:06.290 --> 00:24:10.440 then somewhere along the route, Either a node is offline or doesn't have enough 00:24:10.440 --> 00:24:10.860 liquidity. 00:24:12.200 --> 00:24:16.240 And this route fails. And what your node is going to do is going to find another route. 00:24:16.420 --> 00:24:20.220 And this is also, by the way, where I'd like to shill the episode with Rene 00:24:20.220 --> 00:24:21.760 Pickhardt we did a few years ago. 00:24:23.680 --> 00:24:29.680 Explaining sort of his pathfinding optimal way of making payments. 00:24:29.800 --> 00:24:31.640 But it also involves lots of attempts. 00:24:33.380 --> 00:24:37.580 Yeah, quite a few attempts to get a payment through. It's by design, there's some 00:24:37.580 --> 00:24:41.960 privacy in the Lightning Protocol, so you don't know exactly how much room there 00:24:41.960 --> 00:24:47.060 is in all the channels along the route. You know how big the channel is, but you 00:24:47.060 --> 00:24:50.040 don't know where the money is in that channel, so you don't know how much you can 00:24:50.040 --> 00:24:52.820 actually send through it. And this changes every time as well. 00:24:53.640 --> 00:24:56.460 That was a short special, I believe, right? 00:24:56.900 --> 00:24:57.260 Yes. 00:24:58.250 --> 00:24:59.870 But you don't know the episode, I'm sure? 00:25:00.090 --> 00:25:00.310 No. 00:25:00.670 --> 00:25:00.850 Okay. 00:25:01.470 --> 00:25:07.370 Okay. Yeah, so Alice, if she created this first route and this route fails, that 00:25:07.370 --> 00:25:10.970 would mean that she would only retry whenever she comes back online again. You 00:25:10.970 --> 00:25:16.490 don't know when that is. So what Alice can do is she can delegate the pathfinding 00:25:16.490 --> 00:25:22.100 to another node. And this is a feature in the Lightning Network that's 00:25:22.100 --> 00:25:27.880 being implemented in several node implementations. ACINQ already 00:25:27.880 --> 00:25:32.830 uses it, and it's called Trampoline Payments. So basically, Alice is going to ask 00:25:32.830 --> 00:25:38.510 her LSP, please, I want to forward this payment to this direction. 00:25:39.200 --> 00:25:43.180 Please, do you find the best path over the Lightning Network? And I'm just going 00:25:43.180 --> 00:25:44.840 to chill and go offline now. 00:25:45.170 --> 00:25:49.770 Yeah, and so this works by providing a carte blanche in terms of fees, right? 00:25:49.910 --> 00:25:53.850 Because normally when you establish the route, you know exactly how much fees you 00:25:53.850 --> 00:25:57.310 need to pay at every hop. But because you're not establishing the route, you're 00:25:57.310 --> 00:26:01.530 just going to say, well, here's 100 sats. You figure it out. And if you find a 00:26:01.530 --> 00:26:03.430 cheaper route, you keep the change. 00:26:04.010 --> 00:26:08.870 Exactly, yeah. So you give them some kind of margin. And it could be a 00:26:08.870 --> 00:26:14.270 competition for trampoline nodes as well to say, well, I'm the cheapest because I 00:26:14.270 --> 00:26:16.110 know how to find the best routes in the network. 00:26:16.310 --> 00:26:21.070 Exactly, like the London taxi drivers that have the knowledge and they can find 00:26:21.070 --> 00:26:24.990 the shortest route through London without a GPS and they usually are actually 00:26:24.990 --> 00:26:28.990 faster than the Uber drivers that just follow Google Maps, according to legend. 00:26:31.800 --> 00:26:37.560 So Alice's LSP is now able to retry this payment whenever it 00:26:37.560 --> 00:26:43.560 fails, and so would be able to reach Bob, hopefully in a timely manner, before 00:26:43.560 --> 00:26:44.740 Bob goes offline again. 00:26:44.980 --> 00:26:48.600 And so this ingredient is useful, like we said, because the Lightning network 00:26:48.600 --> 00:26:52.880 changes all the time, you need to do multiple attempts, and so this trampoline 00:26:52.880 --> 00:26:58.840 router can just try it multiple times, basically. The 00:26:58.840 --> 00:27:02.660 downside, of course, is privacy. Because the trampoline now knows where the 00:27:02.660 --> 00:27:03.320 payment is going. 00:27:04.180 --> 00:27:10.130 Yes. So the first part of this is Bob in his invoice 00:27:10.130 --> 00:27:12.830 could have created a blinded path. 00:27:14.250 --> 00:27:19.850 So that's one part of this where the intermediate node would not actually find 00:27:19.850 --> 00:27:22.710 the destination, right? The trampoline node would not find the destination. 00:27:24.090 --> 00:27:30.030 And another way to deal with this is to select multiple trampoline 00:27:30.030 --> 00:27:36.000 hops. in your route so we're now using one trampoline 00:27:36.000 --> 00:27:41.880 node So Alice's LSP is going to find different routes, but you could tell Alice's 00:27:41.880 --> 00:27:47.140 LSP, so first find a route to this random trampoline node, then find a route, 00:27:47.300 --> 00:27:51.680 then that trampoline node has to find a route to that random trampoline node. So 00:27:51.680 --> 00:27:57.620 you could, if you value your privacy, you could diffuse the pathfinding a little 00:27:57.620 --> 00:27:58.520 bit that way. 00:27:59.240 --> 00:28:04.740 Okay, I guess one maybe concern that sort of comes to my mind. 00:28:05.100 --> 00:28:10.260 but I'll let you address that, is it sort of sounds like this would make 00:28:10.260 --> 00:28:15.420 Lightning users very dependent on service providers. 00:28:16.320 --> 00:28:21.990 Sjors mentioned that they're also more general risk, and I'm asking if 00:28:22.120 --> 00:28:27.280 it works for a Lightning service provider, but is this a reasonable concern in 00:28:27.280 --> 00:28:30.820 your view, or in Sjors's view maybe? But let's hear from Jesse first. 00:28:31.380 --> 00:28:33.740 Yeah, from my point of view, it depends on how... 00:28:34.030 --> 00:28:37.190