Lightning Loop Out/In, and Lightning Network Criticisms

Hi and welcome to the Stephan Livera podcast focused on Bitcoin and Austrian economics. Learn the economics and the technology of Bitcoin by listening to interviews with many of Bitcoin's best and brightest. Today my guest is Joost Jager. He is a Lightning infrastructure engineer working at Lightning Labs, and today we talk about Loop In, Loop Out, and also some responses to some of the criticisms leveled at the Lightning Network by Peter Rysen. Here's the interview. Joost, welcome to the show. Hi Stefan, thank you. Joost, I've seen some of the, some of the work you were doing, with Loop In and Loop Out and, Hodel Invoice, so I, I wanted to get you on and discuss about that and also a couple other things around, what's happening with, some of the, the concerns with Lightning as well, so that might be an interesting, thing to touch on, but perhaps if you could just start with telling us and the listeners a little bit of background on you and how

yeah. so I've been a software developer like for many years and working for a d-diverse range of companies, all kinds of, industries. I guess most notable, work that I did was around weather routing. So this is routing of route optimizations for, for ships. So giving them the most advantageous route given, the weather forecast. So this touches a little bit on, airline routing. and about a year ago, I decided to, to stop that work and take a crypto sabbatical. I had been looking in the space for so long already, and I thought It would be nice to do something more active here, besides just reading, reading articles, and I decided to start contributing to LND in my own time and just see what's going to happen if I would do that. And, yeah, I chose LND because it's, it's technically very challenging, like Lightning Network in itself and also the implementation of, the Lightning Network daemon. And, yeah, in my opinion, it has the, the potential to change the world, so this was for me like a perfect mix of what else can you wish for as an engineer? yeah, so and I did it for a few months, and then I was approached by, by Lightning Labs. they said we've got a, like a vacancy And yeah, we started talking. There aren't many companies working on LN, on Eln at that point. they seemed to be like, like a leading team pushing the frontier. So to me, it was an, an awesome opportunity, and I decided to join them. And from that point onwards, I was like a full-time Lightning developer.

Fantastic. Yeah. So as I'm sure you know, I've interviewed a number of the, Lightning Lab staff, and really, it just, you know, every time I've met and spoken with them, it's really, they've been I really like, what some of, you know, some of the stuff you're working on with Loop In and Loop Out, and I was hoping we can talk through some of that today. So, you know, just for the listeners, we'll try and keep this accessible at least at the start, and then we might get more technical, into, you know, the latter end of this, podcast. but can, can you just start with a basic overview of what is Loop Out for a non-technical person?

Yeah, yes, yeah. that's a How to explain this in the clearest possible way, because one thing that is important to understand first, and I don't know how many of these listeners, of your listeners know this, but in Lightning you can't just receive an unlimited amount of money like with other financial systems, it's usually not a problem. Like cash, you can accept any pile of cash that you like, also in Bitcoin on-chain, you, you have an address and people can transfer money into that address, it's not a problem. But with Lightning it's different because to, to be able to receive, you All have a channel with someone, and in addition to that, inside the channel, there needs to be enough balance at the remote end of the channel to actually send money to you. Like people have proposed different metaphors to, to visualize this, like you could look at the channel, as a tube that contains marbles, or the other one is like a string that has, beads attached to it. But in a way, this is, this is pretty different compared to other payment systems. You need to have that, that, that tube with, with marbles in it, and those marbles, they need to be at the other party's end to be able to receive.

Right. And I think, the other complexity here, or I suppose, yeah, so these, all these bi-directional payment channels, the other component I suppose is right now we are using, single funded channels, but hopefully in the future with, you know, the newer versions of the Lightning specification such as one point one, we might get dual funded channels, and that would be a way where, let's say, you and I set up a channel, we can set it up with some balance in both sides rather than, let's say, you open the channel to me and all the balance is on your side.

Right, yes. But even in that situation, once you start receiving, at some point the channel might still get depleted, like if, if, if your transactions aren't balanced, so you're s-receiving more than you're sending out, even a channel that starts out balanced might become unbalanced, and, what are you going to do at that point? But I think for the, for the user, like the, the most obvious problem is when you just start out with Lightning, you've got your wallet, you open a channel And then you want to receive money, and it's not possible at that point, because the-- you've got the capacity in the channel, but all the beads or all the marbles, they are at your side of the channel. And currently, you need help from someone else to be able to receive, or you need to buy things first. But if you don't want to buy anything, what are you going to do? And this is a problem that's, Loop Out, Loop Out is one way to solve this problem. Like there are other ways currently available to do it, but Loop Out is a particular way to do it. Right. And

so Loop Out is a way to receive, to have incoming, capacity. And who might use-- make use of this? So you mentioned an example, let's say, you know, just a random, you know, like a retailer, just an individual who wants to receive money. How about merchants? How might they need this? Yeah.

