Episode 90: Asynchronous Lightning Payments

Aaron van Wirdum Live from Utrecht, this is Bitcoin.

Sjors Provoost Explained.

Aaron van Wirdum Sjors, I have a problem.

Sjors Provoost You have a problem?

Aaron van Wirdum I have Bitcoins laying around everywhere. Bitcoins on exchanges, Bitcoins in hot wallets, Bitcoins in paper wallets,

Sjors Provoost Bitcoins in ETFs.

Aaron van Wirdum Is there a safe place to store my Bitcoin, Sjors?

Sjors Provoost There might be, because we have a sponsor, and they're called Coinkite.

Aaron van Wirdum And they produce the COLDCARD, I heard.

Sjors Provoost That's right.

Aaron van Wirdum A hardware wallet for your Bitcoins.

Sjors Provoost And it supports PSBT, partially signed Bitcoin transactions.

Aaron van Wirdum Great. Okay, Sjors and dear listener. So we've been getting requests over the past years, basically to sometimes make more Lightning-specific episodes.

Sjors Provoost Indeed. Although we know that Lightning is dead.

Aaron van Wirdum Is it?

Sjors Provoost That's what Twitter says.

Aaron van Wirdum What do they say? Why is it that?

Sjors Provoost I don't know.

Aaron van Wirdum I used it today. It worked. It worked for me.

Sjors Provoost Okay.

Aaron van Wirdum Good. So the request is to make Lightning-specific episodes sometimes. However, Sjors and I both kind of feel out of our depth when it comes to at least more advanced Lightning topics. We've discussed this in the episode before where you can really sort of see that the development communities of Bitcoin and Lightning are kind of starting to separate a bit, specialize a bit. There's overlap, obviously, but there's definitely sort of more. Bitcoin-focused, you know, technological experts and developers and those that focus more on Lightning. But we do want to incorporate more Lightning topics in our episodes. So we're happy that today we have a special guest. Jesse.

Jesse de Wit Good to be here.

Aaron van Wirdum How are you, Jesse?

Jesse de Wit Good, good.

Aaron van Wirdum Now, who are you?

Jesse de Wit Who am I? I'm a Lightning developer, and I work for Breez. My name is Jesse de Wit.

Aaron van Wirdum Jesse de Wit.

Jesse de Wit Jesse de Wit. It's an impossible name to pronounce in English.

Aaron van Wirdum I just did pronounce it in English. Anyways, never mind. Move on.

Jesse de Wit Okay. Yeah, so I work on Lightning for Breez, mostly working on Lightning service provider stuff and also Breez SDK. And yeah, I'm quite well read into the Lightning specifics these days.

Aaron van Wirdum Awesome. Yeah. So thanks a lot for coming on. So yeah, we had sort of a list of Lightning topics that we wanted to cover at some point. And earlier this week, we read this list to you. And the one that sort of sprung out for you to cover is asynchronous payments.

Jesse de Wit Exactly.

Aaron van Wirdum And the nice thing about that is you mentioned if we... cover asynchronous payments, then we sort of at the same time also tackle two other topics that were already on our list that we can sort of all wrap into one episode, basically, because it sort of supports each other, right?

Jesse de Wit Yes. Yeah, and we'll touch on the topics later on, I suppose, when we cover async payments.

Aaron van Wirdum Yeah, well, I'll spoil this. So the other two that we're sort of going to touch on are PTLCs, and trampoline payments are also gonna…

Jesse de Wit Yes, we'll touch on them, uh briefly. We'll not go into depth, like exactly how they work, but uh yeah, they definitely are necessary for asynchronous payments.

Aaron van Wirdum Okay, awesome. So asynchronous payments I guess the first the starting point is what is it or maybe why is it needed like what are we talking about?

Jesse de Wit Yeah, so in the Lightning network um if Alice is trying to pay Bob They both have to be online at the same time in order for a Lightning payment to settle. And users are just not used to that these days anymore, right? People use texts and every communication now happens asynchronously. So in Lightning payments, users just expect it to work asynchronously as well.

Sjors Provoost And in Bitcoin, they're also used to... payments being asynchronous, right? You have an address, you send money to it whenever you want.

Jesse de Wit Exactly, yeah. So you don't have to be online at the same time for that.

