Lightning Network Routing - NADO 41

Aaron van Wirdum Live from Utrecht, this is the Van Wirdum Sjorsnado.

Sjors Provoost Hello.

Aaron van Wirdum Hey Sjors.

Sjors Provoost I think we've got somebody else here.

Aaron van Wirdum We've got Joost Jager. Is that how Americans pronounce your name, Joost?

Joost Jager That's indeed how Americans pronounce my name. But the Dutch people say Joost Jager.

Aaron van Wirdum Joost Jager is in the building. Joost, please introduce yourself for our audience.

Joost Jager Yeah, I describe myself as a Lightning developer. I've been working at Lightning Labs for a year or two and recently switched to Bottlepay. And I've got also my own projects on the side, mostly contributing to the LND repository.

Aaron van Wirdum Right. And I think one of the topics that you've sort of... specialized yourself in or become an expert in is Lightning routing is that correct?

Joost Jager Yeah that's correct I did a lot of work on that in the past.

Aaron van Wirdum Yeah, yeah, so Sjors, we did an episode on Lightning in the past.

Sjors Provoost We've done two episodes on Lightning in the past.

Aaron van Wirdum We've done some stuff on Lightning in the past and it's all been very… Superficial? Is that a way to describe it?

Sjors Provoost I think so. So we explained Lightning at a high level, so we can listen to that episode. And then there was another episode where we talked about RBF replaced by fee and how it relates to some problems on Lightning. And that was very detailed, but also very bad.

Aaron van Wirdum Suffice to say, we're not the biggest Lightning experts in the world. So when it gets to sort of more in detail Lightning stuff, it gets pretty complicated for us, at least pretty fast. So I'm very happy to have a real Lightning expert here today Joost welcome,

Joost Jager Thanks for having me.

Aaron van Wirdum And we're hopefully going to so we're going we're going to get into Lightning routing more in more detail and explain what it is what the challenges are what you know what the direction of development is there and really get into it for this episode. All right Sjors, are you ready?

Sjors Provoost I think I am.

Aaron van Wirdum All right, Joost, first of all, let's start with a very basic question, just for maybe our new listeners, or just a very brief premise of what is Lightning and what is routing, what are we going to be talking about here, in a very general sense.

Joost Jager The question, what is Lightning? All right.

Aaron van Wirdum Yeah, just in a few sentences.

Joost Jager Okay, I'd say it like this. Bitcoin is awesome, but it has several downsides. And Lightning is a technology built on top of Bitcoin to solve those. And then we're talking mainly about the fees that you pay to execute a transaction and the speed at which a transaction executes.

Aaron van Wirdum Yeah, it's a payment layer on top of Bitcoin that allows for instant transactions that are also cheaper because not all of the transactions end up in the blockchain. So then the next question would be, what is routing? What are we going to talk about? Why is this a problem or a challenge or what is Lightning routing?

Joost Jager Yeah, so with regular Bitcoin, you can pay to anyone who gives you an address without restrictions. It's a pretty direct process, whereas with Lightning your payment needs to travel through channels and there's only a limited number of channels so it isn't feasible for everyone to have a channel with all the other people on on the globe.

Sjors Provoost And so maybe we can explain channels a little bit. So I could have a channel to Aaron which basically allows me to send coins to Aaron and Aaron could have a channel with you and then he could send coins to you But I can also send coins to you directly through Aaron. [unclear]

Aaron van Wirdum So indirectly, yeah.

Sjors Provoost Yeah, indirectly, exactly. By basically sending it to Aaron first, and then he forwards it to you in a bunch of ways that that's made safe.

Joost Jager Yeah, well, that's indeed why you need routing, because there's a limited number of those channels. You need to find a path from yourself to the payment destination. Yeah.

Aaron van Wirdum Yeah, the general concept is similar to the six degrees of separation idea. where you know everyone in the world through a couple of people only in the end, even though there's billions of people in the world. The theory is that within just a few people who know each other, you actually sort of know everyone. So that's the concept that's being used here. The challenge is... which channels in this case, which channels are you going to use to reach your endpoint? And somehow you need to figure it out. You need to figure out the routes to actually reach the person you want to pay, right?