So it depends on like the where we are in, in time. In a world where merchants pay all their suppliers and employees through Lightning as well, it won't be that much of a problem, possibly. But at the moment, the situation probably is merchants are receiving lots of payments through Lightning and, their expenses go via other means, either f- via or, cri- like on-chain transactions. So what happens is they've got theirself set up with people having open channels to them. they start receiving funds, and at some point, all these channels get depleted, and they basically they can't sell anything anymore because those channels, have all the, all the beads are on their sides of the channel. And, in this situation, there are two things they can do. They can either close the channel, because if they, if they close those channels, they will receive the funds back on chain, and they can do something else with them. but if you do this, you lose the channel, and you have to basically hope that people are opening new channels to you. And this, this all depends on like, routing node operators and how much they think they can earn on opening channels to you. So you're basically dependent on that. I'm sure that like a huge, will attract inbound liquidity by itself, so people opening channels to them because they know that they can earn routing fees by doing that. but if not, and you close those channels Where do you get your inbound capacity from? And with Loop Out, what you can do is you can just leave those channels as they are and basically push a few marbles into the other direction in those tubes so that you're afterwards able to receive again.

Fantastic. And so maybe we can put that into like a more practical context. So let's say, just as an example, you might, a merchant might start with certain channels and they might have some incoming liquidity at the start, but then once they've made a lot of sales What happens is all the customers would have pushed all the beads to the merchant side of that channel, and so now what you're saying there is this loop out solution helps them push the beads back to the other side. Would that be a fair kind of way to summarize it?

Yeah, yeah. Just, we could also, explain it even simpler, like without going into the whole submarine swap story, but suppose you are the merchant, and I am someone else on the network, and you've depleted all your, your channels, you can't receive anymore. What you can do is you just send me a payment over Lightning and I give you back the money on chain or even cash or whatever in any, in, in some way I will compensate you again so that we both have a net result of zero. And, this is basically the trick that we're doing, like you, you pay me through Lightning, and I pay you back via another means.

Excellent. And I think the other, the thing here is, it's just, it, it may not be apparent to people, but it might be difficult to get incoming liquidity without these sorts of services. Now, perhaps we should compare this against other services that already exist. So one example would be Bitrefill's Thor service or Pierre Rochard's Lightning Power Users channels, where basically you can pay Pay them and they will provide you an incoming liquidity. So can you just help us compare that against using Loop Out?

Yeah. Yeah. So one difference there is that, those services sell you a channel and this channel endpoint will be a particular node. Like the service that sells you the channel owns the node and you get a channel from that, from that particular node, while in Loop Out you can take any channel that you already have and then- And create the ability to receive on that channel, so the channel of your liking. And, this is important for, for two reasons. So one is, suppose everyone would go to a few services that sell channels, like end users, for example, they, they would have channels with only those services in the end. while with Loop out, they can choose their, their own channels, and this, this like stimulates decentral—decentralization of the, of the network And the other thing that's important to consider is that not all inbound liquidity is equal. Like normally as a receiver, you don't worry too much about it because you say, "Okay, I'm connected to the network, I've-- I'm able to receive, so just send me the money." But for the sender, it's also important to know what kind of fees are they going to pay. And if you as a receiver are connected, for example, only through a single node that charges a ten percent forwarding fee, all your customers are forced to pay the ten percent fee to be able to pay you And, we don't think too much about it sometimes, but in, in the end, this also might become an important factor. It could be that you have enough inbound liquidity, but not the right liquidity. You don't want to force these fees that are paid to third parties upon your customers.

Right, exactly. And so I guess just to sort of reword that, you, you theoretically, right, now I'm not saying, you know, Bitrefill or Lightning Power users are going to do this, but let's say they set a very high fee rate and you, your only incoming Channels, and then essentially anyone who wants to pay you now would have to pay this very high fee rate, right? Just in a theoretical sense. And then obviously what you want to do is have many different sources of incoming liquidity, and that there would be some level of a market for this incoming liquidity, such that you're not, so to speak, hostage to the routing fees of one particular service provider.

Yeah. Definitely, if there are like lots of options to buy channels from, this becomes le-less of a problem. but with LoopOut, you're already now in the state of where we are at this point in time, you're already able to choose your own channels that you want to, get incoming capacity on. So, but what I, I wanted to touch upon an advantage of the channel buy services, because there's also, also an advantage to them, and that is that with LoopOut, suppose you want to receive a million, like, like, like a million dollars, you want, ignoring the fact that you can't open channels of that size, but suppose you Loop out, you need to open a channel of that size first, so you need to put that money upfront. then you have to loop everything out so that the one million in balance is at the other side of the channel, and then you receive the one million back. But for a short period of time, you, you actually need to have access to that money and able to create, the, the ability to receive an amount of that size. And, this is different with a, a channel buy-sell because there you only pay a small amount to buy the channel, and then

The balance that you, that you bought on their side, so you don't need to pay this out of your own pocket.

Yes, right. I see what you're saying.

Right. And I'm also interested if you could help us ex-understand how this would work in terms of the setup. So it would-- Would this be like a server that anyone can just set up and run?

the Loop server, you mean? Yes. Yeah, so currently the, the, the code of the Loop server is, is, is closed source, so it's not possible for anyone at the moment to set this up, but of course, people can create their own implementations of Submarine Swap. To do this.

