1 00:00:18,280 --> 00:00:20,600 Life from interest. This is Bitcoin. 2 00:00:20,720 --> 00:00:23,920 Explained. Sure, I have a problem. 3 00:00:24,720 --> 00:00:26,880 I have. I have bitcoins laying around 4 00:00:26,880 --> 00:00:30,080 everywhere, Bitcoins on exchanges, bitcoins in hot 5 00:00:30,080 --> 00:00:32,400 wallets, bitcoins in paper wallets. 6 00:00:32,400 --> 00:00:36,160 Bitcoins in ETFs. Is there a safe place to store 7 00:00:36,160 --> 00:00:38,920 my Bitcoin shorts? There might be because we have a 8 00:00:38,920 --> 00:00:41,600 sponsor and they're called coin kite. 9 00:00:42,640 --> 00:00:46,480 And they produce the cold card. I heard that's right, a hardware 10 00:00:46,480 --> 00:00:52,200 wallet for your bitcoins. And it supports PSPT partially 11 00:00:52,200 --> 00:00:54,960 signed Bitcoin transactions. Great. 12 00:00:55,600 --> 00:01:00,800 OK, short and dear listener. So we've been getting requests 13 00:01:00,800 --> 00:01:05,840 over the past years basically to sometimes make more lightning 14 00:01:05,840 --> 00:01:09,360 specific episodes. Indeed, although we know that 15 00:01:09,600 --> 00:01:12,200 lightning is dead. Is it? 16 00:01:12,840 --> 00:01:15,440 That's what Twitter says. What did they say? 17 00:01:15,720 --> 00:01:17,800 Why is it that? I don't know. 18 00:01:19,480 --> 00:01:21,320 I used it today. It worked. 19 00:01:21,480 --> 00:01:23,960 It worked for me. OK. 20 00:01:24,960 --> 00:01:28,400 Good. So we're making the the request 21 00:01:28,400 --> 00:01:29,960 is to make Lightning specific episodes. 22 00:01:29,960 --> 00:01:34,600 Sometimes, however short and I both kind of feel out of our 23 00:01:34,600 --> 00:01:38,960 depth when it comes to at least more advanced Lightning topics. 24 00:01:39,760 --> 00:01:42,240 We've discussed this in the episode before where you can 25 00:01:42,240 --> 00:01:45,440 really sort of see that the development communities of 26 00:01:45,440 --> 00:01:49,120 Bitcoin and Lightning are kind of starting to separate a bit, 27 00:01:49,120 --> 00:01:52,000 specialized a bit. There's overlap, obviously, but 28 00:01:52,000 --> 00:01:56,640 there's definitely sort of more Bitcoin focused, you know, 29 00:01:56,640 --> 00:01:59,840 technological experts and developers and those that focus 30 00:01:59,840 --> 00:02:03,320 more on lightning. But we do want to incorporate 31 00:02:03,320 --> 00:02:05,280 more lightning topics in our episodes. 32 00:02:05,760 --> 00:02:09,240 So we're happy that today we have a special guest. 33 00:02:10,440 --> 00:02:12,440 Yes, Sir. Good to be here. 34 00:02:12,480 --> 00:02:13,320 How are you? Yes, Sir. 35 00:02:14,200 --> 00:02:15,320 Good. Good. 36 00:02:15,400 --> 00:02:16,160 Now, who are you? Who? 37 00:02:16,680 --> 00:02:19,880 Am I? I'm a Lightning developer and I 38 00:02:19,880 --> 00:02:22,440 work for Breeze. My name is Yessa David. 39 00:02:23,200 --> 00:02:25,000 Jesse the White. Jesse the Wit. 40 00:02:26,240 --> 00:02:29,680 It's an impossible name to pronounce in English and. 41 00:02:30,280 --> 00:02:33,080 I just did pronounce it in English anyways, never mind, 42 00:02:33,440 --> 00:02:37,720 move on. OK yeah so I I work on Lightning 43 00:02:37,720 --> 00:02:41,680 for Breeze, mostly working on Lightning service provider stuff 44 00:02:42,080 --> 00:02:46,120 and also Breeze SDK. And yeah, I'm quite well read 45 00:02:46,120 --> 00:02:48,560 into the Lightning specifics these days. 46 00:02:48,760 --> 00:02:49,200 Awesome. Yeah. 47 00:02:49,200 --> 00:02:53,680 So thanks a lot for coming on. So yeah, we had sort of a list 48 00:02:53,680 --> 00:02:57,000 of lighting topics that that we wanted to cover at some point. 49 00:02:57,240 --> 00:03:01,320 And earlier this week we read this list to you and the one 50 00:03:01,320 --> 00:03:04,760 that sort of sprung out for you to cover is asynchronous 51 00:03:04,760 --> 00:03:06,000 payments. Exactly. 52 00:03:06,320 --> 00:03:11,320 And the nice thing about that is you mentioned if we cover 53 00:03:11,320 --> 00:03:14,200 asynchronous payments, then we sort of at the same time also 54 00:03:14,200 --> 00:03:17,480 tackle two other topics that were already on our list that we 55 00:03:17,480 --> 00:03:21,440 can sort of all wrap into one episode basically because it, it 56 00:03:21,440 --> 00:03:23,160 sort of supports each other, right? 57 00:03:23,640 --> 00:03:25,120 So. Yes, yeah. 58 00:03:25,120 --> 00:03:28,280 And we will, we'll touch on the topics later on, I suppose when 59 00:03:28,280 --> 00:03:30,400 we cover async payments. Yeah. 60 00:03:30,400 --> 00:03:32,880 Well, I'll, I'll spoil this. So the other two that we're sort 61 00:03:32,880 --> 00:03:37,320 of going to touch on are PTLCS and trampoline payments are also 62 00:03:37,320 --> 00:03:38,960 going. To yes, we'll touch on them 63 00:03:39,240 --> 00:03:41,560 briefly. We'll not go into depth like 64 00:03:41,560 --> 00:03:44,720 exactly how they work, but yeah, they definitely are necessary 65 00:03:44,720 --> 00:03:47,240 for asynchronous payments. OK, awesome. 66 00:03:47,680 --> 00:03:52,080 So asynchronous payments, I guess the first the starting 67 00:03:52,080 --> 00:03:55,680 point is what is it or maybe why is it needed? 68 00:03:55,680 --> 00:03:58,360 Like what are we talking about? Yeah, so in the Lightning 69 00:03:58,360 --> 00:04:04,040 network, if Alice is trying to pay Bob, they both have to be 70 00:04:04,040 --> 00:04:06,520 online at the same time in order for a lightning payment to 71 00:04:06,520 --> 00:04:09,600 settle. And the people users are just 72 00:04:09,760 --> 00:04:11,400 not using that these days anymore, right? 73 00:04:11,400 --> 00:04:15,760 So people use texts and every communication now happens 74 00:04:15,760 --> 00:04:18,760 asynchronously. So in Lightning Payments, users 75 00:04:18,760 --> 00:04:21,640 just expect it to work asynchronously as well. 76 00:04:22,040 --> 00:04:25,040 And in Bitcoin, so you're also used to payments being 77 00:04:25,040 --> 00:04:26,480 asynchronous, right? You have an address. 78 00:04:26,480 --> 00:04:28,840 You sent some money to it whenever you want. 79 00:04:28,920 --> 00:04:31,440 Exactly, Yeah. So you don't have to be online 80 00:04:31,440 --> 00:04:35,000 at the same time for that. Yeah, So to give a very concrete 81 00:04:35,000 --> 00:04:37,760 example of something that happened to me this week and 82 00:04:37,760 --> 00:04:40,440 also allows me one more option to show my book. 83 00:04:41,120 --> 00:04:42,360 That's all right. It's yeah. 84 00:04:42,360 --> 00:04:44,960 So someone wanted to buy the Genesis book from me, like an 85 00:04:44,960 --> 00:04:47,480 autograph version. And then he emailed me and he 86 00:04:47,480 --> 00:04:50,520 wanted to pay in Lightning and I said, yeah, sure, that's fine. 87 00:04:50,960 --> 00:04:53,440 And then sent him back. You know, using the Breeze wall 88 00:04:53,440 --> 00:04:56,680 is actually a Lightning address. But obviously then I have to 89 00:04:56,680 --> 00:04:59,560 like keep my wallet open and I don't know for how long because 90 00:04:59,600 --> 00:05:01,960 before it's going to make the payment. 91 00:05:01,960 --> 00:05:04,600 So that kind of stuff is just very complicated with Lightning. 92 00:05:04,600 --> 00:05:07,880 So in the end I sent him an on chain address because that way 93 00:05:08,040 --> 00:05:09,440 you can just send whenever he wants. 94 00:05:09,920 --> 00:05:15,000 So essentially that is what we, you lightning developers are 95 00:05:15,000 --> 00:05:19,480 trying to achieve with lightning as well. 96 00:05:19,480 --> 00:05:23,240 You can send a invoice that can be paid at any point. 97 00:05:23,240 --> 00:05:24,680 Is that even the right way of framing? 98 00:05:24,680 --> 00:05:26,600 It yeah. So maybe you can walk into the 99 00:05:26,600 --> 00:05:30,600 problem that you had first because well, first of all, your 100 00:05:30,600 --> 00:05:34,200 app has to be running. It needs CPU time in order to 101 00:05:34,920 --> 00:05:38,000 sign messages for receiving the lightning payment. 102 00:05:38,600 --> 00:05:40,480 And it needs to receive data, right? 103 00:05:40,720 --> 00:05:43,800 Yeah, it needs to receive data and it needs to sign messages. 104 00:05:44,000 --> 00:05:45,640 Exactly. So. 105 00:05:46,480 --> 00:05:48,920 So if you're not online, well, you won't be able to do that. 106 00:05:49,000 --> 00:05:50,880 And so you won't be able to receive the payment. 107 00:05:51,280 --> 00:05:57,200 But if you, if Bob, if let's say Alice is trying to send a 108 00:05:57,200 --> 00:06:02,000 payment and she's sending it to you, then Alice is going to find 109 00:06:02,000 --> 00:06:03,400 a route over the Lightning network. 110 00:06:03,600 --> 00:06:08,240 And a naive thing you would what could try to do is just the last 111 00:06:08,240 --> 00:06:11,160 hop which is for you was the Breeze LSB. 112 00:06:11,360 --> 00:06:14,240 Breeze Lightning service provider, which is the node that 113 00:06:14,240 --> 00:06:19,800 you are connected to, could hold the payment until you come 114 00:06:19,800 --> 00:06:22,680 online and then forward the payment to you. 115 00:06:24,040 --> 00:06:27,400 There will be a naive approach in trying to solve that Alice, 116 00:06:27,800 --> 00:06:30,000 and you don't have to be online at the same time. 117 00:06:30,440 --> 00:06:33,520 And it's naive, I would assume, because in that case Breeze can 118 00:06:33,560 --> 00:06:35,840 steal my money. No, they definitely can steal 119 00:06:35,840 --> 00:06:38,240 your money. But the problem is we're locking 120 00:06:38,240 --> 00:06:41,720 liquidity in the network right now if we do this. 121 00:06:42,280 --> 00:06:47,320 So because Alice is Alice's repayment, maybe we can explain 122 00:06:47,320 --> 00:06:49,680 a little bit what a lightning payment is first. 123 00:06:50,120 --> 00:06:53,760 So first you allocate, you find a route through the network. 124 00:06:54,000 --> 00:06:59,880 So you go, yeah, you you find a path over different nodes, over 125 00:06:59,880 --> 00:07:03,600 different channels and then you're when sending a payment, 126 00:07:03,800 --> 00:07:06,520 first you're going to allocate liquidity in each of these 127 00:07:06,520 --> 00:07:14,840 channels that will be that's sort of locked until you get the 128 00:07:14,840 --> 00:07:19,080 pre image back that comes from from you when whenever you 129 00:07:19,080 --> 00:07:22,440 settle the payment pre image comes back to Alice and only 130 00:07:22,440 --> 00:07:24,800 then are the funds released. Yeah. 131 00:07:24,800 --> 00:07:27,760 So I guess another way to describe is there's, there's a 132 00:07:27,760 --> 00:07:30,080 secret at the end of the tunnel essentially right there. 133 00:07:30,080 --> 00:07:33,400 So that the payee, no the, yeah, the payee, the person receiving 134 00:07:33,400 --> 00:07:39,400 the payment has a secret and the person making the payment has to 135 00:07:40,240 --> 00:07:43,480 allocate liquidity and then like every hop does the same thing 136 00:07:43,600 --> 00:07:47,080 and then the last hop gets the secret and then sends it back to 137 00:07:47,080 --> 00:07:49,440 the payer. So there there's information 138 00:07:49,440 --> 00:07:52,600 that goes towards the from the from the sender to the 139 00:07:52,600 --> 00:07:54,320 recipient, and then there's information that has to go back 140 00:07:54,320 --> 00:07:56,320 from the recipient to the sender. 141 00:07:56,800 --> 00:07:59,800 And as long as that information has not made the full return 142 00:07:59,800 --> 00:08:03,320 trip, the liquidity is locked up all over the channel. 143 00:08:03,560 --> 00:08:05,160 Yeah. So all over the network the 144 00:08:06,040 --> 00:08:09,640 liquidity will be locked and well that's that's something we 145 00:08:09,640 --> 00:08:12,720 don't want into Lighting network was usually when a payment is is 146 00:08:12,720 --> 00:08:15,760 happy with in a happy flow, these payments settle within a 147 00:08:15,760 --> 00:08:19,840 second, right. But if you just turn your phone 148 00:08:19,840 --> 00:08:23,160 off for a day, then liquidity is suddenly locked for for an 149 00:08:23,160 --> 00:08:26,000 entire day. Why is this a problem? 150 00:08:26,680 --> 00:08:29,520 Yeah, it's a problem because of that feature that I just 151 00:08:29,520 --> 00:08:32,559 described. Yeah, you would expect the 152 00:08:32,760 --> 00:08:36,200 liquidity to settle very quickly over the Lightning Network. 153 00:08:36,440 --> 00:08:41,080 So if you lock this liquidity for a long time, you're locking 154 00:08:41,080 --> 00:08:44,640 it in multiple channels as well. So the amount of your payment is 155 00:08:44,640 --> 00:08:49,840 locked over multiple channels, so you exponentially degrade the 156 00:08:50,640 --> 00:08:53,520 the ability of the lightning network to be able to forward 157 00:08:53,520 --> 00:08:55,640 payments this way it. Basically means you need bigger 158 00:08:55,640 --> 00:08:59,040 channels, right? Because if you're only using 159 00:08:59,040 --> 00:09:02,800 channels one second at a time, then maybe a one Bitcoin channel 160 00:09:02,800 --> 00:09:06,000 is enough. But if the you know, if that one 161 00:09:06,000 --> 00:09:08,960 Bitcoin is just locked up for two weeks, then you need a much 162 00:09:08,960 --> 00:09:11,000 bigger channel. OK, and just for my 163 00:09:11,000 --> 00:09:14,520 understanding, is this the only problem we're trying to solve 164 00:09:14,520 --> 00:09:17,760 like is let's say we would all use bigger channels, would that 165 00:09:17,760 --> 00:09:20,120 just sort of also solve the problem in that sense? 166 00:09:20,480 --> 00:09:22,360 No, no. If if people start sending more 167 00:09:22,360 --> 00:09:25,800 payments, then bigger channels are no longer an option anymore 168 00:09:26,480 --> 00:09:29,400 or don't no longer work. Yeah, OK. 169 00:09:29,400 --> 00:09:33,360 And is this is this the problem we're trying to solve, or is 170 00:09:33,360 --> 00:09:35,720 there are other problems involved as well? 171 00:09:36,240 --> 00:09:38,680 Yeah. So the main, so there's two 172 00:09:38,800 --> 00:09:40,720 aspects of this. There's one of them is that we 173 00:09:40,720 --> 00:09:43,320 don't want to look lock this liquidity in the network while 174 00:09:43,320 --> 00:09:47,920 the payment is in flight. And the other one is also has to 175 00:09:47,920 --> 00:09:53,120 do with the invoice generation. So because Alice and Bob 176 00:09:53,960 --> 00:09:56,800 presumably are not online at the same time, they won't maybe 177 00:09:56,800 --> 00:10:01,120 won't exchange an invoice. So Alice needs a way to 178 00:10:01,120 --> 00:10:04,880 statically create an invoice. Because an example of your book, 179 00:10:04,880 --> 00:10:08,720 you created an invoice, but only once you saw the e-mail. 180 00:10:09,280 --> 00:10:12,240 So yeah, whoever wanted to buy the book had to wait for you to 181 00:10:12,240 --> 00:10:14,760 do that. And it'd be better if the person 182 00:10:14,760 --> 00:10:16,920 who wants to buy the book does not have to wait for you to make 183 00:10:16,920 --> 00:10:19,120 an invoice. But then the problem is that 184 00:10:19,240 --> 00:10:24,160 standard lightning invoices, the Bolt 11 format, you can pay them 185 00:10:24,160 --> 00:10:26,920 once, right? So, So you can make an invoice 186 00:10:26,920 --> 00:10:29,280 and say, well, whoever is the first person to buy my book, pay 187 00:10:29,280 --> 00:10:31,960 this invoice. But now if you want to scale 188 00:10:31,960 --> 00:10:33,640 that and you want to sell multiple books, well you'd 189 00:10:33,640 --> 00:10:36,440 probably have to make multiple invoices and put them on your 190 00:10:36,440 --> 00:10:39,720 website and tell people to pick which one. 191 00:10:39,720 --> 00:10:42,360 I don't know. OK, so let's cover that problem 192 00:10:42,360 --> 00:10:44,800 first. I I need a way to sort of 193 00:10:44,800 --> 00:10:47,920 automatically generate invoices even though my phone is switched 194 00:10:47,960 --> 00:10:49,160 off I guess. Right. 195 00:10:50,000 --> 00:10:52,600 Yeah. So yeah, so if you would 196 00:10:52,720 --> 00:10:55,840 currently create a BOLT 11 invoice, which is the invoice 197 00:10:55,840 --> 00:10:57,480 format we use on a lighting network today. 198 00:10:59,000 --> 00:11:02,400 If you get that invoice paid, then you release the the pre 199 00:11:02,400 --> 00:11:06,920 image which is your secret, which is the payment secret and 200 00:11:08,480 --> 00:11:10,960 so nobody else will be able to pay that again because an 201 00:11:10,960 --> 00:11:15,400 intermediate node would be able to intercept your payment and 202 00:11:15,400 --> 00:11:18,360 settle the payment without the payment ever arriving to you 203 00:11:18,360 --> 00:11:19,960 because he already knows the secret. 204 00:11:20,320 --> 00:11:23,440 Yeah, the secrets can only be used once for a for a one 205 00:11:23,440 --> 00:11:26,040 payment flow essentially. Yeah, so the secret can only be 206 00:11:26,040 --> 00:11:28,320 used once, which means the invoice can only be used. 207 00:11:28,320 --> 00:11:32,480 And this is a secret that I'm generating on my Breeze Bullet 208 00:11:32,480 --> 00:11:34,000 app. Basically a random number. 209 00:11:34,320 --> 00:11:38,440 Yeah yeah, so. So first we need to tackle that 210 00:11:38,440 --> 00:11:41,720 and the the best way to do that is to create an actually a 211 00:11:41,760 --> 00:11:44,360 static invoice which would be reusable. 212 00:11:45,800 --> 00:11:48,120 So you could just post that on your website. 213 00:11:48,120 --> 00:11:52,640 Say well a book costs this and this cost money and senders 214 00:11:52,640 --> 00:11:56,200 would be able to pay to this invoice an infinite amount of 215 00:11:56,200 --> 00:12:00,240 times. And for that we we need a 216 00:12:00,240 --> 00:12:03,000 different model. And this different model works 217 00:12:03,000 --> 00:12:05,840 with PTLCS. So currently the way we 218 00:12:05,840 --> 00:12:11,480 described, you've got a secret, and this secret is hashed into 219 00:12:11,480 --> 00:12:16,840 the invoice, which and then and then HCLCS are sent over the 220 00:12:16,840 --> 00:12:18,640 lightning network. I think you've covered this in 221 00:12:18,640 --> 00:12:21,520 Lightning episodes. We've previously tried to 222 00:12:21,520 --> 00:12:25,960 explain what we generally also explain what hashes are. 223 00:12:27,440 --> 00:12:30,480 So we definitely had like a basic Lightner lightning 224 00:12:30,480 --> 00:12:32,920 explainer episode at one point, and I'm sure we must have 225 00:12:32,920 --> 00:12:34,960 covered this. Yeah, It's a couple of years 226 00:12:34,960 --> 00:12:37,520 ago, so I don't remember exactly, but presumably yes. 227 00:12:37,840 --> 00:12:39,520 But the hash, it's the hash of the secret. 228 00:12:39,760 --> 00:12:41,440 That's what you're sending to the other side. 229 00:12:41,440 --> 00:12:43,440 And the other side says, if, please give me the secret that 230 00:12:43,440 --> 00:12:45,680 belongs to this hash. And that's really the message 231 00:12:45,680 --> 00:12:47,520 you're forwarding along all these channels. 232 00:12:49,160 --> 00:12:50,840 Right. So that's called an HTLC. 233 00:12:50,840 --> 00:12:54,080 So what is a PTLC? Yeah, and it's basically sort of 234 00:12:54,080 --> 00:12:58,560 the same construct, only instead of having a pre image and a 235 00:12:58,560 --> 00:13:02,960 hash, you have a private key and a public key which is called a 236 00:13:02,960 --> 00:13:05,840 payment point. And that's why it's called a 237 00:13:05,840 --> 00:13:08,640 point time lock contract. So it's not a hash time lock 238 00:13:08,640 --> 00:13:10,440 contract, but a point time lock contract. 239 00:13:11,240 --> 00:13:15,640 And the trick with these public keys is you can tweak them, 240 00:13:17,120 --> 00:13:20,840 which make them so, and you can basically derive as much keys as 241 00:13:20,840 --> 00:13:25,280 you want from a single public key which make them yeah, you 242 00:13:25,280 --> 00:13:28,080 can make an infinite amount of secrets from. 243 00:13:28,400 --> 00:13:31,200 Yeah, one of our very first episodes talked about taproot 244 00:13:31,280 --> 00:13:34,480 and why taproot is so cool. And one of the aspects of it 245 00:13:34,480 --> 00:13:38,840 said it's very easy to add add a number to a private key and then 246 00:13:38,840 --> 00:13:43,600 add essentially the same number to the public key and then well. 247 00:13:43,600 --> 00:13:45,160 That's snore, basically, right? But yeah. 248 00:13:45,160 --> 00:13:48,280 Yes, and that's that's already possible with ECDH, but it's 249 00:13:48,280 --> 00:13:50,720 just much, much easier with Schnorr. 250 00:13:51,280 --> 00:13:54,880 And this PTLC construct makes use of that, right? 251 00:13:54,880 --> 00:13:59,840 But the ability to add some random number to A to a private 252 00:13:59,840 --> 00:14:02,240 key, and the other side can do that to the public key. 253 00:14:02,600 --> 00:14:04,320 So even if you don't have the public key, you know how to 254 00:14:04,320 --> 00:14:05,840 tweak it. And you cannot do that with 255 00:14:05,840 --> 00:14:09,240 hashes, because if it hashes, if you take the number, if you take 256 00:14:09,240 --> 00:14:12,360 the letter A for example, and you hash it, you get some large 257 00:14:12,360 --> 00:14:14,360 number. Then if you say, oh, I'm just 258 00:14:14,360 --> 00:14:17,920 going to change A to B, well the other side has no idea, Like you 259 00:14:17,920 --> 00:14:20,560 cannot just take the hash of A and then take the hash of B and 260 00:14:20,560 --> 00:14:22,040 add them together. That's not going to give you the 261 00:14:22,040 --> 00:14:25,320 same result. Yeah, Yeah. 262 00:14:25,320 --> 00:14:28,800 So and so it is. It does work with with points, 263 00:14:28,800 --> 00:14:31,880 what with payment points. And So what a sender can do is 264 00:14:31,960 --> 00:14:36,040 is going to, for each intermediate hub, generate a 265 00:14:36,040 --> 00:14:38,920 different secret basically. So each intermediate hub is 266 00:14:38,920 --> 00:14:44,600 going to think that the that it's a different secret than the 267 00:14:44,600 --> 00:14:47,360 1 the recipient actually created, and so each 268 00:14:47,360 --> 00:14:54,040 intermediate hub won't ever learn the actual secret from the 269 00:14:54,040 --> 00:14:56,480 PE. But how does how does that work 270 00:14:56,480 --> 00:14:59,320 if you're making two payments to the same route? 271 00:15:00,000 --> 00:15:01,960 Because what's what? What is it that makes a second 272 00:15:02,000 --> 00:15:03,400 payment different from the first payment? 273 00:15:04,160 --> 00:15:08,920 So the trick is that Alice, which is the sender, she 274 00:15:09,560 --> 00:15:13,280 generates a random number as well, which tweaks tweaks the 275 00:15:14,000 --> 00:15:19,800 the public key and the intermediate notes they use. 276 00:15:19,800 --> 00:15:25,800 This tweaks public key as as the the for the in order to in order 277 00:15:25,800 --> 00:15:28,880 to learn the secret basically. Yeah, so it's never the same 278 00:15:28,880 --> 00:15:30,680 secret. It's never the same secret, and 279 00:15:30,680 --> 00:15:32,960 not for any intermediate hub as well, yeah. 280 00:15:33,600 --> 00:15:36,320 So even if two different people make a payment, they both the 281 00:15:36,440 --> 00:15:39,360 the sender picks the random number, so the recipient doesn't 282 00:15:39,360 --> 00:15:41,840 have to do anything. As long as each sender picks a 283 00:15:41,840 --> 00:15:44,080 random number, they cannot reuse the same secret. 284 00:15:44,760 --> 00:15:47,760 Yeah, and it's in the best interest of the sender to pick a 285 00:15:47,800 --> 00:15:51,760 random number then, because it's his payment that will be stolen 286 00:15:51,800 --> 00:15:57,280 otherwise. OK, so in this case, you know 287 00:15:57,280 --> 00:16:00,560 I'm trying to sell the Genesis book to someone, so I got to 288 00:16:00,880 --> 00:16:04,280 generate an invoice. Who's generating? 289 00:16:04,760 --> 00:16:07,760 Why does this generation happen? What happens exactly? 290 00:16:07,760 --> 00:16:11,800 Yeah, so you create an invoice and it's got a payment point 291 00:16:11,800 --> 00:16:14,720 inside inside of your invoice, and you just put that up on your 292 00:16:14,720 --> 00:16:17,400 website. I'm a sender, I scan your 293 00:16:17,400 --> 00:16:22,120 invoice and I'm going to tweak your payment points with random 294 00:16:22,120 --> 00:16:25,760 numbers right along the route, right? 295 00:16:25,760 --> 00:16:28,480 So nobody learns about the actual secret when the secret 296 00:16:28,480 --> 00:16:30,880 comes back to to the sender, right? 297 00:16:31,200 --> 00:16:33,560 OK, got it. That that part makes sense to 298 00:16:33,560 --> 00:16:35,360 me. So that removes the 299 00:16:35,360 --> 00:16:38,240 interactivity from you having to make an invoice. 300 00:16:38,480 --> 00:16:41,560 But in this scenario, you're still online because you are 301 00:16:41,560 --> 00:16:45,760 clearly perceiving the payment and sending back to secret every 302 00:16:45,760 --> 00:16:47,200 time somebody makes a payment. Yeah. 303 00:16:47,200 --> 00:16:50,120 So that was the second part of the problem I think we're trying 304 00:16:50,120 --> 00:16:53,120 to solve right now. My phone is, you know, I emailed 305 00:16:53,360 --> 00:16:55,680 this guy back or whatever. My phone is switched off and now 306 00:16:55,680 --> 00:16:59,080 I still need to receive the payment without locking these 307 00:16:59,080 --> 00:17:02,120 funds along all these channels. Because that's, yeah, so. 308 00:17:02,120 --> 00:17:04,160 Your friend has downloaded the invoice from your website 309 00:17:04,160 --> 00:17:05,680 instead of having to send you an e-mail. 310 00:17:06,359 --> 00:17:09,599 But in this so far we've we've still reached the point where, 311 00:17:09,599 --> 00:17:12,000 OK, they don't have to e-mail you anymore, they just make the 312 00:17:12,000 --> 00:17:13,480 payment. But your wallet still needs to 313 00:17:13,480 --> 00:17:14,640 be online to receive the payment. 314 00:17:14,720 --> 00:17:16,960 Yes. OK, so how do we solve this 315 00:17:16,960 --> 00:17:17,640 problem? Yes, Sir. 316 00:17:17,720 --> 00:17:20,480 OK, let's go over how async payments works then. 317 00:17:21,240 --> 00:17:27,560 So Alice is going to pay Bob and Alice is going to be connected 318 00:17:27,560 --> 00:17:31,920 to the Lightning network through a Lightning Service Provider and 319 00:17:31,920 --> 00:17:34,520 Bob is going to be connected to the lightning network through a 320 00:17:34,520 --> 00:17:38,320 a lightning service provider. Where alert Lightning service 321 00:17:38,320 --> 00:17:43,320 provider is basically just a node that that you're connected 322 00:17:43,320 --> 00:17:47,840 to to the lightning network and this node is well connected to 323 00:17:47,840 --> 00:17:50,120 the lightning network. Yeah so the concrete example 324 00:17:50,120 --> 00:17:52,600 here would be for example breeze I think right? 325 00:17:52,600 --> 00:17:56,560 Like my wallet is not a full node, it just connects to 326 00:17:57,080 --> 00:17:58,800 breezes full nodes. Yeah. 327 00:17:59,080 --> 00:18:04,080 And and Breeze's full node is tolerant of you being offline a 328 00:18:04,080 --> 00:18:07,200 lot, which is why we call this a Lightning service provider. 329 00:18:07,200 --> 00:18:09,680 But it could basically be any node that's tolerant to that. 330 00:18:11,840 --> 00:18:18,840 And what Alice is going to do is going to is going to send the 331 00:18:18,840 --> 00:18:26,200 payment to Bob, but it's going to tell her LSP, please hold 332 00:18:26,200 --> 00:18:30,720 this payment until you receive a message that you can release it. 333 00:18:30,920 --> 00:18:33,960 That she's telling her own LSP. That she's telling her own LSP 334 00:18:33,960 --> 00:18:37,880 that and the reason she doesn't. Otherwise, it's a regular 335 00:18:37,880 --> 00:18:40,920 lighting payment with a PTLC, then it's a regular. 336 00:18:40,920 --> 00:18:44,000 It's normal, she just says to her own service provider. 337 00:18:44,000 --> 00:18:46,240 Don't send this yet. Yeah, exactly. 338 00:18:46,240 --> 00:18:47,760 Yeah. And this message is inside the 339 00:18:47,760 --> 00:18:51,960 payment itself, but so basically it's a regular Lighting payment. 340 00:18:52,560 --> 00:18:55,880 And so at this point the Alice's LSP cannot steal the money, 341 00:18:55,880 --> 00:18:57,200 right? It's not that she's making a 342 00:18:57,200 --> 00:19:01,640 payment to her LSP, she is doing the first step of the payment, 343 00:19:01,840 --> 00:19:05,120 which is giving the pre image. No, not the payment, It's giving 344 00:19:05,120 --> 00:19:11,040 the the point, the basically the the public thing of the secret 345 00:19:11,680 --> 00:19:16,080 to her payment provider who cannot take the money unless 346 00:19:16,400 --> 00:19:18,600 they get the secret. And in order to get the secret 347 00:19:18,600 --> 00:19:21,040 they have to forward it. But all Alice is doing is 348 00:19:21,040 --> 00:19:24,240 saying, oh wait a minute, don't forward it just yet because Bob 349 00:19:24,240 --> 00:19:26,000 might not be online. Exactly. 350 00:19:26,000 --> 00:19:28,040 Yeah. So we know the reason why she 351 00:19:28,120 --> 00:19:33,200 why the LSP is not forwarding, forwarding it, and what Alice is 352 00:19:33,200 --> 00:19:36,600 going to do as well. She's going to send an onion 353 00:19:36,600 --> 00:19:41,640 message to Bob saying, hey, there's a pending payment here. 354 00:19:42,560 --> 00:19:47,360 If you want to release that whenever you're online, send a 355 00:19:47,360 --> 00:19:49,360 message back along this path over here. 356 00:19:49,360 --> 00:19:52,360 And there's an encrypted path inside this message as well. 357 00:19:52,600 --> 00:19:55,040 When you say onion message, what do you mean by that? 358 00:19:55,280 --> 00:19:59,440 An onion message is so over the lighting network we route 359 00:19:59,440 --> 00:20:03,640 payments over onions as well, basically meaning that every hop 360 00:20:05,320 --> 00:20:09,760 where this message is routed over is encrypted, so it sort of 361 00:20:09,760 --> 00:20:13,640 gets becomes an onion of encryption where onions have 362 00:20:13,640 --> 00:20:16,400 layers. So every every point in a route 363 00:20:16,640 --> 00:20:20,520 can only see which point is coming next, or which node is 364 00:20:20,520 --> 00:20:23,240 coming next and which node came before it, but cannot see 365 00:20:23,240 --> 00:20:27,400 further in either direction, which we claimed a bit in our 366 00:20:27,400 --> 00:20:30,600 episode about Bold 12. Yeah, and you can basically send 367 00:20:30,640 --> 00:20:34,040 arbitrary messages over this construction over the liking 368 00:20:34,040 --> 00:20:38,200 network then, right? And she's going to send this to 369 00:20:38,200 --> 00:20:41,240 Bob and with a reply path then to her LSP. 370 00:20:42,760 --> 00:20:46,160 So Bob will be able to unlock the the payment. 371 00:20:46,160 --> 00:20:49,320 So it's it actually becomes forwarded, but Bob is offline of 372 00:20:49,320 --> 00:20:52,920 course. So the LSP is of Bob will hold 373 00:20:52,920 --> 00:20:56,960 this on your message until Bob is online, right, Because the 374 00:20:56,960 --> 00:20:59,960 LSP knows well I have to forward this to Bob, Bob is not there. 375 00:21:00,320 --> 00:21:02,320 So I'm just going to wait until Bob is online. 376 00:21:02,440 --> 00:21:04,840 Right and. The LSP cannot read what is in 377 00:21:04,840 --> 00:21:07,080 the message, just knows like I have a message for Bob. 378 00:21:07,080 --> 00:21:09,600 I don't know where it came from, but I'll give it to Bob when Bob 379 00:21:09,600 --> 00:21:11,080 is online. Yeah. 380 00:21:11,080 --> 00:21:13,720 And in this case, it's obviously not a problem because no funds 381 00:21:13,720 --> 00:21:15,440 are being locked up. It's just a message. 382 00:21:15,640 --> 00:21:18,600 Yeah, yeah. OK, so that's the onion message 383 00:21:18,600 --> 00:21:22,760 goes first to Bob's service provider and he will forward 384 00:21:22,760 --> 00:21:24,360 that to Bob or Bob's going online. 385 00:21:24,360 --> 00:21:25,920 Bob. Bob comes online, turns his 386 00:21:25,920 --> 00:21:29,520 photos on or as you know, Breeze app or whatever Lightning app he 387 00:21:29,560 --> 00:21:32,040 has sees this message, or probably as well. 388 00:21:32,040 --> 00:21:33,880 It just responds to the message I would assume. 389 00:21:33,960 --> 00:21:35,840 Yeah, yeah, yeah. He doesn't have to actually see 390 00:21:35,840 --> 00:21:36,880 it. Yeah, it just all goes 391 00:21:36,880 --> 00:21:39,400 automatic. But we will say that he that his 392 00:21:39,400 --> 00:21:42,400 wallet sees the message and then he's going to reply over the 393 00:21:42,400 --> 00:21:44,520 reply path. So he doesn't really know where 394 00:21:44,520 --> 00:21:46,240 the where the message is coming from. 395 00:21:46,560 --> 00:21:49,040 He just knows that he has to send an onion message there in 396 00:21:49,040 --> 00:21:54,920 order to unlock it and then. So Alice's LSP, who is still 397 00:21:54,920 --> 00:22:01,440 holding that payment right now? By the way, Alice, after she 398 00:22:01,440 --> 00:22:05,160 sent the onion lessons to Bob, was able to go offline, right? 399 00:22:05,160 --> 00:22:07,320 She could put her phone back in her pocket. 400 00:22:07,320 --> 00:22:09,960 So important part that they don't have to be online at the 401 00:22:09,960 --> 00:22:15,880 same time, yeah. Because Alice's LSP now has the 402 00:22:15,880 --> 00:22:18,000 money, in a way. Yeah, has the money in a way. 403 00:22:18,560 --> 00:22:22,440 And now, so we're now at the point where Alice's LSP received 404 00:22:22,440 --> 00:22:25,360 the onion message from Bob saying please forward this 405 00:22:25,360 --> 00:22:27,800 payment. Then the LSP forwards the 406 00:22:27,800 --> 00:22:31,440 payment to Bob, and Bob is online now, so he's able to 407 00:22:32,200 --> 00:22:36,120 settle the payment. So he's going to release the pre 408 00:22:36,120 --> 00:22:41,840 image and the pre image goes back all the way to to Alice's 409 00:22:41,840 --> 00:22:46,360 LSP. And Alice's LSP, whenever Alice 410 00:22:46,360 --> 00:22:50,200 comes online, is able to settle the last piece between her and 411 00:22:50,200 --> 00:22:53,920 Alice, because only her channel with Alice is now still in a 412 00:22:53,920 --> 00:22:56,960 state where funds are in limbo. Right. 413 00:22:57,000 --> 00:22:58,520 Yeah. So the, I guess the only player 414 00:22:58,520 --> 00:23:02,160 in this story that needs to hold funds in, in limbo in a channel 415 00:23:02,160 --> 00:23:05,720 longer than you'd normally want to do is the channel between 416 00:23:05,720 --> 00:23:08,160 Alice and her lightning service provider. 417 00:23:08,160 --> 00:23:11,200 So obviously the Lightning service provider will want to be 418 00:23:11,200 --> 00:23:15,600 compensated for that in a way. But if Alice is a mobile node, 419 00:23:15,600 --> 00:23:18,760 then that money is probably going to be stuck kind of stuck 420 00:23:18,760 --> 00:23:21,280 anyway, because if she's not online, they can route through 421 00:23:21,280 --> 00:23:24,000 it and she probably doesn't have any other channels. 422 00:23:24,000 --> 00:23:26,080 So yeah, it's not a routing node anyway. 423 00:23:26,160 --> 00:23:30,600 And LSP will already allocate liquidity towards these users. 424 00:23:31,920 --> 00:23:35,000 So I don't think there will be any specific compensation for 425 00:23:35,000 --> 00:23:37,760 this, just probably for the fact of being a liking service 426 00:23:37,760 --> 00:23:39,440 provider and allocating liquidity. 427 00:23:39,880 --> 00:23:41,600 Maybe you'll pay something for that, yeah? 428 00:23:42,600 --> 00:23:45,680 We promised, or I promised that we would also cover trampling 429 00:23:45,680 --> 00:23:46,440 payments. Where? 430 00:23:46,440 --> 00:23:48,720 Where does this come in? So there's this in. 431 00:23:48,720 --> 00:23:51,200 In some situations it would just work this way, right? 432 00:23:51,520 --> 00:23:54,520 In some situations it would just work, but there is actually a 433 00:23:54,520 --> 00:23:59,240 problem because if Alice finds a route for this payment over the 434 00:23:59,240 --> 00:24:03,920 lighting network to Bob, usually in Lightning what happens is you 435 00:24:03,920 --> 00:24:07,400 find a route, you try the route and then somewhere along the 436 00:24:07,400 --> 00:24:11,480 route either notice offline or doesn't have enough liquidity or 437 00:24:12,520 --> 00:24:15,320 and this route fails and what you know is going to do is going 438 00:24:15,320 --> 00:24:17,840 to find another route. And this is also, by the way, 439 00:24:17,840 --> 00:24:21,080 where I'd like to shield the episode with Renee Picard we did 440 00:24:21,080 --> 00:24:28,440 a few years ago explaining sort of his his pathfinding, optimal 441 00:24:28,800 --> 00:24:31,240 way of making payments. But it also involves lots of 442 00:24:31,240 --> 00:24:35,000 attempts. Yeah, quite quite a few attempts 443 00:24:35,000 --> 00:24:38,040 to get a payment through. It's by designed as some privacy 444 00:24:38,040 --> 00:24:41,200 in the Lightning protocol. So you don't know exactly how 445 00:24:41,200 --> 00:24:43,560 much room there is in all the channels along the route. 446 00:24:44,640 --> 00:24:48,240 You you know how big the channel is, but you don't know where the 447 00:24:48,240 --> 00:24:50,040 money is in that Channel, so you don't know how much you can 448 00:24:50,040 --> 00:24:52,640 actually send through it. And this changes every time as 449 00:24:52,640 --> 00:24:55,480 well. Yeah, that was, that was a short 450 00:24:55,480 --> 00:24:57,440 special, I believe, right? Yes. 451 00:24:58,560 --> 00:25:00,440 But you don't know the episode, I'm sure, no. 452 00:25:00,640 --> 00:25:01,920 OK. OK. 453 00:25:01,960 --> 00:25:05,040 Yes, Sir. Yeah, so Alice, if she created 454 00:25:05,040 --> 00:25:08,360 this first route and this route fails, that would mean that she 455 00:25:08,360 --> 00:25:10,840 would only retry whenever she comes back online again. 456 00:25:10,840 --> 00:25:14,360 You don't know when that is. So what Alice can do is she can 457 00:25:14,520 --> 00:25:18,160 delegate the path finding to another node. 458 00:25:19,520 --> 00:25:22,720 And this is a feature in the Lightning Network that's being 459 00:25:22,720 --> 00:25:26,560 implemented in in several Node implementations. 460 00:25:27,200 --> 00:25:30,240 Asank already uses it and it's called Trampoline Payments. 461 00:25:31,120 --> 00:25:36,000 So basically Alice is going to ask her LSB please, I want to 462 00:25:36,280 --> 00:25:39,840 forward this payment to this direction please. 463 00:25:39,840 --> 00:25:42,120 Do you find the best path over the light network? 464 00:25:42,120 --> 00:25:44,920 And I'm I'm just going to chill and go offline now. 465 00:25:45,360 --> 00:25:46,960 Yeah. And and so this works by 466 00:25:46,960 --> 00:25:49,840 providing A carte blanche in terms of fees, right? 467 00:25:49,840 --> 00:25:52,560 Because normally when you establish the route, you know 468 00:25:52,560 --> 00:25:54,920 exactly how much fees you need to pay at every hop. 469 00:25:54,920 --> 00:25:57,280 But because you're not establishing the route, you're 470 00:25:57,280 --> 00:26:00,680 just going to say, well, here's a hundred sets, you figure it 471 00:26:00,680 --> 00:26:03,200 out and if you find a cheaper route, you get the you keep the 472 00:26:03,200 --> 00:26:04,680 change. Exactly. 473 00:26:04,720 --> 00:26:05,440 Yeah. Yeah. 474 00:26:05,440 --> 00:26:08,840 So you give them some kind of margin and this could be a 475 00:26:08,840 --> 00:26:12,920 competition for trampoline notes as well to say, well, I'm the 476 00:26:12,920 --> 00:26:15,760 cheapest because I know how to find the best routes in the 477 00:26:15,760 --> 00:26:17,800 network. Exactly like the like the London 478 00:26:17,800 --> 00:26:21,160 taxi drivers that have the knowledge and they they can find 479 00:26:21,160 --> 00:26:24,120 the shortest route through London without AGPS and they 480 00:26:24,120 --> 00:26:26,720 usually are actually faster than the Uber drivers that just 481 00:26:26,920 --> 00:26:29,160 follow Google Maps, according to legend. 482 00:26:31,680 --> 00:26:35,560 And now, so Alice's Alice. Alice's Alice B is now able to 483 00:26:36,000 --> 00:26:40,160 retry this payment, so whenever it fails, and so would be able 484 00:26:40,160 --> 00:26:44,200 to reach Bob, hopefully in a timely manner, before Bob goes 485 00:26:44,200 --> 00:26:46,320 offline again. And so this ingredient is 486 00:26:46,320 --> 00:26:48,040 useful. Like we said, because the 487 00:26:48,040 --> 00:26:49,840 Lightning network changes all the time, you need to do 488 00:26:49,840 --> 00:26:56,120 multiple attempts and so this trample line router, this can 489 00:26:56,120 --> 00:26:58,720 just try it multiple times basically, yeah. 490 00:26:58,720 --> 00:27:02,000 The downside, of course, is privacy, because the trampoline 491 00:27:02,000 --> 00:27:03,520 now knows where the payment is going. 492 00:27:04,440 --> 00:27:08,520 Yes. So the first part of this is Bob 493 00:27:09,320 --> 00:27:12,960 in his invoice could have created a blinded path. 494 00:27:14,680 --> 00:27:17,520 So that's one part of this where you would not actually, where 495 00:27:17,520 --> 00:27:20,800 the intermediate node would not actually find the destination, 496 00:27:20,800 --> 00:27:22,040 right? The trampoline node would not 497 00:27:22,040 --> 00:27:27,640 find the destination, and another way to deal with this is 498 00:27:27,640 --> 00:27:32,760 to select multiple trampoline hops in your route. 499 00:27:32,760 --> 00:27:36,440 So we're now using one trampoline node. 500 00:27:37,400 --> 00:27:40,160 So Alice's LSP is going to find different routes. 501 00:27:40,440 --> 00:27:44,960 But you could tell Alice's LSP. So first find a route to this 502 00:27:44,960 --> 00:27:47,760 random trampoline node, then find a route, and then that 503 00:27:47,760 --> 00:27:50,800 trampoline node has to find a route to that random trampoline 504 00:27:50,800 --> 00:27:53,320 node. So you could, if you value your 505 00:27:53,320 --> 00:27:58,320 privacy, you could diffuse the path finding a little bit that 506 00:27:58,320 --> 00:27:59,200 way. Right. 507 00:27:59,560 --> 00:28:03,440 OK. I guess one maybe concern that 508 00:28:03,440 --> 00:28:07,360 sort of comes to my mind, but I'll let you address that is it 509 00:28:07,360 --> 00:28:13,040 sort of sounds like this would make Lightning users very 510 00:28:13,040 --> 00:28:16,520 dependent on service providers. Sure. 511 00:28:16,760 --> 00:28:22,640 Mentioned they're also more general risk and I'm asked works 512 00:28:22,640 --> 00:28:24,120 for a Lightning service provider. 513 00:28:24,120 --> 00:28:27,720 But, you know, is this a reasonable concern in your view? 514 00:28:27,720 --> 00:28:30,960 Or is your view maybe. But let's hear from Yassa first. 515 00:28:31,440 --> 00:28:33,440 Yeah, from my point of view, it depends on how. 516 00:28:34,320 --> 00:28:37,320 Sure, I said. Let's hear from Yassa first. 517 00:28:38,440 --> 00:28:38,920 OK. OK. 518 00:28:39,000 --> 00:28:41,840 Well, OK. So there's a user that 519 00:28:41,840 --> 00:28:46,920 apparently online lightning node, right? 520 00:28:46,920 --> 00:28:49,520 So he wants to run a lightning node in his pocket. 521 00:28:50,680 --> 00:28:55,880 So that means there's no other way the network through nodes 522 00:28:55,880 --> 00:29:02,120 that are willing to accept that. And as a reminder why there's 523 00:29:02,480 --> 00:29:07,240 William involved here, if if you have a channel but you're 524 00:29:07,240 --> 00:29:11,760 offline all the time. Now if channel and all the money 525 00:29:12,240 --> 00:29:14,840 in the channel is on your own side, then the other side is not 526 00:29:14,840 --> 00:29:18,040 going to care. But if you have made like lots 527 00:29:18,040 --> 00:29:20,720 and lots of payments through the channel, now all the money's on 528 00:29:20,720 --> 00:29:22,720 the other side. The other side is going to be 529 00:29:22,720 --> 00:29:26,960 annoyed by this because when you're offline, they cannot 530 00:29:27,200 --> 00:29:30,760 access that money at all. They can't, but they have to 531 00:29:30,760 --> 00:29:32,280 force close it, which is expensive. 532 00:29:32,720 --> 00:29:34,720 They can't route anything through it because you're 533 00:29:34,720 --> 00:29:35,960 offline. You're not a routing node. 534 00:29:36,240 --> 00:29:39,520 So that money is just they own it, but they're forced huddling 535 00:29:39,520 --> 00:29:42,520 it essentially. And so there is not, not 536 00:29:42,520 --> 00:29:45,080 everybody's going to be willing to just allow you to open a 537 00:29:45,080 --> 00:29:48,280 channel and behave like that. I think right now many nodes 538 00:29:48,280 --> 00:29:51,680 don't care, but they might close the channel on you saying, hey, 539 00:29:51,720 --> 00:29:52,960 this is not making me enough money. 540 00:29:53,280 --> 00:29:55,720 So a Lightning service provider, in the very broad sense, is 541 00:29:55,720 --> 00:30:00,000 anyone who's willing to just put up with a peer that's not online 542 00:30:00,000 --> 00:30:02,240 all the time, probably by charging. 543 00:30:02,680 --> 00:30:08,080 Yeah, how far is this? So there's there's a lot of 544 00:30:08,080 --> 00:30:13,320 prerequisites. So first of all, we need to 545 00:30:13,640 --> 00:30:19,320 taproot channels in order to TEP root channels. 546 00:30:19,320 --> 00:30:24,200 Are L&D implemented the simple TEP root channels protocol which 547 00:30:24,200 --> 00:30:27,320 sort of works with private channels right now, but not with 548 00:30:27,320 --> 00:30:29,480 public? OK, it's. 549 00:30:33,400 --> 00:30:36,560 Basically the the transit. So lightning channels are 550 00:30:36,560 --> 00:30:40,080 basically just commitment transaction, transactions on 551 00:30:40,080 --> 00:30:42,880 chain, right. But you update them locally and 552 00:30:43,000 --> 00:30:46,760 you broadcast don't broadcast many of these that you sign in 553 00:30:46,760 --> 00:30:49,480 between in your channel and these transactions are tap 554 00:30:50,360 --> 00:30:51,760 actions. So that's basically what a 555 00:30:52,240 --> 00:30:53,640 taproot channel is. OK. 556 00:30:55,040 --> 00:30:56,960 So, so it's pretty much what it sounds like. 557 00:30:57,120 --> 00:30:59,400 And that's just, that's just the main transaction. 558 00:30:59,400 --> 00:31:02,320 But then there's the HTLCS, the things that fly over the channel 559 00:31:02,320 --> 00:31:06,760 when you're making a payment, those to make those PTLC another 560 00:31:06,760 --> 00:31:08,640 change, right? You can have taproot channels 561 00:31:08,640 --> 00:31:11,840 that still use locks for the payments. 562 00:31:12,480 --> 00:31:16,800 Yeah and so and also if you use step root channels, you need to 563 00:31:16,800 --> 00:31:18,920 gossip your channel. So you need to tell the rest of 564 00:31:18,920 --> 00:31:26,520 the network like these are the channels that I have and this 565 00:31:26,520 --> 00:31:31,440 also does not exist yet. So, so there's some 566 00:31:31,440 --> 00:31:39,080 prerequisites there on side. And then there is a proposal now 567 00:31:39,080 --> 00:31:43,600 for holding the payment, which is one part of ASYNC payments 568 00:31:44,320 --> 00:31:48,160 where the LSP holds the payment until a message is sent when 569 00:31:48,160 --> 00:31:51,040 it's released. And this standard is within the 570 00:31:51,040 --> 00:31:53,800 protocol itself. So it's not like some custom API 571 00:31:53,800 --> 00:31:56,160 of the Lightning service provider, It's really just part 572 00:31:56,160 --> 00:31:58,560 of the Lightning protocol. Anybody who speaks to Lighting 573 00:31:58,560 --> 00:32:01,200 protocol could hold a payment. Yeah. 574 00:32:01,200 --> 00:32:03,840 So there it would be the question where this ends up 575 00:32:03,840 --> 00:32:12,720 exactly in Bolts, which is is a Lightning Improvement Proposal. 576 00:32:13,640 --> 00:32:15,680 But blips can also be implemented by any node 577 00:32:15,840 --> 00:32:21,440 basically. So there's that part, which is 578 00:32:26,080 --> 00:32:34,440 are currently only supported by CLN in order to be able. 579 00:32:36,480 --> 00:32:40,400 Because on your messages of Bolt 12, right, we just made, we did 580 00:32:40,400 --> 00:32:43,400 a whole episode about BOLT 12. We explained how on your 581 00:32:43,400 --> 00:32:45,560 messages are kind of useful in that scheme. 582 00:32:46,000 --> 00:32:50,680 But BOLT 12 is mostly being pushed by core Lightning and I 583 00:32:50,680 --> 00:32:54,520 guess LDK now. And so you have to wait for I 584 00:32:54,520 --> 00:32:56,080 guess you just need 2 implementations. 585 00:32:56,080 --> 00:32:58,120 But in order for it to be useful, it's nice if LMD 586 00:32:58,120 --> 00:33:00,800 supports it, because like a whole bunch of nodes are 587 00:33:01,280 --> 00:33:04,880 running, LMD in the onion message needs to go from A to B 588 00:33:04,880 --> 00:33:09,720 through all these hops. So if you know I, I think onion 589 00:33:09,720 --> 00:33:11,600 messages can follow any route you like, right? 590 00:33:11,600 --> 00:33:14,720 They don't have to follow any channels that exist, they can 591 00:33:14,720 --> 00:33:16,560 just go through any way through the network. 592 00:33:16,920 --> 00:33:18,760 Yeah, I guess, yeah, they sort of could. 593 00:33:18,760 --> 00:33:21,760 But you only know that people are connected through their 594 00:33:21,760 --> 00:33:23,600 channels usually. Right. 595 00:33:23,600 --> 00:33:26,000 Yeah, yeah, yeah. So so it has to follow some 596 00:33:26,000 --> 00:33:28,880 bunch of channels and and if all these nodes are running LED in 597 00:33:28,880 --> 00:33:31,760 the middle, then you just don't have a way to get your message 598 00:33:31,760 --> 00:33:34,080 to the other side. Yeah. 599 00:33:35,600 --> 00:33:39,080 So I think we probably talked about most of the prerequisites. 600 00:33:39,080 --> 00:33:40,240 Trampoline. Yeah. 601 00:33:40,240 --> 00:33:41,680 So trampoline. Yeah, exactly. 602 00:33:41,760 --> 00:33:45,080 That's done by the assigned people that's used by Phoenix, 603 00:33:45,080 --> 00:33:46,440 but is. It yeah, by the assigned people 604 00:33:46,480 --> 00:33:52,200 now and there's so LDK also implemented parts of it. 605 00:33:52,200 --> 00:33:55,320 I don't think they completed trampoline payments completely. 606 00:33:55,320 --> 00:33:56,840 Please correct me if I'm wrong there. 607 00:33:58,520 --> 00:34:00,640 So that's also not part of the Bolt spec yet. 608 00:34:00,680 --> 00:34:02,280 It's not merged into the spec yet. 609 00:34:02,400 --> 00:34:05,680 OK, so basically there's still a bunch of building blocks that 610 00:34:05,680 --> 00:34:09,040 need to be in place before this can work, and different 611 00:34:09,040 --> 00:34:12,159 implementations are in different stages of completing these 612 00:34:12,159 --> 00:34:13,440 building blocks. Yeah. 613 00:34:13,600 --> 00:34:16,480 So it's basically almost every improvement to the Lighting 614 00:34:16,480 --> 00:34:20,080 Network that we want to have is sort of a prerequisite for async 615 00:34:20,080 --> 00:34:22,040 payments. Sounds easy. 616 00:34:22,040 --> 00:34:23,280 Two weeks. Yeah. 617 00:34:23,600 --> 00:34:27,080 No, it's not going to be two weeks, but and more like several 618 00:34:27,080 --> 00:34:29,480 severally. Is anyone against this? 619 00:34:32,239 --> 00:34:34,040 Is jungle for all against async payments. 620 00:34:34,800 --> 00:34:38,159 He's against everything. So I'm assuming what? 621 00:34:38,159 --> 00:34:40,400 Why are there people against this? 622 00:34:41,480 --> 00:34:44,360 Is this, is this like in any way controversial or are there 623 00:34:44,360 --> 00:34:47,920 concerns about this? Or maybe there are people that 624 00:34:47,920 --> 00:34:50,280 have, you know, developers that have different preferences? 625 00:34:50,280 --> 00:34:54,880 Or is there? People may be against some parts 626 00:34:54,880 --> 00:35:04,480 of the upgrades, yeah, so maybe I I'm not exactly sure about 627 00:35:04,480 --> 00:35:09,080 their reasoning, but one reason I can come up with is that well 628 00:35:09,080 --> 00:35:12,040 on your messages they can also be a DOS factor. 629 00:35:13,600 --> 00:35:15,800 So just, I said. Lalo basically came up with 630 00:35:15,800 --> 00:35:16,440 that. They said. 631 00:35:16,480 --> 00:35:21,320 Just am I misremembering that? I I don't know about this. 632 00:35:21,320 --> 00:35:22,400 Exactly. Oh, never mind. 633 00:35:23,520 --> 00:35:27,760 OK, so they they might be against onion messages. 634 00:35:27,760 --> 00:35:29,520 Or are they against onion messages? 635 00:35:29,520 --> 00:35:31,040 Yeah, you you think? So, well, they're not 636 00:35:31,040 --> 00:35:38,640 implementing it. They they do have so, so LNDK 637 00:35:39,120 --> 00:35:41,720 which is sort of like an extension to L&D which does 638 00:35:41,720 --> 00:35:43,880 support all your messages and. Yeah. 639 00:35:43,880 --> 00:35:46,840 I mean, sometimes, most of the time when somebody doesn't 640 00:35:46,840 --> 00:35:48,920 implement something, it's just because they don't have time for 641 00:35:48,920 --> 00:35:51,280 it because they're working on 6000 other things that have that 642 00:35:51,280 --> 00:35:53,000 priority. It's not that they're opposed to 643 00:35:53,000 --> 00:35:54,320 it. Right. 644 00:35:54,880 --> 00:35:56,200 OK. So as far as you know, there's 645 00:35:56,200 --> 00:36:00,400 not necessarily any opposition to asynchronous payments I. 646 00:36:00,400 --> 00:36:03,200 Don't. I think this is just a great. 647 00:36:03,360 --> 00:36:04,800 Yeah. And and it's also a bit of a 648 00:36:04,800 --> 00:36:08,520 harm, harm reduction thing because people like this ability 649 00:36:08,520 --> 00:36:12,280 to pay to a mobile. So there are already solutions 650 00:36:12,320 --> 00:36:14,880 out there that will just lock up all the liquidity. 651 00:36:16,200 --> 00:36:18,040 Yeah, and that's evil. Lots of problems. 652 00:36:18,040 --> 00:36:20,920 So it's one of those things where it's might be better to 653 00:36:20,920 --> 00:36:23,080 implement it because the alternative is worse. 654 00:36:24,000 --> 00:36:26,960 Right, OK. Does that cover it? 655 00:36:27,200 --> 00:36:28,000 I think so. You got it. 656 00:36:30,080 --> 00:36:33,280 And if you want to shell. Where should people find you? 657 00:36:33,320 --> 00:36:35,720 Yeah, that's a good Should people find you people? 658 00:36:35,720 --> 00:36:38,920 Can find me on Twitter at With the Jesse. 659 00:36:41,720 --> 00:36:46,960 In that case. For a choice. 660 00:36:46,960 --> 00:36:48,480 Indeed. Thank you for listening to 661 00:36:48,480 --> 00:36:49,800 Bitcoin. Explained.