Joost Jager Indeed, it's like a roadmap. So you know where you want to go. There's only a limited number of roads that you can take. And you'd like to find the best possible route to your destination based on... similar to if a car either you want the fastest route or the shortest route I like different options and this is also at play in Lightning

Sjors Provoost And this is why it's different from the rest of the internet because on the internet you just say I want to go to this Google website and all your computer has to do is send it to your router and then your router sends it to your internet provider and your internet provider sends it onwards just like the postal mail like you send it onwards and every hop knows where it where to go next, they figured it out. But with Lightning, you have to decide in advance exactly where it's going and which route it's going to take.

Joost Jager Yeah, that's right. In Lightning, the sender decides what route is going to be taken exactly. And the reason for this is that Lightning has privacy properties that allow intermediate nodes or that allow the sender to keep himself hidden from intermediate nodes. So the intermediate hops, they don't see where... the way the payment is going. Sorry, I'm explaining this.

Aaron van Wirdum Or where it came from.

Joost Jager Yeah, well, also not where it came from, but they also don't know where it's going. And if every of those hops would find out the best path for themselves towards the destination, it wouldn't be hidden what the destination is.

Sjors Provoost And to make an analogy to the real postal mail, like I could send Aaron a letter and inside the envelope is another envelope that has Joost’s address on it. And if you do that multiple steps, then, you know, when Aaron opens it, he only knows it's going to Joost and he might know it comes from me. but not where it's going ultimately. This is how the Onion Network works too.

Aaron van Wirdum Yeah, nor did I know that you were the first step. Like that could have been five steps before.

Sjors Provoost Yeah, there could have been many, many envelopes outside of my envelope.

Aaron van Wirdum Right, yeah. And like I said, this is also how Tor works.

Sjors Provoost And you also have to pay all the postage in advance.

Joost Jager Yeah, that's a great analogy. And also the size of the envelope is always the same in Lightning, so you can't even see how many smaller envelopes are in… still inside

Sjors Provoost So that's where it breaks down because with real envelopes you could put them on a scale.

Joost Jager Yeah that's where it breaks down indeed.

Sjors Provoost Yeah well actually yeah no yeah no there's no way to fix that.

Aaron van Wirdum Let's not get lost in the analogy.

Sjors Provoost I was thinking about how to how to put fake envelopes inside of it but you can't really without opening it.

Aaron van Wirdum You want to get into it Sjors you want to get into the envelope game or?

Sjors Provoost Well if you did the envelope game then the way you would keep the weight the same is I guess by replacing… opening it and putting a new envelope in the innermost envelope without reading it.

Aaron van Wirdum Could you put pockets of helium in it to sort of counteract the weight balance?

Sjors Provoost And then release the helium every time you ship it? I don't know.

Joost Jager But that's indeed what's happening in Lightning. Like extra bytes are padded at the end of the packet to keep it of the same size all the time.

Sjors Provoost Right, so you have no idea where you are in the route.

Joost Jager Yeah, you don't know what hop you are.

Aaron van Wirdum Okay, so that's why the sender needs to figure out the whole route. That's why we're getting into the whole envelope thing, just to point out that the sender needs to figure out the whole route. So in order for the sender to do that... The sender needs the map of the network, right?

Joost Jager Yes.

Aaron van Wirdum Does the sender need the entire map?

Joost Jager It doesn't need the entire map. It needs enough routes to find its destination. But in practice, you will receive the entire map.

Aaron van Wirdum Right now, nodes use the entire map to figure out…

Joost Jager At least the visible part of it. Because there is also private channels, like say private roads. They are not on the map, but you need to get that information from a different source if you want to use those.

Aaron van Wirdum Yeah, and private channels can't be used for routing anyways. That's why they're private, I guess.

Joost Jager You can route over private channels, but you still need to know where they are.

Aaron van Wirdum Okay.

Joost Jager So you can have a routing node that has only private channels and is routing for users that know those.

Sjors Provoost So I guess the postal analogy here would be to say, dear postman, like when you ask your friend, like, what's your address? You say, well, this is where I live, but I'm... But the postal service doesn't really know my street name. They only know the city I'm in. So here's what you need to tell the postman, like how to get from the city to my street or something like that. It's like a hidden instruction for the last [unclear]. Or maybe the analogy is like use the mailbox on the left, not the mailbox on the right or something like that. Maybe we should not do the analogy. In the Lightning Network, basically...