Aaron van Wirdum Yeah, so to give a very concrete example of something that happened to me this week and also allows me one more option to show my book.

Sjors Provoost That's all right.

Aaron van Wirdum Yeah, so someone wanted to buy the Genesis book from me, like an autographed version, and then he emailed me and he wanted to pay in Lightning. And I said, yeah, sure, that's fine. And then I sent him back, using the Breez wallet actually, a Lightning address. But obviously then I have to keep my wallet open and I don't know for how long before he's going to make the payment. So that kind of stuff is just very complicated with Lightning. So in the end, I sent him an on-chain address because that way he can just send whenever he wants. So essentially that is what we, you Lightning developers, are trying to achieve With Lightning as well, you can send an invoice that can be paid at any point. Is that even the right way of framing it?

Jesse de Wit Yeah, so maybe you can walk into the problem that you had first because, well, first of all, your app has to be running. It needs CPU time in order to sign messages for receiving the Lightning payment.

Sjors Provoost And it needs to receive data, right?

Jesse de Wit Yeah, it needs to receive data and it needs to sign messages, exactly. So if you're not online, well, you won't be able to do that, and so you won't be able to receive the payment. But if, let's say, Alice is trying to send a payment and she's sending it to you, then Alice is going to find a route over the Lightning Network. And a naive thing you could try to do is just the last hop, which for you was the Breez LSP, Breez Lightning Service Provider, which is the node that you are connected to. could hold the payment until you come online and then forward the payment to you. That would be a naive approach in trying to solve that Alice and you don't have to be online at the same time.

Aaron van Wirdum And it's naive, I would assume, because in that case, Breez can steal my money?

Jesse de Wit No, it definitely [unclear] steal your money. But the problem is we're locking liquidity in the network right now if we do this. So because Alice is her payment, maybe we can explain a little bit what a Lightning payment is first. So first you allocate, you find a route through the network. So you go, yeah, you find a path over different nodes, over different channels. And then when sending a payment, first you're going to allocate liquidity in each of these channels that's sort of locked. until you get the pre-image back that comes from you whenever you settle the payment. Pre-image comes back to Alice, and only then are the funds released.

Sjors Provoost Yeah, so I guess another way to describe it is there's a secret at the end of the tunnel, essentially. So the payee, the person receiving the payment, has a secret. and the person making the payment has to allocate liquidity, and then every hop does the same thing, and then the last hop gets the secret, and then sends it back to the payer. So there's information that goes from the sender to the recipient, and then this information has to go back from the recipient to the sender. And as long as that information has not made the full return trip, the liquidity is locked up all over the channel.

Jesse de Wit Yeah, so all over the network, the liquidity will be locked. And well, that's something we don't want in the Lightning Network. Usually when a payment is happy, in a happy flow, these payments settle within a second, right? But if you just turn your phone off for a day, then liquidity is suddenly locked for an entire day.

Aaron van Wirdum Why is this a problem?

Jesse de Wit Yeah, it's a problem because of that feature I just described. Yeah, you would expect the liquidity to settle very quickly over the Lightning Network. So if you lock this liquidity for a long time, you're locking it in multiple channels as well. So the amount of your payment is locked over multiple channels. you exponentially degrade the ability of the Lightning Network to be able to forward payments this way.

Sjors Provoost It basically means you need bigger channels, right? Because if you're only using channels one second at a time, then maybe a one Bitcoin channel is enough. But if that one Bitcoin is just locked up for two weeks, then you need a much bigger channel.

Aaron van Wirdum Okay, and just from my understanding, is this the only problem we're trying to solve? Let's say we would all use bigger channels. Would that just sort of also solve the problem in that sense?

Jesse de Wit No, if people start sending more payments, then bigger channels are no longer an option anymore. Or no longer work.

Aaron van Wirdum Okay, and is this... Is this the problem we're trying to solve or are there other problems involved as well?

Jesse de Wit Yeah, so there's two aspects of this. One of them is that we don't want to lock this liquidity in the network while the payment is in flight. And the other one also has to do with the invoice generation. Because Alice and Bob presumably are not online at the same time, they maybe won't exchange an invoice. So Alice needs a way to statically create an invoice.