Right, I see, I see. Yeah, okay. And so let's get into some of the other kind of, a little bit more technical now and just talk about how some of these areas kind of interact. So one area you, I've seen, on just on your GitHub, there was this concept of, it's called HTLC Switch or Huddle Invoice. Can you tell us a little bit about, you know, what that is and how does that contrast with like just a normal HTLC on the Lightning Network?

yeah. Yeah, so how does invoice-- it's not something different than an ACHLC, it's basically, it is an ACHLC. The only thing that, that is different is basically the timing. So, to go back to the basics, what's happen-- what happens for a receiver if an invoice is paid is, in the first stage, you are locking in an, a payment. So you receive a ACHLC and you lock it into your commitment transaction as a receiver. And at that point, what, an implementation does is going to look Look in the invoice database and see if this is an HLC for which we actually know the pre-image, because with the pre-image you can claim the money that's in the HLC. If the invoice is there, we take the pre-image and then we, we settle the invoice and we pull in the money. So this is all like a very fast process. You receive the HLC, you look up the pre-image, and you settle the HLC back at that point, and you've-- the invoice is considered paid. And the only thing that Hold invoice basically does is create a hook inside this, Delay this. So once you receive the HLC, we aren't directly going to look up the invoice and try to sell it, but just holding onto it because the HLC still have an expiry, height, so you can hold on them, f-onto them for, for a bit, and during this time you can check whether you actually want to settle this invoice or maybe not. And, this is a mechanism that's really useful for preventing, to go into the refund process for users. So what you can do here is a user pays to you, you are a web shop, you, you check your inventory, and if for some reason the thing that the user wants to order isn't in stock anymore, you just decide not to pull the invoice, pull the HLC in. You could do that because you have the pre-image, but you don't do it, and instead you just It is as, as if nothing happened. So it's not different from an HLC, it's just like the normal info settlement process, but there is a, a little hook point that is created where you can decide what to do, do I actually want to settle or cancel?

Right, I see. Yeah, and I suppose, yeah, before we get sort of into that, I guess it's good also to talk through the mechanism which you, you were discussing there. So, just from your post here as well, it talks about how you, you know, the user would generate In the Loop server, step three says pay to hash locked output, as you were mentioning, then, step four sweep that hash locked output, and then five, finally, is back on the other side, the Lightning Network settles the payment back to the Loop server, and so that is what you were saying there that That is where you could, you know, decide, decide whether to pull it in or leave it. Is that correct?

Yeah, that's correct. And in the case of, a loop, it's, we are holding on to the HLC, but initially we're not e-e-even able to settle because we don't know the pre-image yet. And this is also what makes the service trustless. So a user pays a whole invoice to the server, the server has the HLC, it knows that for a certain amount of time When I get the preimage, when I learn the preimage, I'm able to, f-for sure, get this payment, but I don't have the preimage yet. And, knowing this, the server there's no risk for the server to, to publish the HLC on chain. the user can only sweep that HLC by revealing the pre-image, and because we know that we've got that whole invoice, hanging on to our note, once we've got the pre-image, we can pull in that payment. So this is like the, the basic principle that, that makes the whole operation trustless.

Right. Okay. Excellent. And I think the other thing, that would be cool to touch on is you mentioned here that there's a, a denial of

Yeah, yeah, we were forced to introduce that because, if you look at who's going to spend money first in Loop Out, it's the Loop server that's first going to spend money because what's happening, is that the Loop server starts with publishing an on-chain HGLC and to, to do this, f-miner, f-miner fee needs to be paid. And without the pre-prepayment, it wouldn't be possible for users to initiate swaps. they do need to pay the whole invoice, but if in the end they don't follow up with sweeping the on

The order invoice can never be pulled in because the pre-image is never learnt by the server. Eventually, it will be cancelled back, but at, at that point, the server would have spent a fee, a minor fee to publish the HLC and a second minor fee to reclaim the HLC because it hasn't been spent by the client. So this is, on the one hand, it's, it's a way to, to protect ourselves from, from losing money by that, like the, the user only needs to commit funds in an order invoice, which, he gets back in the end,

Twice a miner fee that we can't get, can't recover anymore. Excellent. And

I think you also mentioned here that it's also about having enough UTXOs as well.

Yeah, if you suppose this would be possible to do, like an attacker could not only force us to spend money on miner fees, but if you do this in quick succession, we are also going to-- it, it will also lock up our UTXOs because all the time we are publishing transactions on the blockchain that have a, a, a time lock on them, so those UTXOs can't be used So this is like a second reason why, we need to have to, have the prepayment. So locking up all our UTXOs would mean that we can't service other users anymore. Right, exactly.

interesting stuff. And, just curious as well, is this something that could be-- what's the interoperability like in terms of other implementations? So let's say it's a C-Lightning user who wants to use this service, can they, or is this LND only at this point?

At, at this point, it's LND only, but if you, if you look at the server, like what, what's the interface of the server? It's basically like the Bitcoin blockchain, it's the Lightning Network, and there is a single RPC call to initiate the swap. So it's very well possible to write a client implementation that connects to the Loop server that, handles the client part of, of, of looping for a, a different Lightning, implementation. But We didn't implement it like that, but it is possible, like in that way it is interoperable, but it's not available at the moment. Yeah.