Aaron van Wirdum You need to be on the road outside of Hill Valley in 1955. Exactly. This is a Back to the Future analogy.

Sjors Provoost Exactly. So in the actual Lightning Network, it's simpler, right? It's just that some of the channels are not known. So if you're receiving, say, on a mobile wallet, then what you do is when you make an invoice, you say, this is my node. And by the way... I am connected to this publicly visible node through this channel. So you have to use that at the end of your route, but the rest of the route is up to you.

Aaron van Wirdum We're getting sidetracked. Let's just assume for convenience sake, I'm going to assume for convenience sake that we're using public channels. So in that case, your node needs to know the entire map of the network of all the public channels. So how does your node, I'm running in the Lightning node, how does my node get all of this public channels? How does my node know where all of the public channels are?

Joost Jager Yeah, so your node is connected to a few other nodes. And those few other nodes are also connected to a few other nodes. And through that, a whole network is created. And on that network, gossip is being passed around. So if there's one node who knows about the public channel, they gossiped this to their neighbors. And those neighbors, they...

Aaron van Wirdum Gossip, just to be clear, is just sending messages. It's just sharing data.

Joost Jager Yeah, just sending messages indeed. Yeah. So it slowly propagates throughout the network because they're all passing on the new information that they received from their peers.

Aaron van Wirdum So every node basically shares with all of the nodes it connects to which channels it has, And then the next node does that as well. The information it got from the first node, and that's how all of the nodes end up with knowledge of all of the channels and allows all nodes to construct a map of the entire network. Is this correct?

Joost Jager Yeah, they share the information that they have with their peers indeed. And in the end, everybody has the same copy, roughly the same copy of the network.

Aaron van Wirdum So what is the information that's being shared exactly? What information about these channels is being... Is it just the information that the channels exist? Or is there more that's being shared?

Joost Jager Yeah, so most important are the endpoints of the channel. So between which nodes the channel lives. Another important one is the size of the channel. So you can use this to decide whether this channel is big enough to carry the payment that you want to send. So if you have a large payment, you can skip all the small channels. You don't need to evaluate those because they won't be able to carry it anyway. There's also a pointer to the... the the output on chain so you can verify on the chain that this channel actually exists

Aaron van Wirdum and and the size of it as well I guess

Joost Jager yeah you can also observe the size from there. yeah yeah um so this is very important to prevent spam on the network.

Aaron van Wirdum Yeah the size in this context of course mean number of satoshi or number of coins in the channel.

Joost Jager yeah the capacity of the channel. yeah so the maximum size that it can relay um so that's there. And there's also the forwarding policy for that channel. So if nodes advertise a channel that can be used for routing other payments, those nodes, they charge a fee for that. And the fee is also advertised in this peer-to-peer network.

Aaron van Wirdum Right. So if my node is mapping the entire network, it knows… where all which channels exist or at least which public channels exist it knows how many satoshis or how many coins are in each channels it knows how much it's going to cost me to route through that channel But it does not, for example, know for each channel where the balance is because the balance can be on either side of the channel, right?

Joost Jager Yeah.

Aaron van Wirdum So that's not communicated. That's not part of the map that my node has. Is that correct?

Joost Jager That's right. Yes.

Aaron van Wirdum So that sounds like that could be a challenge when we actually start routing because it actually does matter. how the balances are divided over the different channels, right?

Joost Jager That's right. If you start routing and you've picked your route, you've picked your channels, it could turn out that one of those channels doesn't have the balance on the right side and then your payment fails.

Aaron van Wirdum Right. So how does my node calculate the best route? How does my node deal with something like that?

Joost Jager Yeah. So you can look at this in different ways. But one way a node can implement this is that it assumes channels to be in balance always. So let's say if there's a channel that has one BTC. we will accept that it might be a little bit unbalanced, but not too much. So for example, you could say a one BTC channel should at least be able to carry a payment of 0.2 BTC, for example, because it's not reasonable to expect from a one BTC channel that it's always able to carry one BTC. So if you assume that good routing nodes keep their channels balanced and that they let payments through those channels and it doesn't happen, then you can take note of that as a node and avoid this channel the next time.