Sjors Provoost Right, because an example of your book, you created an invoice, but only once you saw the email. So whoever wanted to buy the book had to wait for you to do that. And it'd be better if the person who wants to buy the book does not have to wait for you to make an invoice. But then the problem is that standard Lightning invoices, the BOLT 11 format, you can pay them once. So you can make an invoice and say, well, whoever is the first person to buy my book paid this invoice. But now if you want to scale that and you want to sell multiple books, well, you probably have to make multiple invoices and put them on your website and tell people to pick which one. I don't know.

Aaron van Wirdum Okay, so let's cover that problem first. I need a way to sort of automatically generate invoices even though my phone is switched off, I guess.

Jesse de Wit Yeah, so if you would currently create a BOLT 11 invoice, which is the invoice format we use on the Lightning Network today, If you get that invoice paid, then you release the pre-image, which is your secret, which is the payment secret. And so nobody else will be able to pay that again because an intermediate node would be able to intercept. your payment and settle the payment without the payment ever arriving to you because he already knows the secret.

Aaron van Wirdum Yeah, the secret can only be used once for one payment flow, essentially.

Jesse de Wit Yeah, so the secret can only be used once, which means the invoice can only be used.

Aaron van Wirdum And this is a secret that I'm generating on my Breez wallet app.

Jesse de Wit Yeah, basically a random number.

Aaron van Wirdum Yeah.

Jesse de Wit So first we need to tackle that. And the best way to do that is to create an actually a static invoice, which would be reusable. So you could just post that on your website, say, well, a book costs this and this much money. And senders would be able to pay to this invoice an infinite amount of times. And for that we... We need a different model, and this different model works with PTLCs. So currently, the way we described, you've got a secret, and this secret is hashed into the invoice, and then HTLCs are sent over the Lightning Network. I think you've covered this in Lightning episodes.

Sjors Provoost We have previously tried to explain, but we generally also explained what hashes are.

Aaron van Wirdum We definitely had a basic Lightning explainer episode at one point, and I'm sure we must have covered this, yeah. It was a couple of years ago, so I don't remember exactly, but presumably, yes.

Sjors Provoost But the hash of the secret, that's what you're sending to the other side, and the other side says, please give me the secret that belongs to this hash, and that's really the message you're forwarding along all these channels.

Aaron van Wirdum Right, so that's called an HTLC. So what is a PTLC?

Jesse de Wit Yeah, it's basically sort of the same construct, only instead of having a pre-image and a hash, you have a private key and a public key, which is called a payment point. And that's why it's called a point time lock contract. So it's not a hash time lock contract, but a point time lock contract. And the trick with these public keys is that you can tweak them. And you can basically derive as much keys as you want from a single public key, which you can make an infinite amount of secrets from.

Sjors Provoost Yeah, one of our very first episodes talked about Taproot and why Taproot is so cool. And one of the aspects of it is that it's very easy to add a number to a private key and then add essentially the same number to the public key.

Aaron van Wirdum Well, that's Schnorr, basically, right?

Sjors Provoost Yes, and that's already possible with the CDH, but it's just much, much easier with Schnorr. And this PTLC construct makes use of that. The ability to add some random number to a private key, and the other side can do that to the public key. So even if you don't have the public key, you know how to tweak it. And you cannot do that with hashes. Because if it hashes, if you take the letter A, For example, when you hash it, you get some large number. Then if you say, oh, I'm just going to change A to B, well, the other side has no idea. You cannot just take the hash of A and then take the hash of B and add them together. That's not going to give you the same result.

Jesse de Wit Yeah, so it does work with points, with payment points. And so what a sender can do is it's going to, for each intermediate hop, generate a different secret, basically. So each intermediate hop is going to think that it's a different secret than the one the recipient actually created. So each intermediate hop won't ever learn the actual secret from the payee.

Sjors Provoost But how does that work if you're making two payments through the same route? Because what is it that makes the second payment different from the first payment?

Jesse de Wit So the trick is that Alice, which is the sender, she generates a random number as well, which tweaks the public key. And the intermediate nodes, they use this tweaked public key in order to learn the secret, basically.

Sjors Provoost Yeah, so it's never the same secret.

Jesse de Wit It's never the same secret, and not for any intermediate hop as well.