Okay, and I think it might be interesting now to talk about the flip side of this, which is the loop in. So could you just give us a, a basic overview on that?

Yeah, indeed. So loop in is indeed the flip side. So what's happening is, is that coins are moving in the, in the other direction. So this is to solve the opposite problem. Suppose you've got a channel, you've spent everything inside

Close the channel and open a new channel, but you can also, use Loop in to, to regain the ability to, to buy basically. So what happens is that you send an on-chain transaction, it's an, it's again a, a hash lock contract, and the amount that's in that hash lock contract will be sent to you off-chain into the channel of your choice.

So to summarize then, it would be like, let's say I have a channel open to you, Joost, and all the beads, On your side of the channel, and I want to now get some more on my side, but let's say you don't necessarily want to spend to me or pay to me, so I would pay an on-chain transaction to then have my channel kind of replenished on my own side so that I actually have more outgoing capacity. Is that correct?

Yeah, that's correct. So, so in, in a way, this competes more with like reopening a new channel. In the, in the loop out case, you can close your channel and open a channel, but you still won't have- Have any, possibility to receive, with Loop in, it is different. So if you deplete your channel, you can close it, open a new one, and at that point, all the beats are on your side again. but we, we see that with Loop in there are also like more advanced things possible, such as, looping in multiple channels at once. So this has to do with, it, it also needs like the, the multi-path payments, but there is potential both for loop in and loop out to, to be able to refill or unload multiple channels at once. And it all, there, it will all come down to, to what kind of fees am I going to pay in the end? Like, what's the, the on-chain fee for me to, to close and open a channel versus what am I going to pay altogether for, for using the, the loop service? And the other aspect here, but it

So a channel has an age, like the height at which it was, at, at whi-at which it was created, and, it could be that this age is used as a heuristic, for example, for people, having an autopilot active that needs to select which node am I going to connect to, and also users, wanting to optimizing their routes, they could also look at channel age. So there might be an, an argument to, to have old channels because they may signal stability. Right.

It's kind of like, it might be,

This reminds me of, in the older days, when people on IRC would all brag about their uptime of their computer. So,

you know, maybe people can brag about the uptime of their channel. Yeah? Connect to me, I've got a year old channels. Yeah? It's like good wine. Yes, your Lightning channel is like a good wine. It just, you know, it gets better with age. Yeah. But it is still to be seen, like what, what will be the role of channel age in those heuristics?

It's also still, sim- something that needs to develop as well.

Yeah, sure, sure. And

also, just looking

through some of the, you know, documentation

and stuff,

I saw this

concept

of loop de loop. Do you mind explaining that one for us?

Yeah, that's pretty interesting. Like to-- what you can do is, I can open a million satoshis channel, I can loop everything out, and at that point, I've got a channel, all the beats are at the remote party, and I've got my million satoshis back in my on-chain wallet, minus a few fees, but let's, let's ignore that for now. And what I can do now, now with that on-chain, funds, is open a new channel to, to another node or to the same node, and once I've got the channel confirmed

Over and, and open channels with people and basically force them to commit their capital to me, like w-with one million Satoshi, I could gain like twenty million of, of, of in, of inbound receive capacity. and that is quite, quite interesting that you can do this. It also sounds a little bit counterintuitive, like if I only got a million, how can I get twenty million inbound? But it, in this way, it is possible. and this also illustrates the need for nodes to also become more Critical about the channels that they have. Suppose everyone would do this, you, you would force other people to commit their capital to you, if at that point you are never going to receive any payments, because nobody's paying you, that capital will, there, there will be no return on that capital, it will just sit there. So nodes will become more active in, in monitoring this and also closing channels that, that aren't profitable for them.

very interesting. Yeah, thank you for explaining that. I, I hadn't quite grasped it, but I think once you explained it there I think I understand that a little bit better, but essentially it's, right now on the network, people will most of the time just open a channel with whoever, right? Like if someone offers to open a channel to you, then, you know, they'll just accept it. but I suppose here, what it's doing is it's forcing all the balance to be on the other person's side rather than on your side. And so like you're saying, it's committing their own capital, and in that sense, it's, you know, the-- 'cause there's a cost of capital

Some sense. I, I wonder if there's some game playing to be had here that people will, will do this to just try and have lots of incoming liquidity without spending any themselves.

Yeah, you, you could do this and, A routing node operator wants to see a profit, like see, see, returns on the capital commitment. So for them, it's a challenge like, where, in what direction am I going to co-commit my capital to? And it needs to, to be committed into directions that, that actually, Will allow, will take traffic in that direction. So if you as a user can decide where someone else is going to commit their capital, in the end, this isn't going to work. So something needs to be developed to counter that. Right. And I

suppose in this case, let's say you're a merchant, it might make sense for you to do that because, and even the routing node person might want that because he may sense that, oh yeah, I actually want to have capacity to send to this merchant so that Other people route through me, therefore I would get the routing fee.

Yeah, that's how it usually works. Like routing nodes, they, they need to think about what are good destinations to, to open channels to. Is that what you mean or what? Yeah, yeah, exactly.