Aaron van Wirdum Right. Taking one small step back, so we're now getting into sort of pathfinding. I guess that's the technically correct term, right?

Joost Jager Yes.

Aaron van Wirdum And pathfinding, we already mentioned that this is something that a node itself figures out. The paying node essentially figures this out. This isn't like a... protocol thing right this is something that individual nodes can do however they please essentially and and is there a difference between different Lightning implementations how they do this or is this more or less synchronized as far as you know?

Joost Jager Oh so the part that is synchronized is that uh it is optimized for cost. So there's cheap channels, there's expensive channels, and all of these implementations, they primarily look for the cheapest path to the destination.

Aaron van Wirdum Right.

Joost Jager But then between the node implementation, there's variation in other factors that play into this as well.

Aaron van Wirdum Right.

Joost Jager Yeah, so one of those factors.

Aaron van Wirdum Yeah, let's get into these factors. That's an interesting point. Okay, so we want to make a payment. We've mapped out the entire network. We know which channels exist. We know what kind of fees they will charge if they forward the payment. Now, there are obviously, or I mean, I guess in most cases, there are going to be multiple potential paths yeah definitely in the same way that if you're you know you're traveling from one city to another there are probably multiple roads you could potentially take how do you decide on the actual route that you're going to take? How does a Lightning node decide this?

Joost Jager Yes. So besides the cost factor, there is the time lock factor. So in Lightning, it's quite technical, but if you send a payment in Lightning, there is a maximum time that this payment can take to complete. And this is a pretty long time. It could be like five days or even two weeks in some cases. So this is a parameter normally…

Aaron van Wirdum So it takes long because every hub on the network can potentially wait for a little while before forwarding. Is that the reason?

Joost Jager So in the happy flow, it's near instant. But in the worst case, a node can sit on that payment and not do anything. And then you have to wait until that ultimate time lock that you attach to a payment.

Aaron van Wirdum Until that expires, until you can sort of take the money back, right?

Joost Jager Yeah, so you can take the money back. And usually you don't see or hear anything of this, but only in a rare case that a node indeed does this, you see your money locked up for a long time. And if you've got two routes with identical costs, while one node only requires you to lock up the money for a maximum of one day and the other seven days, we prefer the one-day option.

Aaron van Wirdum Right, because in the worst case scenario, you'll get your money back faster.

Joost Jager Yes.

Aaron van Wirdum So you're making a calculation based on fees, based on time. And was there another factor?

Joost Jager Yeah, there's another factor, which is reliability. And this ties into the thing that we just talked about, where we keep track of the performance of nodes. And if certain channels don't perform well, we try to avoid them.

Sjors Provoost And by not performing well, you mean they previously? Either didn't have enough capacity, so they immediately said, hey, I'm sorry, I can't actually do this for you now. Or they timed out?

Joost Jager Yeah, so there are multiple things that can go wrong. Like one of the most common things is that the balance is not sufficient in the channel, but it could also, for example, be that a node is offline. That can also happen. So there is balance, but the node is offline, so it still can't carry your payment. And there's also a variety of more rare exceptions that we also use to update those reputation scores of nodes.

Sjors Provoost Right. And one of the problems with that reputation, as we talked about this before, so that's why I sound really smart, is that you don't know, you don't necessarily know which node on the route screwed up, right?

Aaron van Wirdum Yeah, if a payment fails, you know that the payment fails. But in some cases, or maybe even in all cases, you don't know where it failed exactly. Is that right?

Joost Jager You do know where it fails. Like a node sends you back an error message to the sender, and it contains its identity, a signature. So the node, it signs the error. So as a sender, you know where the error occurred, but it's still not completely clear whether this node is actually also at fault. So it's actually responsible for the error. So it could happen that node A sends a bad payment request to node B, and then node B replies with an error message. But it's not fair to penalize node B in that case, because it's node A that actually sent the wrong request. So it's a little bit more complicated than...

Aaron van Wirdum So if you're neither A nor B, you're the one that made the payment, then you're not sure if it was A or B?