Sjors Provoost Yeah. So even if two different people make a payment, the sender picks the random number, so the recipient doesn't have to do anything. As long as each sender picks a random number, they cannot reuse the same secret.

Jesse de Wit Yeah, and it's in the best interest of the sender to pick a random number then, because it's his payment that will be stolen otherwise.

Aaron van Wirdum Okay, so in this case, I'm trying to sell the Genesis book to someone, so I got to generate an invoice. who's generating, where does this generation happen? What happens exactly?

Jesse de Wit Yeah, so you create an invoice and it's got a payment point inside of your invoice and you just put that up on your website. I'm a sender, I scan your invoice and I'm going to tweak your payment points with random numbers along the route so nobody learns about the actual secret when the secret comes back to the sender.

Aaron van Wirdum Right. Okay, got it. That part makes sense to me.

Sjors Provoost So that removes the interactivity from you having to make an invoice. But in this scenario, you're still online because you are clearly receiving the payment and sending back the secret every time somebody makes a payment.

Aaron van Wirdum Yeah, so that was the second part of the problem I think we're trying to solve, right? Now my phone is, you know, I emailed this guy back or whatever. My phone is switched off and now I still need to receive. the payment without locking these funds along all these channels because that screws up.

Sjors Provoost So your friend has downloaded the invoice from your website instead of having to send you an email. But in this, so far, we've still reached the point where, okay, they don't have to email you anymore. They just make the payment, but your wallet still needs to be online to receive the payment.

Aaron van Wirdum Yes. Okay, so how do we solve this problem, Jesse?

Jesse de Wit Okay, let's go over how async payments works then. So Alice is going to pay Bob and Alice is going to be connected to the Lightning Network through a Lightning service provider. And Bob is going to be connected to the Lightning network through a Lightning service provider. Where a Lightning service provider is basically just a node that you're connected to the Lightning network. And this node is well connected to the Lightning network.

Aaron van Wirdum Yeah, so the concrete example here would be, for example, Breez I think, right? Like my wallet is not a full node. It just connects to Breez's full node.

Jesse de Wit Yeah. And Breez's full node is tolerant of you being offline a lot, which is why we call this a Lightning service provider. But it could basically be any node that's tolerant to that. And what Alice is going to do, it's going to send the payment to Bob, but it's going to tell her LSP, please hold this payment. until you receive a message that you can release it.

Aaron van Wirdum She's telling her own LSP that.

Jesse de Wit She's telling her own LSP that. And the reason she does that...

Aaron van Wirdum Otherwise, it's a regular Lightning payment with a PTLC then. It's normal. She just says to her own service provider, don't send this yet.

Jesse de Wit Yeah, exactly. And this message is inside the payment itself. So basically, it's a regular Lightning payment.

Sjors Provoost And so at this point, Alice's LSP cannot steal the money, right? It's not that she's making a payment to her LSP. She is doing the first step of the payment, which is giving the pre-image. No, not the pre-image, giving the point. basically the public thing of the secret to her payment provider who cannot take the money unless they get the secret. And in order to get the secret, they have to forward it. But all Alice is doing is saying, oh, wait a minute, don't forward it just yet because Bob might not be online.

Jesse de Wit Exactly. So we know the reason why she— why the LSP is not forwarding it. And what Alice is going to do as well... She's going to send an onion message to Bob saying, hey, there's a pending payment here. If you want to release that whenever you're online, send a message back along this path over here. And there's an encrypted path inside this message as well.

Aaron van Wirdum When you say onion message, what do you mean by that?

Jesse de Wit An onion message is, so over the Lightning Network, we route payments over onions as well, basically meaning that every hop, where this message is routed over, is encrypted. So it sort of becomes an onion of encryption, where onions have layers.

Sjors Provoost So every point in a route can only see which point is coming next or which node is coming next and which node came before it, but cannot see further. In either direction. Which we explained a bit in our episode about BOLT 12.

Jesse de Wit Yeah, and you can basically send arbitrary messages over this construction, over the Lightning Network then. Right. And she's going to send this to Bob and with a reply path then to her LSP. So Bob will be able to unlock the payment so it actually becomes forwarded. But Bob is offline, of course. So the LSP of Bob will hold this Onion message until Bob is online. Right? Because the LSP knows, well, I have to forward this to Bob. Bob is not there. So I'm just going to wait until Bob is online.