And I was just trying to kind of outline that a little bit further. Okay, excellent. so did you have anything else you wanted to touch on with Loop in or Loop

out? Maybe just mention that we just released a new version of Loop that supports Loop in on Testnet, so it's not ready for Main It can be played with already now. Fantastic.

Okay, so Joost, I was hoping to also now cover some of the stuff that's come up recently with, what we might call concerns with Lightning, right? So there was a recent, quite recent episode with Peter Risen on Peter McCormack's podcast, the What Bitcoin Did show, and, was hoping to just talk through a few of those concerns there. Now, obviously, I have quite a few disagreements with the way Peter Risen, explained things, particularly with some of the stuff around SegWit 2x, I thought that was quite, ignorant or just perhaps not the right way to explain what happened there. But let's, let's kind of focus more on his, criticisms of the Lightning Network. And, I mean, look, personally, in my experience, I think every Lightning developer I've spoken to, at least, you know, in the many interviews that I've done, they've all been very open and honest about, you know, what the limitations are and what the work being, you know, what, what, what work is being done, but okay, so maybe just allow me to maybe just summarize some of Peter's concerns and then, you can, we can, you know, we can just hear what some of your thoughts are on that. So one of Peter's main thrusts or criticisms is around this idea of variability of fees in Bitcoin and how, in his view, you know, Lightning may struggle in a high fee environment or where the fees are inconsistent and, you know, it's all about if the fees are kind of moving up and down a lot. And so he brings up examples of things like the fee reserve moving up Basically, the other criticism he levels is that he thinks Lightning Network as it is will drive too much custodial wallet use and that people won't hold their own keys. So I suppose in terms of his main thrusts, do you have any, thoughts on that?

Yeah, I, I think in general, that at the moment there, there are definitely proof in that you see, with regards to custodial wallets, they are pretty popular. I've been to meetups myself as well, and, there is like half of the people just install a custodial wallet because everything is easy for them, and the other half, tries with non-custodial, and they are indeed a bit struggling at the moment. And I think, we have only just started, and, to make something non-custodial, like decentralized Rather than making it, in, offering a centralized solution, it's like similar to if you would want to build like a decentralized Twitter, it's like, like a huge, challenge, and if, if it's cen- if it's centralized, it's, yeah, something that has been done many times before already. So I think it's just still really early. I see for all these- Issues that currently exist with a non-custodial wallet like where to open channels to, how to manage those channels, like when to loop out, when to loop in, to do that all like in a completely transparent way. Yeah, there's a lot of work to do there, but, also I don't see why this fundamentally wouldn't work to automate all of this in the end.

Right, yeah, agreed. and I think maybe let's touch on, so one of his first, I think he's got five main ideas, so I've listed some of them out. So one of them is he, he believes that it would be hard to onboard users and that, in his terminology, he thinks Lightning only scales the transactions and not the number of users. So one of the concerns is theoretically that over time There will not be enough UTXOs, unspent transaction outputs, for each person to be sovereign, and so, in my mind, I was thinking, well, that can be partially solved with things like multi-party channels, as, my earlier discussion with, Christian Decker, and also some use of custodial, but not necessarily everyone going custodial. What are your thoughts there?

yeah. First, I think it's isn't it a great problem to have, like if we're talking about blocks that are completely filled with channel open transactions all the time? Like, if we actually reached that

point, it's, it is a huge success, isn't it? Exactly. Yeah, because it's, it's almost like some of these things are

almost like a, a, a, a quote-unquote good problem to have, right? so I, I think the other thing in terms of like, oh, the fees and so on, because at least the way

And over time, we'll start to see, hopefully, like a more stable kind of fee rate, and there will be kind of, you h- you'll have to pay fees to get a transaction in, and therefore it kind of means each transaction needs to be a little bit more weighty, if that makes sense, like as in, in the, the, container ships, not, the container ships analogy.

so I'm not completely sure. So you're talking about fees going up, and what, what will the impact for Lightning be?

Yes, but I suppose let me expand that a little bit further. I think from when I was speaking with my earlier episode with Christian Decker, I think one thing he mentioned there was this idea of being able to perhaps tune the timing windows of Lightning Network such that It is still okay to work, work with it. So in Lightning, that might be changing the retaliation window

time. right. So you've got more

opportunity to wait for fees to come down, you mean, to publish your, your transaction? Yes. Yeah. Yeah, I can. I, I haven't thought too much about this subject myself, but I can see that working. But I'm also wondering, what is the fee market going to look like in the future? You could also bring up an argument to say like, suppose every transaction is a, is a, a lightning transaction. So will there be as much demand for a chain space as there is now? Like in, like in a, a stable situation where everyone has a channel open and can happily transact through that channel, there, there might even be like less on-chain transact- Transactions that we have at the moment. Some people even worry that if the amount of transaction goes down that much, that it might actually threaten the security of the blockchain if the block reward goes down as well. So there's nothing to, to, to earn anymore for miners. Right. Yeah.