Joost Jager Yeah, you're not sure whether it's A or B. So what the sender does in this case is they penalize the pair of nodes. So they apply a penalty to the link between A and B.

Aaron van Wirdum Right.

Sjors Provoost So this can create guilt by association if you're an unlucky node next to a bad node.

Joost Jager Yeah, definitely. So you have to be very careful about which nodes you peer to because they are also influencing your own reputation.

Aaron van Wirdum Okay, so I think you've now mentioned, so yeah, you're basically attaching a score to nodes. Am I saying this right? So you've got a map of the network. You know all of the channels. You know how much funds each channel has. You know how much fees they charge. And now you're also applying a score to all nodes on the network based on their performance. based on your request to route through them. Is this right?

Joost Jager Yeah, well, not to nodes, but to node pairs. So we attach the score to [unclear] node pairs.

Aaron van Wirdum They're always two pairs. So it doesn't get calculated into individual nodes in the end.

Joost Jager Yeah, you're right, it does get… it does get… so, like, at the basic level, we assign penalties to pairs of nodes. But some nodes have a lot of peers. And to prevent us from trying out all the combinations of that node with all its peers, we also extrapolate the performance of a specific pair to the performance of the node.

Aaron van Wirdum Right, yeah. So nodes have a specific score, essentially.

Joost Jager Yes, they have a score.

Sjors Provoost So I think there was another heuristic you talked about when we prepared this, which is, I guess, never change a winning team would be a way to describe it. As in, if you're looking for a route to pay and you found one that's been used before and it worked really well, then you prefer that one rather than try something new.

Joost Jager Yeah, now you're getting to the point… How is this reliability factored into the pathfinding? So what's the weight of a reliable or unreliable node? And the way this works, at least in LND, is that previously successful routes, they are very much preferred until proven otherwise. So if a route is successful, it will keep that label until it's proven otherwise, whereas a failure slowly decays because if you would hold on to a failure forever, we would never give that node another chance. So there's two different ways of dealing with a success versus a failure.

Sjors Provoost All right.

Aaron van Wirdum So if I'm understanding correctly, I think the way it essentially works is that your node... has a map of network figures out what the cheapest route is and by cheap cheapest actually factors in these other things so it factors in the fees itself so that's sort of the most plain way of calculating the cost but then it factors in the time locks which you mentioned and the reliability as sort of cost factors and then based on all these three things fees time and reliability, it figures out what sort of the real cheapest route is. Is that right?

Joost Jager Yeah, I would call that the best route. So best is a little bit unqualified, but it means a combination of those things that you mentioned, yes.

Aaron van Wirdum Right. And just to reiterate this, nodes on the network, so my node makes this calculation, but Sjors’ node could make a different calculation based on the past routing that Sjors has done and based on the past routing that I have done, right? It's an individual calculation for all nodes on the network.

Joost Jager It is an individual calculation, and it's based indeed on the experiences that a node has, but also on how you configure the node. So there's also room for the user to decide what they think is important, whether they value cost over reliability or the other way around. So I've talked about an analogy with restaurants, for example. So if you have been to a good restaurant, the question is, will you go to that every time again the rest of your life? Or do you sometimes try a new restaurant? And between people, there's a difference in how they find this balance. So some people want to try something new all the time and have disappointments, and others, they never try something new. And this is a parameter that you can also set on your Lightning Node.

Aaron van Wirdum Right. Interesting. So I I've written about Lightning uh type of stuff in the past including routing at some point and I but I think it's been like probably two years since I wrote about this back then the idea was because there was a lot of um criticism I guess or a little concern or maybe concern trolling whatever you want to call it about how these solutions don't really scale because you know it does mean that every node needs to keep track of the entire network. And at that point, the sort of answer to that concern was, for now it works. For now this is scalable enough. For now all nodes can keep track of this. And we'll now just keep track of how the network develops because there's a lot of questions about that. Are we going to see a network with a few power players that do most of the routing? Or are we going to see a very decentralized network? But for now, we're just going to see how it develops. And then we'll make our next decisions based on that. Is that still sort of the status? Or are there other... Are there by now other ideas of how to evolve this over time, how to develop this over time?