Aaron van Wirdum Right.

Sjors Provoost And the LSP cannot read what is in the message. Just knows, like, I have a message for Bob. I don't know where it came from, but I'll give it to Bob when Bob is online.

Aaron van Wirdum Yeah, and in this case, it's obviously not a problem because no funds are being locked up. It's just a message.

Jesse de Wit Yeah.

Sjors Provoost Yeah.

Aaron van Wirdum Okay, so that's the onion message. Goes first to Bob's service provider, and he will forward that to Bob. Bob's gone online. Bob comes online, turns his phone on. or Breez app or whatever Lightning app he has sees this message, or probably his wallet just responds to the message, I would assume.

Jesse de Wit Yeah, yeah, yeah.

Aaron van Wirdum He doesn't have to actually see it.

Jesse de Wit Yeah, this all goes automatic, but we will say that his wallet sees the message and then is going to reply over that reply path. So he doesn't really know where the message is coming from. He just knows that he has to send an onion message there in order to unlock it. And then, so Alice's LSP, who's still holding that payment right now, By the way, Alice, after she sent the onion message to Bob, was able to go offline. She could put her phone back in your pocket. It's an important part that they don't have to be online at the same time.

Aaron van Wirdum Yeah, because Alice's LSP now has the money in a way.

Jesse de Wit Yeah, has the money in a way. And now, so we're now at the point where Alice's LSP received the onion message from Bob saying, please forward this payment. Then the LSP forwards the payment to Bob, and Bob is online now. So he's able to settle the payment. So he's going to release the pre-image. The pre-image goes back all the way to Alice's LSP. And Alice's LSP, whenever Alice comes online, is able to settle the last piece between her and Alice. Because only her channel with Alice is now still in a state where funds are... In Limbo.

Aaron van Wirdum Right.

Sjors Provoost Yeah, so I guess the only player in this story that needs to hold funds in Limbo in a channel longer than you'd normally want to do is the channel between Alice and her Lightning service provider. So obviously the Lightning service provider will want to be compensated for that in a way. But if Alice is a mobile node, then that money is probably going to be stuck, kind of stuck anyway, because if she's not online, they can't route through it and she probably doesn't have any other channels. It's not a routing node anyway.

Jesse de Wit And LSP will already allocate liquidity towards these users. So I don't think there will be any specific compensation for this, just probably for the fact of being a Lightning service provider and allocating liquidity. Maybe you'll pay something for that.

Aaron van Wirdum We promised, or I promised, that we would also cover trampoline payments. Where does this come in?

Sjors Provoost In some situations, it would just work this way, right?

Jesse de Wit In some situations, it would just work. But there is actually a problem, because if Alice finds a route for this payment over the Lightning network to Bob, Usually in Lightning, what happens is you find a route, you try the route, and then somewhere along the route, Either a node is offline or doesn't have enough liquidity. And this route fails. And what your node is going to do is going to find another route.

Sjors Provoost And this is also, by the way, where I'd like to shill the episode with Rene Pickhardt we did a few years ago. Explaining sort of his pathfinding optimal way of making payments. But it also involves lots of attempts. Yeah, quite a few attempts to get a payment through. It's by design, there's some privacy in the Lightning Protocol, so you don't know exactly how much room there is in all the channels along the route. You know how big the channel is, but you don't know where the money is in that channel, so you don't know how much you can actually send through it. And this changes every time as well.

Aaron van Wirdum That was a short special, I believe, right?

Sjors Provoost Yes.

Aaron van Wirdum But you don't know the episode, I'm sure?

Sjors Provoost No.

Aaron van Wirdum Okay.

Jesse de Wit Okay. Yeah, so Alice, if she created this first route and this route fails, that would mean that she would only retry whenever she comes back online again. You don't know when that is. So what Alice can do is she can delegate the pathfinding to another node. And this is a feature in the Lightning Network that's being implemented in several node implementations. ACINQ already uses it, and it's called Trampoline Payments. So basically, Alice is going to ask her LSP, please, I want to forward this payment to this direction. Please, do you find the best path over the Lightning Network? And I'm just going to chill and go offline now.