But I think ultimately it's that whole-- People have spoken about that idea of like Jeffries' paradox and so on, that the more uses there are for Bitcoin and the more people ultimately, just the more people trying to use it overall, I think, in my view, I think that we should be optimistic that, We will see more use of, Bitcoin's blockchain, whether that is for Lightning channel open and close, or whether that's just for a straight up, you know, Bitcoin transaction, let's say between, settlement between big, you know, Bitcoin banks or between, you know, kind of, you know, Bitcoin whales and so on, let's, you know, in the future, right, ten, fifteen, twenty years down the line. now, might be good to touch on another one, Peter Risen mentioned. So he talks about this idea of friction from layer one and some of this stuff around the fee reserve. So he mentions how, okay, let's say if the fees were to spike, then the fee reserve in a certain channel may go up, and then the other party may close the channel on you. Do you have any thoughts on that? Yeah.

I, I don't think I have a good opinion about that, really. I haven't given it that much thought. Yeah. I know, I, I understand, I understand what the problem is. It all depends, like, if you've got, like, you need to pay a thousand dollar to, to, to bring a channel, a transaction on chain, that changes, like- The thing drastically. So

yeah, right. I think one response that I have seen was, Stop and Decrypt, and he recently posted something there saying, "Well, on a sat per byte basis, fees have historically remained about the same, but have gone up in USD value. So in my view, it might be similar to that thing we were saying before about it, it might just be a good problem to have, but there are also other possibilities as well. So I think even in the interview, Peter McComack brings up, this concept of probabilistic which Tadzh has also, brought up as well. So that's one, that's just a few examples. and then another one that comes up is this idea of having to be online to receive a payment. So what's your thoughts on that?

Yeah, that's also interesting indeed. there are some ide-ideas around this. Of course, you could say, are we really offline anymore at, in the future? So that's one, that's one answer to it. The other one could be a, a different model, like, if, if Lightning nodes, but it's more the casa, the, the casa model. So people have like a bank in their, in their house, a, a lightning node, and they just use their phones as remote controls for that. So those nodes will be probably more online than, than phones are. and one other idea to not introduce anything custodial would be, to create sort of a mailbox. So if the, the, the hop prior to yourself sees that you're offline, similar to how it basically works with, with hold invoice, it's not going to- Directly cancel back the HLC because that's what's happening currently. If, if the hop can't deliver the HLC, it will just cancel the payment back, but it could also decide to hold on to it for a while, as long as possible, given the, the expiry of the, of the HLC. And when you come online within a certain window, then it can still deliver it. So it's not custodial, but it does mitigate the problem a bit of being offline for a limited period of time.

Right. Yeah. And I guess the other thing is, some of Through engineering. So an example is the Eclair Android wallet. So my understanding is when that wallet, and my personal experience as well, is when you first-- when I first had that wallet, it didn't have receive, and then they actually did some certain trade-offs to expand the retaliation window such that the channels can now Eclair mobile wallet can actually receive.

retaliation window, that's, that sounds more like related to, to watchtower. So I think there's like two things not to confuse. So the one One is, am I able to receive and settle an ALC when I'm offline? and the other one is if I'm offline, people might breach on me by publishing outdated, channel state? I think the one you were talking about, about the retaliation, has to do with, with watching the chain and, by having it watched by, by another party and making sure that, any that, breaches are detected and acted upon.

Right, I see, I see you. Yeah. and I think My understanding on it is that, it's, what's it called? Yeah, so that, yeah, it's called, just opening my, it says "Retaliation Window" and it's got "Remote Uncooperative Close." So I think that's what it's, referring to. And then it's got a, and that's saying two thousand and sixteen blocks. So, I mean, that's just an example. and we can also talk about a few other ones that come up as, that have come up from Peter as well. Another one So essentially he's saying, "Oh, the problem might be you might not be able to find a route with the sufficient liquidity, and perhaps that's ignoring the work in things like AMP and some of the work, I think even on LND zero point six, about disregarding zombie channels." Can you comment a little bit on that?

Yeah, so this is an area that I'm, I'm working on myself as well at the moment. currently we are as a sender, we are pretty like relaxed around node and channel reputation. So if, if- If you try to pay and it fails, we, at least in LND, we do something with managing the reputation of that node or channel, but not too much. I can imagine that in the future senders are becoming much more aggressive in that, in that regard. So if you are a routing node and someone tries to pay through you and you are the cause of the failure, you are just like maybe not immediately blacklisted, but at least the probability of being chosen again for future attempts will be severely lowered. and by, by doing that, and this needs to- Go hand in hand with those reliable nodes being available on the network, I think the number of attempts needed can drastically go down.

Right, exactly. and Sorry, go

on. Is

that, is that clear or do I need to elaborate? Yeah, no, I think, I think

that, that was clear to me, but maybe I'll just, I'll just paraphrase it, hopefully. So just for any listeners who are struggling to follow along there, essentially it's like saying routing nodes that aren't doing a good job will be less likely to be selected for routing in the future, and that in some sense helps, in some way helps keep the health of the, you know, the routing success probability of the network higher. Would that be a fair summary