Joost Jager Yeah, so as far as I know, that's still more or less the status. They're just on the part of the mobile nodes. There has been some developments in those areas. Like a copy of the network is not that big for like a modern time computer; it's very easy to keep track of what’s… what’s… what’s… there now.

Aaron van Wirdum For now, it's very doable.

Joost Jager Yeah, only for mobile nodes it's different. So you see that these mobile wallets, they look for different solutions. So either they outsource the route finding completely to a server or partially. And in the case of partial outsourcing, they use trampoline nodes. So these are nodes on the network that have a copy of... all the channels that exist, and you can delegate part of your pathfinding to that node.

Aaron van Wirdum So how this works, I think, but do correct me if I'm wrong, is that your mobile wallet, in this case, would find a route to a special node, a trampoline node, which is, I guess, relatively close or something like that. I'm speculating here.

Sjors Provoost It doesn't matter where it is. It's just that you might, as a note, decide to only know the trampoline nodes. So as a mobile client, instead of downloading...

Aaron van Wirdum you just know much fewer nodes, right?

Sjors Provoost Yeah. So when you listen to the gossip, you might tell your peers, like, only send me gossip about trampoline nodes.

Aaron van Wirdum Right.

Sjors Provoost And then that's a much smaller network. And then what you do is when you're creating a route, you create a route to a trampoline node. And then you tell the trampoline node, essentially, that's sort of the inner envelope, like, go to this final destination.

Aaron van Wirdum The trampoline node figures it out from there.

Sjors Provoost Yeah, so you're compromising a bit on your privacy and on your ability to find the cheapest route. But the upshot is that you don't have to know the map of the entire network. And there's some intermediate solutions where you might use multiple trampoline routes, nodes in your routes, so the trampoline nodes also don't know everything about you. And there's other things you can do to improve your privacy even a little bit more despite these trampoline nodes doing some of the work for you.

Aaron van Wirdum Right.

Sjors Provoost So there's interesting trade-offs there. I don't think that's been totally figured out because I guess mobile clients, you just have to use them in the field and see how well they work.

Aaron van Wirdum Yeah. Another challenge I think is or was that a lot of channels probably... Just because of network topology or something, a lot of channels are probably mostly used in one direction. So sooner or later, they always end up... depleted on one end and all of the funds on the other end at which point they're no good for routing or at least you know not not anymore in that direction is there any sort of solution is that a problem first of all and if so is there a solution for [unclear] to sort of get a better balance or rebalance or rebalancing strategies or… in that context.

Joost Jager Yeah, so the way I see this is that, as I mentioned earlier, a node should keep their channels available, like they should be available for routing. So if this happens, if a channel ends up depleted on one side, the fix should be to open a new channel so that apparently there is traffic in that direction. There's money to be made in routing fees. That pair of nodes should coordinate among themselves to open a fresh channel to keep that link lively.

Aaron van Wirdum You think it's better to open a new channel rather than rebalance or refund or whatever we want to call it, the existing channel?

Joost Jager Yeah, so... We need to define what's rebalanced and refund. There's different ways to do it. So you can open a fresh channel. That's the easiest way. You can also use a service like Loop, for example. So with Loop, and there's also other providers that do the same thing, you can push money out through a channel into an on-chain address. So you're basically loading money off Lightning into an on-chain address, and this changes your balance so that you can route more payments. But I'm always thinking, what does it cost in terms of chain fees? If you do a loop, there's two chain transactions involved. If you do open a channel and close a channel, it's also two chain transactions. So you have to be careful. Is this really the best option for me if I can simply open a fresh channel and that allows me to route more payments?

Sjors Provoost I guess one downside would be that because this reputation system you just described is based on channels, not on nodes. Like if you open a fresh channel, that doesn't have the great reputation of the previous channel. But I guess that can be solved.

Joost Jager No, in LND, it's based on node pairs.

Sjors Provoost Oh, node pairs, not the channel name.

Joost Jager So it's the pair of node keys. So indeed, we thought about this. And this is indeed to get around the problem that if you open fresh channels, you would lose your reputation. So that's not the case.

Sjors Provoost Nice. Great. Okay, then everything is solved.

Aaron van Wirdum Nice. Done.

Sjors Provoost I don't know. Did we have any?