Sjors Provoost Yeah, and so this works by providing a carte blanche in terms of fees, right? Because normally when you establish the route, you know exactly how much fees you need to pay at every hop. But because you're not establishing the route, you're just going to say, well, here's 100 sats. You figure it out. And if you find a cheaper route, you keep the change.

Jesse de Wit Exactly, yeah. So you give them some kind of margin. And it could be a competition for trampoline nodes as well to say, well, I'm the cheapest because I know how to find the best routes in the network.

Sjors Provoost Exactly, like the London taxi drivers that have the knowledge and they can find the shortest route through London without a GPS and they usually are actually faster than the Uber drivers that just follow Google Maps, according to legend.

Jesse de Wit So Alice's LSP is now able to retry this payment whenever it fails, and so would be able to reach Bob, hopefully in a timely manner, before Bob goes offline again.

Sjors Provoost And so this ingredient is useful, like we said, because the Lightning network changes all the time, you need to do multiple attempts, and so this trampoline router can just try it multiple times, basically. The downside, of course, is privacy. Because the trampoline now knows where the payment is going.

Jesse de Wit Yes. So the first part of this is Bob in his invoice could have created a blinded path. So that's one part of this where the intermediate node would not actually find the destination, right? The trampoline node would not find the destination. And another way to deal with this is to select multiple trampoline hops. in your route so we're now using one trampoline node So Alice's LSP is going to find different routes, but you could tell Alice's LSP, so first find a route to this random trampoline node, then find a route, then that trampoline node has to find a route to that random trampoline node. So you could, if you value your privacy, you could diffuse the pathfinding a little bit that way.

Aaron van Wirdum Okay, I guess one maybe concern that sort of comes to my mind. but I'll let you address that, is it sort of sounds like this would make Lightning users very dependent on service providers. Sjors mentioned that they're also more general risk, and I'm asking if it works for a Lightning service provider, but is this a reasonable concern in your view, or in Sjors's view maybe? But let's hear from Jesse first.

Sjors Provoost Yeah, from my point of view, it depends on how...

Aaron van Wirdum Sjors. I said, let's hear from Jesse first.

Sjors Provoost Okay.

Jesse de Wit Well, okay. So there's a user that apparently… online Lightning node, right? So he wants to run a Lightning node in his pocket. So that means there's no other way in network through nodes that are willing to accept that.

Sjors Provoost And as a reminder, why [unclear]? If you have a channel, But you're offline all the time. Now, if you channel and all the money in the channel is on your own side then the other side is not going to care but if you have made like lots and lots of payments to the channel, now the money is on the other side. The other side is going to be annoyed by this because when you're offline, they cannot access that money at all. They can't it— but they have to force close it which is expensive. They can't route anything through it because you're offline. You're not a routing node so that money is just they own it, but they're forced HODLing it essentially. And so not everybody's going to be willing to just allow you to open a channel and behave like that. I think right now many nodes don't care, but they might close the channel on you saying, hey, this is not making me enough money. So a Lightning service provider in the very broad sense is anyone who's willing to just put up with a peer that's not online all the time, probably by charging.

Aaron van Wirdum Yeah. How far is this?

Jesse de Wit So there's a lot of prerequisites. So first of all, we need Taproot channels in order to... Taproot channels are an LND-implemented simple Taproot channels protocol, which sort of works with private channels right now, but not with public channels. It's basically the, so Lightning channels are basically just commitment transactions on chain, right? But you update them locally and you broadcast, don't broadcast many of these that you sign in between in your channel. And these transactions are tap transactions. So that's basically what a Taproot channel is.

Aaron van Wirdum Okay. So it's pretty much what it sounds like.

Sjors Provoost And that's just the main transaction, but then there's the HTLCs, the things that fly over the channel when you're making a payment, to make those PTLC. Another change, right? You can have Taproot channels that still use locks for the payments.

Jesse de Wit Yeah, and also if you use Taproot channels, you need to gossip your channel, so you need to tell the rest of the network, like, these are the channels that I have. This also does not exist yet. So there are some prerequisites there on the side. And then there is a proposal now for holding the payment, which is one part of async payments, where the LSP holds the payment until a message is sent when it's released.