And those nodes, they, they want to earn forwarding fees, so if they are unreliable, they aren't selected anymore, so they won't earn any money. So this should basically solve itself, but we can't just say today, like, we make every sender super strict, like if a node fails, then once we blacklist them for a full month, in the end, you won't have any options anymore to, to, to send. So this needs to go a bit hand in hand, nodes becoming more active in managing their, at least public channels, making sure that they are balanced Are, are online, and on the other end senders becoming more aggressive in pruning nodes out that don't live up to the expectations that we have of a routing node. Right.

Okay. Yeah. And I think the other thing there is also this concept around mobile phones having to route, right? So, can you just touch on what's involved with that? Like, does the mobile phone need to have the entire network graph stored and compute that, or is there, like, are there mitigations around that?

Yeah. And what I find an interesting question is also what will be the size of the graph in the end, because now it's like really big, a lot of channels, they are public while they don't serve a good routing purpose. But I think at the point where, senders are going to penalize nodes for not forwarding properly, those nodes will be careful with which channels they actually open as public, because those public channels they can be chosen for, in, in, in path finding, and if it fails, then it will be bad for the reputation. So this might actually also Compact graph that doesn't include channels that aren't very useful, and this also makes it more feasible to, to do all this on a, on a mobile phone.

Right. So if I were to summarize then, it's sort of like we will make more judicious use of private versus public channels such that the network graph is more manageable for a mobile phone to traverse or have kind of contain that in its memory. Would that be right?

Yeah. I think in the end nodes will be, be forced as well to make some, channels private once they notice That they are being skipped in pathfinding because they advertise channels that aren't well balanced, for example, they won't earn anything anymore. So this should be like a, a system that, that improves itself in a way. and of course, there are for mobile phones there's also like hybrid solutions where you- Might, what, what we do for the, for the Lightning app as well, like there's, there's a list of, of notes that have been probed before, like a, a, the boss list, a, a list of good notes, it isn't The complete decentralized dream, but it does make things, easier. and then you've got, I think, the, the Eclair model, where there is, also a, a, a default node that is just a good routing node, and if you connect to that, you won't have too many problems. So there are ways that- Might not be perfect from a decentralization point of view, but can work very well in practice on a mobile phone.

Right, yeah. And I think in practice, what we're-- look, let's be honest, what we're most likely to see is this model of home node and your mobile phone pairs to that home node. So I think in reality, most people are going to be using the mobile phone as a remote control for the node rather than trying to have a, you know, all-in-one, everything on the mobile node. I'm, I'm not sure what

way it will go. I've seen both people, opting for both options now, so the various, like degrees of custodialness of, a, a mobile app and people are using it only as a remote control. Yeah, I'm not sure yet which direction it will go. it is definitely a challenge to get it all running on, on, on a phone, but it's not said that we won't succeed.

Let's move on. number four, that, Peter Riesen brings up is this whole trapped liquidity, concept, and if I were to just quickly summarize, essentially, I, I think actually Loop helps this exact problem, but if I were to summarize the way he explains it in that interview, it's something like, imagine you're hosting a concert and Well, what do you do? How do you get that incoming liquidity? And then you might have to go and pay for this, you know, to get someone to give you incoming liquidity. And I suppose as we've just, you know, the first part of this interview, we were talking exactly about Loop Out, and we touched on Loop In as well. So in your view, would you-- do you, do you believe Loop in and out can help with this sort of problem?

Yeah, they, they def- they definitely help with this, with the sort of problem. So either Loop or any of the other solutions that currently exist to, to gain inbound liquidity. And, indeed, you need to pay for that, but in the, in the, in the world outside of Lightning, it's also pretty common that, that merchants need to pay to, in or in order to receive. So, this will be an interesting question, like,

Everything is balanced and mature. What, what will people pay to actually get this inbound liquidity? Maybe they also pay, pay nothing, like if, which I, which I try to explain at the beginning as well. If you are like a huge merchant and people know that opening a channel to you, makes them earn routing fees of the customers of that merchant paying through you, it could also be solved like automatically in a sense.

Yeah, great point. I agree. Okay, and lastly, I think, I think Peter is basically, Peter Ryzen is, is skeptical of being Away some of this complexity. So obviously, you and I have spoken in a little bit more of a technical way. This is kind of, you either need to be a developer or someone who's quite enthusiastic and interested to go and learn about, you know, the difference between on-chain Bitcoin, off-chain Bitcoin, channel management, are we doing it in a custodial way or am I doing it in a sovereign way where I hold the keys? Now, I guess one of my criticisms is of that idea is that I think maybe Peter Risen and some of the BeeCasher types are perhaps overly romanticizing this SPV mobile wallet use and the twelve word seed, and they're sort of putting too much into this idea of just being able to- Have like a certain, they're kind of holding on to a certain user experience that may not be feasible, like in the long term. But what are your thoughts, sir?

Yeah, I think it all depends on whether you believe that, that on-chain can work to serve the whole world. Obviously, Lightning is a complicated solution. There are all kinds of, u-unique problems that first we discover and then we need to solve them, and we need to solve them in such a way that ideally the, no, the user doesn't notice any of that. but yeah, if you don't think that you can make it with on-chain, you need to do something else, and then you're forced to solve those problems. So I think it comes down to that. If you believe on-chain can scale, then there are-- it's, it's easier, yeah.