Joost Jager We are close.

Aaron van Wirdum No. Is everything solved, Joost? I guess that's actually a good question. Are we done?

Joost Jager I think on the routing side, we have very few problems. At the moment, payments do succeed quite well. Only it's difficult to get a definitive answer to that because everything is so private. You can't have a master view showing you payment success rates across all of the network. If there are problems, it's mostly at the upper end of the amount range. So if you start to send larger payments, there are fewer channels that are available. And yeah. So if you see failed payments, they're usually there. If you want to send a one BTC payment, you need to find for channels that are able to carry that. And there may not be that many. But the solution for that is, in my opinion, just for the network to mature further, more of those bigger channels to be opened.

Sjors Provoost Along with the multi-path solutions.

Joost Jager Yeah, that's another way to get around that, to send it to multiple smaller shards. Yeah,

Aaron van Wirdum so before Sjors declared Lightning done, I think the idea here is basically that, yeah, it's a thing that channels get depleted, but the solution is simply that there is money to be made in offering. non-depleted channels and you think these incentives will work itself out and there were people willing to make money on offering these kinds of channels so that's sort of the solution is incentives and economics. Yes. And you think this aligns well enough for it to actually work itself out?

Joost Jager Yes.

Sjors Provoost So, that brought me to sort of a separate related point I guess let's say I have a Lightning node and I started it many years ago and I have a bunch of channels but I'm super lazy So the only thing I do is when I see that some of the channels are closed, I just open another channel to somewhere. What's going to happen to my node? Is it going to be left alone in the universe because it's not balanced correctly? Because I'm not doing that because that's work.

Joost Jager Yeah, so if you're very lucky, you will get perfectly balanced traffic on your node and you will keep getting free money forever.

Sjors Provoost I like that.

Aaron van Wirdum That sounds great.

Joost Jager But it's probably not going to be like that because what's the chance that your traffic is exactly balanced? Probably not. So you will end up with depleted channels and then you will need to open new ones to be able to keep routing or other people need to open channels to you.

Sjors Provoost Right. And I guess, so on a related note, like if too much money is on one side, you know, you might think, well, I opened the channel, so all the money is, you know, on the other side. But, you know, whose problem is that? But of course, the other side might want access to that money. So they might have an incentive to close it.

Joost Jager Yes. So if from your node there's no economical destination to go through, this channel towards you will also be useless. Like suppose you charge a very high routing fee. Like nobody will pick your outgoing channels on their routes, meaning your incoming channel is also not seeing any traffic. And if on that incoming channel the balance is fully on the side of the other node, they will basically have a useless channel with money locked up into it. So the reasonable thing to do then is to close it.

Sjors Provoost Yeah, and I guess this problem is bigger for mobile wallets because mobile wallets tend to be at the edge of the network. So if I have a mobile wallet and I open a channel to Amazon and I'm buying a couple of things in Amazon, then there's a whole bunch of money sitting on Amazon's side of that channel. But it can go the other direction unless I also get my salary on the mobile phone through Lightning in the other direction. So I guess what would you… how would you solve that?

Joost Jager Yeah, that's a good question. It's not just mobile wallets, but probably any end-user wallet that doesn't function as a routing node because the policies or the connections or the sizes of the channels, they are not right for being a routing node. If you have a channel, you open it and you're only spending very slowly and you accumulate more money on the other side. Yeah. How does it need to be compensated? So one idea could be that you would actually need to pay for this. So to pay for the channel to stay alive.

Sjors Provoost Yeah, you're renting the channel.

Joost Jager Yeah, and if you look at Lightning Labs Pool service, for example, you're buying a channel and the same thing is at play there because you get a guarantee that the channel stays open for a bit. I think this is something that can be, it's a parameter in the system. But after that, the other party is free to close the channel again. So if you buy a channel... Let's say you buy a 10 BTC channel, like extremely big channel, and nothing is happening on the channel. Like there's a lot of money locked up there. So after the obligatory period that it needs to remain open, the other party will probably close it because there's so much money in there.

Sjors Provoost Yeah. Okay. Aaron, you had a question?

Aaron van Wirdum No, I was just wondering, I mean, are there any solutions for lazy people like Sjors to automate all of this stuff so we can actually be lazy and still make money?