Sjors Provoost And this standard is within the protocol itself. So it's not like some custom API of the Lightning service provider. It's really just part of the Lightning protocol. Anybody who speaks to Lightning Protocol could hold a payment.

Jesse de Wit Yeah, so it would be the question where this ends up exactly. BOLTs, which is a Lightning improvement proposal, but bLIPs, can also be implemented by any node, basically. So there's that part, which are currently only supported by CLN in order to be able...

Sjors Provoost Because onion messages [unclear] BOLT 12, right? We just made— we did a whole episode about BOLT 12, but we explained how onion messages are kind of useful in that scheme, but BOLT 12 is mostly being pushed by Core Lightning and I guess LDK now, and so you have to wait for— I guess you just need two implementations, but in order for it to be useful it's nice if LND supports it because like a whole bunch of nodes are running LND, in— the onion message needs to go from A to B through all these hops. I think onion messages can follow any route you like, right? They don't have to follow any channels that exist. They can just go through any way through the network.

Jesse de Wit Yeah, I guess they sort of could, but you only know that people are connected through their channels usually.

Sjors Provoost Right, yeah, yeah, yeah. So it has to follow some bunch of channels, and if all these nodes are running LND in the middle, then you just don't have a way to get your message to the other side.

Jesse de Wit Yeah. So I think we probably talked about most of the prerequisitions.

Sjors Provoost Trampoline?

Jesse de Wit Yeah, so trampoline. Yeah, exactly.

Sjors Provoost That's done by the ACINQ people. That's used by Phoenix. Yeah, by the ACINQ people.

Jesse de Wit And there's so LDK also implemented parts of it. I don't think they completed trampoline payments completely. Please correct me if I'm wrong there. So that's also not part of the BOLT spec yet. It's not merged into the spec yet.

Aaron van Wirdum Okay, so basically there's still a bunch of building blocks that need to be in place before this can work. And different implementations are in different stages of completing these building blocks.

Jesse de Wit Yeah, so it's basically almost every improvement to the Lightning Network that we want to have is sort of a prerequisite for async payments.

Sjors Provoost Sounds easy. Two weeks.

Jesse de Wit Yeah. No, it's not going to be two weeks, but more like several, several years.

Aaron van Wirdum Is anyone against this?

Jesse de Wit Is John [unclear] against async payments?

Aaron van Wirdum He's against everything, so I'm assuming. Are there people against this? Is this like in any way controversial or are there concerns about this? Or maybe there are people that have, you know, developers that have different preferences or is there?

Jesse de Wit The people may be against some parts of the upgrades. I'm not exactly sure about their reasoning, but one reason I can come up with is that Onion messages, they can also be a DoS factor.

Aaron van Wirdum I thought Laolu basically came up with that. Am I misremembering that?

Jesse de Wit I don't know about this exactly.

Aaron van Wirdum Okay, well, never mind. Okay, so they might be against onion messages, or are they against onion messages? Yeah, you think so.

Jesse de Wit Well, they're not implementing it. They do have LNDK, which is sort of like an extension to LND, which does support onion messages.

Sjors Provoost I mean, sometimes, most of the time when somebody doesn't implement something, it's just because they don't have time for it, because they're working on 6,000 other things that have that priority. It's not that they're opposed to it.

Aaron van Wirdum Right. Okay, so as far as you know, there's not necessarily any opposition to asynchronous payments.

Jesse de Wit No, I don't believe so. No, I think this is just a great...

Sjors Provoost Yeah, and it's also a bit of a harm [unclear] thing because people like this ability to pay to a mobile client, and so there are already solutions out there that will just lock up all the liquidity.

Jesse de Wit Yeah, and that's evil.

Sjors Provoost Lots of problems, so it's one of those things where it might be better to implement it because the alternative is worse.

Aaron van Wirdum Right. Okay. Does that cover it?

Sjors Provoost I think so. You got it.

Aaron van Wirdum Anything you want to [unclear]?

Sjors Provoost Where should people find you?

Aaron van Wirdum Yeah, that's a good one.

Sjors Provoost Should people find you?

Jesse de Wit People can find me on Twitter at @WitDeJesse.

Sjors Provoost In that case,

Aaron van Wirdum [unclear],

Sjors Provoost indeed, thank you for listening to Bitcoin,

Aaron van Wirdum Explained.