so look, I think that's the kind of most of the points that I wanted to bring up from, Peter Rison to get your comments. Is there anything else that you wanted to mention in terms of, Peter Rison's criticisms of the Lightning Network?

I think in general, it's still just pretty early and, speculating about, you know, what, what, what could happen, like fees becoming huge or, four mil- four billion people, starting to use Lightning Network. I think it's interesting to, to think about at this point, but on the other hand, we, we've just started and Lightning Network, it does serve a, a pro- it does solve a problem that we have at the moment. So, yeah, I'm not, I'm not too worried yet about that.

Yeah, I, I I think, like you said, it, it comes back to that idea of whether you believe you can scale on chain, and I think basically most, or if not all, Bitcoiners believe that you can't do that. While, while maintaining certain other decentralized or certain other characteristics that make Bitcoin government resistant. but I suppose let's, let's sort of finish up with, if you've got any thoughts on what you're looking forward to most with Bitcoin and Lightning technology, and also just if you've got anything that we should keep an eye out for from Lightning Labs.

Yeah. I think, I think for Lightning, I would really love to see like a-- This is not a very original statement, but I would like to love to see a, a, a killer application that, that really highlights- benefits of Lightning that don't exist in any other form, and my idea is that this should be in the micropayments sphere because there it really has a unique advantage over other payment methods, like paying this one hundred Satoshi, it's hardly possible in any other, in any other way, so that would be great for, for adoption. It's not like a, a technical thing, but, It would be interesting to see if this is going to appear soon. and in terms of like more technical developments, I'm pretty interested in improving payment reliability in general. So I, I think there are all kinds of ideas to, build more things on top of Lightning, make it even more complicated than it already is. But I, I, I'm also interested in, making like a basic payment reliable, so the things that we talked about, offering routing node operators Tools for channel management, so to monitor that channels to see are they profitable, yes or no, maybe automatically close down the ones that they, that are not profitable. and this allows also the senders to, to be more aggressive with reputation management and reduce the number of routing failures. possibly related to that is also probing. This is something that we currently don't do yet, but, not immediately make the payment, but make a probe first with a smaller amount to test the route, like all things to just make the basic payment. More successful than it, than it currently is.

How about anything just to keep an eye out coming from Lightning Labs?

yeah, I think, one of the things that we want to start work on are these, these tools for, for channel management, so to, to create insights for, for routing node operators to, to see how their channels are doing. Would that

be

similar to things like

RTL or LN Dash?

I haven't looked at those, myself, but, I think there work that fundamental work that needs to be done is, also to improve accounting in LND so that it actually becomes possible to, to gather all the information that you need about the channel to- To make this evaluation.

excellent. Yeah, so maybe, yeah, around giving the actual data that those, dashboards might use. excellent. Okay, so look, I think Joost, I think that was pretty much it. So maybe just finish up with just telling the listeners where they can find you and, you know, where they can, find Lightning Labs and what, what, you know, any other last pieces of advice.

Yeah. So I've got my, my Twitter, I guess you, you will post, post a link. and I think to get in contact with Lightning Labs, the, the LND Slack is the best way to do it. we are all pretty active, there to provide support, to discuss wishes for new features, et cetera. So And we've got our blog that's, that has some useful

information too. Great. Well, I'll put all the links there in the description. And thank you very much for coming and joining me on the show today, Joost. Yeah, Stefan, thank you for having me. I hope you enjoyed the discussion there with Joost about Lightning Loop Out and Lightning Loop In, as well as his thoughts on Peter Rysen's criticism of the Lightning Network. Just wanted to add a few thoughts here. I really disagree very much with Peter Rysen's criticisms, of the Lightning Network Some, if you're being very charitable, there might be some elements of it that are fair, but I think ultimately the solution that he presents isn't the right one. Ultimately, lo-- Bitcoin can't scale just naively through block size increase. It will drive an unnecessary and just too great centralization pressure. It would make it harder for the network to stay in consensus as well. So if you're interested to listen to more on this, listen to episode fifty-five with Shinobi. And also, I think we should point out that the Lightning developers have been very open and very honest about many of the trade-offs that they're facing in what they are building. It's not like they're hiding any of this. You could listen to, earlier interviews. Another one would be, fifty-seven with Christian Decker, and we're talking about multi-party channels, which would be one way in which Lightning Network could really scale out in a way that is low fee and accessible to many, many people. But that's just, you know, that's a little while off. We might L2 and so on before we get to that. And ultimately, there are many problems that will disappear over time through further development work and th-th- further work by the Bitcoiners who are building solutions to these problems. So I just, I really disagree with the way Peter Rysen approaches this. So Let me know your thoughts, I'm always willing to hear your thoughts as well. You can DM me or there's a contact page on my website as well. Also, just wanted to let you guys know I'm going on holidays for about three weeks, but I will have some episodes queued up and have those auto-release. Just make sure you're subscribed on a podcast app because I'm traveling, I may not necessarily have as much time to set up the website, but if you get on the podcast app, you'll get the episodes there. That's it from me. Thanks guys, and I'll speak to