Sjors Provoost Yeah, but I'm not just lazy, I'm also paranoid. So I don't want to run sort of like autopilot like software.

Aaron van Wirdum Is there a solution for lazy and paranoid people like Sjors so they can make money for free?

Joost Jager This is an impossible question.

Sjors Provoost I'm actually okay with not making money for free. What I would like the situation to be is that the next time I want to make a Lightning payment, I still have peers.

Joost Jager Ah, right. So you don't want to earn any money, but just want to keep healthy channels. That's what you want.

Sjors Provoost Yeah, pretty much. I want to have the ability to make payments when I feel like it and to receive payments when I feel like it. Yeah, but other than that, I don't care too much. But if I don't look at the node for a year and I log into it again and it's disconnected, which, by the way, hasn't happened so far. Usually some of these channels are very old, so it's fine.

Joost Jager Yeah, it's a very good question. How does it come to play out in the end? Because if you have a channel and not all of it balances in your side, it is a cost to the other party. And if you don't look at it for 10 years, it doesn't work out for the channel to remain open for that long.

Sjors Provoost Unless, I guess, the other side also doesn't care.

Joost Jager Yeah, if nobody cares. But in the end, I think there is always people who care because it's money. So they can also do something else with that. So I'd say that it is unavoidable over time to make some kind of a payments in the channel to keep it open, to pay for your checking account.

Sjors Provoost Right. I guess I would be okay with automation at the level of, you know, this channel has a certain rent, so to speak. Yeah, just not too much magic.

Joost Jager Yeah, and it could be based on the balance on the other side. So if you just open the fresh channel, all the balance is still on your side. The rent will be very low because your counterparty will have very few funds locked up into it at that point. Whereas if you are a merchant and you expect lots of incoming payments, you get a large channel from a routing node. Then initially in that channel, you will probably need to pay a higher rent because there's still so much value at the other side. And as you sell your goods and you're receiving money, the balance will shift to your side and the rent can go down.

Sjors Provoost Okay.

Aaron van Wirdum All right. Joost, is there anything else our listeners need to know about routing and pathfinding or do we cover everything?

Joost Jager I think one thing that's interesting to be aware of, especially if you are a routing node, we already touched on that briefly, but I think it's still good to say that at least LND as a sender tries to extrapolate… the experiences that they have with some of your channels. So if you are a large routing node and you have a lot of channels and a few of those channels are bad and all the other ones are good, then it's good to be aware that if senders use those bad channels, they may not also try all your good channels. It's not that you just want to accept channels from anyone because accepting a channel from a bad peer could lead to your node’s [unclear] being degraded, and then your routing revenue going down and then there's no more free money.

Aaron van Wirdum Yeah, so it's a business that Sjors mentioned that guilt by association thing. So that is something to be aware of, especially if you're in it for the money and you want to make a profit by routing.

Sjors Provoost And quite strongly by association. So it's not just like... you know, you had this guy on the podcast. No, no, no. It's like this guy tweeted about you and now your reputation is soiled because somebody can make a connection.

Aaron van Wirdum A channel is still a bidirectional thing, right? You still need to agree to be part of the channel.

Sjors Provoost Yeah, but it's automatic. If I open a channel to you, then by default, you're just going to accept it within certain parameters.

Joost Jager By default, but this is something you can configure. You can create a channel acceptor plugin where you screen your potential peers, but it's all not out of the box, really, that that's going to happen. But the routing nodes are not something that work out of the box. Well, they do work, but if you want to be a good routing node, you need to do more than that.

Aaron van Wirdum Yeah, so it sounds like it's a job, Sjors. I'm sorry.

Sjors Provoost Yeah, well, we'll see how it goes. Okay, I think that's all we got, right?

Aaron van Wirdum I think so.

Sjors Provoost So thank you for listening to this.

Aaron van Wirdum Joost, thanks for coming. Sjors, do you feel like a Lightning expert now? Do you feel like a routing expert?

Sjors Provoost A little bit more.

Aaron van Wirdum A little bit more. Me too.

Sjors Provoost So thank you for listening to the Van Wirdum Sjorsnado.

Aaron van Wirdum There you go.