Lightning x Liquidity *rebalancing edition* by Lisa Neigut | BTC++ 2022

Link to the YouTube: https://youtu.be/5E9aB4REpOk?t=1596

Lisa Neigut: Today we’re going to talk about some of my things that I like spending time thinking about, which is Lightning and liquidity. Specifically, I’m going to talk about a proposal I made at the last Lightning spec meeting which was last week, so this I’m going to call it pre-spec, which means that the spec is in the process of being written and I haven’t made a mailing list post yet but it’s coming as soon as I get a second, so probably end of this week-next week. So it’s probably super-early pre-print, so to speak, of a not yet drafted paper, but I’m really excited about this — I think that it’s going to change the game on how Lightning payments happen and hopefully open up some really cool opportunities for more people to do stuff on Lightning in both increasing the amount of payment traffic that’s happening and just getting more of a healthy liquidity ecosystem going. So the topic that we’re talking about is Lightning x Liquidity *rebalancing edition*. I actually gave a talk called Lightning x Liquidity back in the Lightning conference of 2019 where I introduced liquidity ads, so this is the 2022 edition where we’re talking about rebalancing. The liquidity ad thing was like, How do we deploy capital to the Lightning Network? This is about how do we get the most out of the capital that’s already been deployed to the Lightning Network. For those of you who are unfamiliar with Lightning, I hear Fabrice had a great talk yesterday about how it works, assuming you understand channels etc. — maybe you’ll learn some stuff today. Great, so here’s a node and here’s another node and they have a channel between them and that channel has a balance and usually the balance is in one person’s favor or another. In this case the node on the left has more liquidity than the node on the right, so if you want to send a payment to the channel, it’ll move that balance over to the other side of the node when the payment happens. So payments move balances from one person’s side to the other. Another payment goes through, it gets moved over even more — so now if you want to send payments in this direction you can’t anymore because there’s not enough liquidity on that person’s side of the channel to move it to other side. This is something that René Pickhardt [has been working on], who’s been doing a lot of more theoretical research in liquidity and how liquidity works. He calls this channel a depleted channel at this point because payments have moved through the channel so much that there’s not enough liquidity left on this side of the channel — it’s been depleted — so no more payments can flow in this direction. Instead, only payments can flow in this direction. So all the liquidity — available balance — is on the other side of the channel. It’s been depleted in one direction. You’ll notice that when a channel gets depleted in one direction, that automatically means it’s extremely available in the other direction. So if this guy on this side wanted to send a payment, he would extremely be able to send a payment pretty much almost up to the size of that channel. So it’s not a one-way thing, but once one side gets depleted, the other side has a lot, and then if the other side gets depleted — so anyways, it’s not like a channel ever can’t route payments, it just can’t route payments in a certain direction. Okay, so how do you come back from this? You could close the channel, but that costs money. So what people do currently — the current state of play in how do I get liquidity back in this channel — is you have another channel that’s got a lot of outgoing capacity, this magical other channel existing somewhere in the right place in the graph that also has some liquidity in it pointing in the other direction, and you can route a payment to yourself through the existing graph. So you can push out a payment like this, and as it moves around, the money moves with it, if that makes sense. So this is what you started with before you did the rebalance, and then you pushed a payment all the way around, and now at the ending point this is what your channel liquidity looks like after rebalance. And you did that by taking a payment, sending it around through some magic channels out here, and then back to yourself. One thing you’ll notice is that if you added these arrows together, it should be the same number — this is called outbound capacity, it’s the amount you pay out — and so you haven’t made your outbound capacity any larger, you’ve just moved it around. So you had let’s say 1,000 sats total, 500 and 500 here, and here it was 999 and 1 — you just pushed it around through the channel graph so that you still have the same total amount, it’s just in different places. Okay so this seems fine — I don’t know, doing this can be expensive. What does that mean? So the way that Lightning payments are priced is that the node here has a gate between this capacity here, and when you want to make a payment through that gate you basically pay the money at that point. So pushing a payment around here means there’s two gates that you have to pay — you have to pay a gate at this one and you’re gonna have to pay a gate at this one. This is mine — I don’t have to pay anything to push this, so I can push this here — this is not mine, so I have to pay them to push it to the other side, and then that’s not mine, I have to pay them to push it to the other side. So when my payment goes around I’m gonna have to pay two nodes a fee to make this rebalance happen. Another thing that’s possible — in fact, the handful of times I have personally attempted rebalancing is that you may not find a route that succeeds, so you could send a payment and then it gets here and there’s not enough capacity here to send it which means you can’t send it back so you can’t finish the rebalance because there’s not a third link here somewhere in the graph that has enough capacity that you can push the amount you want to around. So rebalances aren’t guaranteed to succeed. There’s no guarantee that there is enough available balance on the other channels that you have to route through to do the rebalance that makes it such that you can actually get your stuff moved around. The other thing is that it unbalances your peers’ channels, so before your peer’s balance was like this — maybe they were really happy with this — but then you pushed a payment through it and totally moved it in a different direction with your rebalance, and maybe that’s not as beneficial to them as if you hadn’t done that. So rebalancing has external effects on other channels in the entire network graph that are connected to you. Maybe that’s fine, maybe it’s not — I’m not here to pass judgment about it, but it’s just definitely an impact that rebalancing as a practice has. So maybe they didn’t like it — I don’t know. Can we do better? Good question. So rebalancing is basically one person using their available capacity, etc., to reroute payments to themselves. So the only way that you can really do rebalancing right now is with self-payments — you have to send one out and bring it back to you, and that’ll move your money around between your channels. Like I said, it costs money — usually it costs money. Maybe you’re not able to do it, and then you usually upset things for other people in the graph. One of my co-workers, Christian Decker, is of the opinion that rebalancing is really never worth it. So can we do better than that? So maybe one way of thinking about ways to do better is, Well, what are we trying to do in the first place? So why rebalance at all? One of the reasons you’re doing a rebalance is because, ideally you’re trying to make more payments work on Lightning. Because, if you have a Lightning channel, you’ve taken some Bitcoin and you’ve locked it up into that. Most of the reasons that people do this — everyone has different reasons why they open Lightning channels — I think one of the more ambitious ones is they want to earn more Bitcoin with their Bitcoin by running a Lightning node. So if you’re taking money and putting it into Lightning, usually that costs you money. You have to pay an on-chain fee — a layer one Bitcoin fee — and then every time a payment gets routed through your channel you make a little bit of money. So you’re betting that your ability to make money by routing payments is going to be more than you paid in on-chain fees, otherwise you’d be losing money running a Lightning node, and that wouldn’t meet your goal of earning more Bitcoin with the Lightning node. So one way you can make the most of the money (the Bitcoin) that you lock into it is if you push it to one side of the channel and then it gets pushed back to you and then you can reuse it again. So being able to get this balance in your channel, moving both back and forth, makes it such that you can make more payments with the same amount of Bitcoin because you’re reusing it — it’s getting pushed back and forth — which I think is one reason that you do the rebalancing, is because it got pushed to the other side and then you push it back, so someone else can push it again in the other direction. So you have a lot of payments, they’re going through the channel, and then they move through the channel, the balance moves the other side, and then it’s all on the other side so now we start sending payments in the other direction and it flows through that way, and then we send some payments back the other direction and it flows back that way. So it moves back and forth, and so you get to reuse the same Bitcoin for multiple payments, which is the gold standard goal of Lightning. Okay, so like I said earlier, rebalancing is sending payments yourself. So what if instead of me having to make these payments to myself to rebalance it and paying the cost of that — and when we’re talking about cost of running a Lightning node, if you’re paying money to rebalance your channels to reuse liquidity, then the amount of fees you’re charging to use that liquidity has to cover the cost of making the rebalance, so it’s a lot of cost-benefit analysis here. So what if, instead, we incentivize people on the Network to send payments on channels so it gets rebalanced? So instead of me having to do the rebalances myself, what if I figured out a way to hint to people that I would like this channel to be rebalanced so I don’t have to do it, but maybe someone else — if it’s actually worthwhile to them and useful, or I can incentivize them in some way to help me rebalance my channel so I as a node operator don’t have to do anything, but — someone, if it’s actually useful to them, will rebalance it for me? One way that we can do this, and this was actually a proposal by Clara Shikhelman — she works at Chaincode — we were talking at Miami last year and she’s like, Lisa, why don’t we have negative fee rates on Lightning? So I’m like, Okay, that’s a cool idea. So how do negative fees work? Well let’s walk through it: we have a node, usually the node has something advertise the rates for the capital that they have on their side of the channel. So then when a payment comes through — someone wants to make a payment — they’re trying to make a 100 sat payment, target goal at the final node they want that last node to get 100 sats, and this is their stated fee rate. We’re just going to pretend it’s 10 base fee and ignore the ppm part because that just makes my example really nice — in order to make a 100 sat payment at the end, you have to pay the node in the middle 110 sats because they’re charging 10 base fee. So this has to be worth 110 sats. So if I send this person 110 sats, they will send 100 sats to my target. This is normal fee rates — this is how Lightning works today, except ignore the 10 ppm thing. It’s just 10 base fees — that’s easy — 10 sats. So I just charged 10 sats — this is me making a 100 sat payment and getting paid 10 sats to do it — that’s how it happens in Lightning today. Okay, so how do negative fees work? What if I made a negative ppm — pretend it’s base fee, whatever. So instead of having to do 100 sats, now this person only has to send me 90 sats and I will push 100 sats as soon as I get 90 sats. So negative fee rate means that you can push me less money and I will on the other end push a larger amount. So that’s a negative fee rate. So you get a little bit of a discount to make a payment because I really wanted you to push some liquidity to the other side of the channel, so I’m willing to give you a discount on pushing that liquidity in exchange for the fact that you’re pushing the liquidity. That makes the channel more balanced. The problem with negative fees is that if you’ve got a lot of money in a channel, you probably don’t want to do all of the money in the channel at a negative fee rate, because then you would not make any money on your channel — you’d be paying people to route to your channel, and that would not be very economic of you at all. So suddenly you’ve got the question of like, How much of my total channel capacity should I make available at a negative fee rate? So if you have a lot of capacity, you probably want to put it on sale. When you have a lot of available capacity, you probably want it to be negative so more people will send payments to the other side. If I have a lot of capacity, I probably would want to put it on sale so people use my channel. However, as my channel starts getting used, I probably want to change my fee rate, so now I’m charging 10 parts per million sats, or whatever. So now it’s balanced — now I’m charging an actual fee rate so if you use it you actually charge me money, but then when I don’t have very much capacity at all I probably want to charge a large fee rate because that probably means that since it’s been used so much or has actually been moved over, then that’s probably pretty valuable liquidity at that point if it’s being used. So that way you end up paying more money on this side, which is cool. But you’ll notice though I’ve got a fee rate to push it this way — this guy on the other side probably is also going to have a fee rate that they set on their own stuff, so if they’re doing the opposite of what I’m doing, it would be negative on their side to send payments this way but really expensive on my side to send them their way. So if you go one direction on the graph you can actually make a payment for less than you actually have to put up to start it, whereas if you’re going the direction that’s expensive and there’s not a lot of liquidity, you actually have to pay more money to make a payment happen in that direction. So it incentivizes — with fee rates — payments moving in one direction versus the other, which is cool. A lot of capacity, put it on sale — less capacity, charge more for it. So it’d be really cool if your fee rates were dynamic by available capacity. The problem with negative fees though, at least the way that we currently do publish fee rates on Lightning, is you have one fee rate and it doesn’t matter how much capacity you have, that’s just the fee rate you charge. Negative fees, though, you don’t want to just put up a negative fee for the whole channel balance because that’s not a good idea — it could get drained before you had a chance to change it, etc. So instead, what if we introduce this idea of a rate card where we can say, Okay, so I have a channel and it’s going to be maybe in four different states during its lifetime: when you’ve got almost 100% of the capacity on my side, over half is on my side, under half, and then almost depleted. So we take it and we say, Okay, we can divide the capacity in your channel into four different segments, and then we just give them all a price. And what if everyone could just say — and then you can just publish this, this is your rate card — you say, Okay, if my capacity is super on my side, I’ll give you a discount. If it’s pretty much near the middle, I’m gonna charge a little bit. If it’s starting to get depleted, I’m gonna start charging you a little bit more. And then if I really don’t have as much in this channel, you’re gonna pay me a lot of money for that because this is probably a pretty expensive route, etc., and it might be one of the last payments I can make on this channel so you’re going to pay me for that capacity, etc. So what’s cool about this is now you have dynamic fee pricing of where the liquidity is in Lightning Network. Super-available capacity is at a discount, so moving payments in directions on channels such that it moves them back towards the middle — so making a payment on this channel is going to bring it closer to the middle, whereas making payments on channels that are unbalanced is very expensive. So all of a sudden, you’ve incentivized people who are making routes and making payments to either push channels back towards balanced or to only use pet channels that are already in the middle. So what this does as an incentive, economic model is it makes payments that are either difficult to make because there’s not a lot of available liquidity really expensive — so you’re getting paid for being on a very limited route, if that makes sense — so you automatically make more money if you’ve got capacity in a direction where there’s not a lot, so to speak. So this is the proposal. When I get the e-mail out, if you have better ideas about this you should definitely post them on the listserve. But the cool thing about this is that as an ecosystem of Lightning payments, now there is suddenly an incentive for someone to find routes with negative fee rates all the way through them. We make a payment — they’re (1) getting a discount, but (2) they’re also rebalancing all those channels that they flow through. So this makes Lightning more reliable because payments are going to naturally flow in places that push the network towards more balanced such that there are more balanced channels to make payments on. So what this is actually doing, this negative rate when you have a lot of capacity, it’s actually taking what you would have been spending on rebalancing, or attempting to rebalance, and externalizing that so that instead of you having to do the rebalances for yourself and finding your route through the graph back to yourself, now you’ve suddenly made it an external thing where you’re paying what you would have paid in those rebalance fees to anyone who’s able to find a rebalance path. And so with rebalancing, that is from the graph perspective of yourself in the network, and it makes it this mono-view — your availability and what is the economic route to do rebalancing from a single node point is very limited — by externalizing that to anyone in the graph who can see it, basically you make it such that anyone can do the rebalance for you, they just have to be able to find the negative thing in the graph, and maybe for their perspective or where they are located in the graph, making a negative payment actually makes sense for them, whereas for you it wouldn’t because of what your location is. We make a rebalancing, so you would have paid a cost to rebalance — now you pay a cost to rebalance to anyone who’s able to make the payment instead of to the people that have the liquidity that you’re pushing it through. Okay, so then a question you get is: Doesn’t this leak my channel balance? Because if someone tries to make a payment at a certain rate but that’s not available, don’t I have to tell them where my current thing is? The answer is, Yes, it leaks your channel balance — within a bucket. So people will know, Hey, my channel balance is in a range, but you don’t leak exactly what it is. So right now people can probe your channel balance, anyway. This is definitely giving them a hint of where you are, but you’re making a trade-off of: you leak a very coarse idea of where your balance is, but the trade-off of that is that people will be paying you more when you have less, sort of thing. So it gives you a little bit more control of ability to price your liquidity over the lifetime of where it is and how much it’s worth, but for the trade-off of: you now have this very coarse information that you’re leaking when someone tries to make a payment and you’re like, Okay, you didn’t pay enough in fees because I don’t have that much liquidity, so if you want this payment to go through you need to pay more in fees for this thing. Another question I got last week at the Lightning spec meeting is: Well, doesn’t this make payments more unreliable? Because if I just keep trying to make it the negative fee rate and that’s not available, it’ll keep failing? And the answer is, Yes. However, if you’re trying to make a payment and you want it to be reliable, you can guess a higher fee rate and just pay the higher fee rate out of the bag, and so you pay for the higher fee rate. So if you’re paying through let’s say four channels — you don’t know what the liquidity situation is on each of those four channels — you can make a reasonable guess that they’re maybe up to 25% available, so you could pay the third payment bracket and your payment will succeed as long as it isn’t more than 25% depleted or whatever, if that makes sense. So you can pick before, without even knowing anything about it — if speed matters to you, you can choose to pay a little bit more, and it’s more likely to go through. Whereas if you’ve got some thing where you’re just trying to see if you can make money rebalancing channels, you can have a lot of payment failures by trying to make payments at lower rates by finding negative routes through the graph, and that could just be a thing that you do without having to actually trust that it’ll make it through. Or maybe you keep trying at lower rates and your payments fail and maybe you don’t care if the payments fail — maybe you’re not trying to make the Lightning payment today and it’s like an eventually thing. So this will definitely make more traffic on Lightning, which I think is probably good for privacy because of more payments going through and more stuff happening is good for everyone because there’s just a lot more balances moving in a lot of directions for reasons that no one knows whether you’re actually making a payment or trying to do some sort of arb on negative fee channels. But now all those negative fee payments that are getting made are actually helping keep the Lightning Network more balanced, because they’re moving in the opposite way. So what is the state of this project proposal? Again, I’m calling it pre-spec, which means I have proposed it at a meeting with a lot of Lightning spec people, and everyone was like, That sounds like a very reasonable idea. So now I’m just gonna write it up and implement it in Core Lightning, and the nice thing about this is it’s not super-complicated to implement. What I’m proposing is that you start advertising information on your node — that’s not something that’s super-complicated to do. What is complicated about it is how to use that information once it’s public, so the second stage of this would be to update your routing algorithm so that they use it or to start taking advantage of this information to try to find negative fee routes so that you get to make discounted payments on Lightning. But we can start publishing the information without having to change any of the routing stuff. So hopefully — fingers crossed — this will be done in two weeks, and maybe we’ll get it in the next Core Lightning release but don’t count on it beyond that. I have a few minutes for questions.

Q: If I’m trying to basically probe in order to figure out what the fee rate is, how does this affect the traffic on the Lightning Network? Because for example in Solana, they do all these transactions per second, but the transactions was just this automated army. So what’s going to be the effect of this if you have just these bots trying to do the negative fee rebalancing continuously?

Lisa Neigut: You’re going to have a lot of traffic on Lightning and there’ll be a lot of payments happening, but I mean the arbs will stop — I don’t know if they’ll stop, but — as soon as the channels are balanced, there won’t be any more places for them to run payments. Yeah, I would assume there would be more traffic. There’s gonna be more probe stuff looking for these routes. So the trade-off there, though — so on Solana, I don’t know what the benefit of having all those bots running is, but one of the benefits of having the bots running on Lightning is it should make it more reliable for people trying to use it, because when the arbs run on Lightning they’re actually pushing the channels toward the middle, which means that payment in either direction is more likely to succeed. Again, the cool thing about the rate card thing is you don’t have to set negative fees if you don’t want to — it’s now an option — it’s not like you have to. I think there are certain situations where you’re running a routing node, for example, that having negative fees like this on both sides really incentivizes the whole rebalancing thing. However, if you are a channel that runs a node and you expect that node to basically always ever be in one direction, this might not make sense as a sensible strategy for setting your node balance that way. I mean, this is a thing that you can do and not a thing you have to do, but making it available I think makes them really interesting opportunities in terms of improving reliability for the network.

Q: And then for the fee rate, for the rate card, when I initially open the channel, I can also set the rate card so it wasn’t gossiping that this new channel open has a rate card with this [inaudible]?

Lisa Neigut: Yeah, so you would be able to update it whenever you want. So one of the downsides of the current way that we advertise price of a channel is that you get two numbers — you get a price for part per per million and you get a base fee, and that anytime you want to change that you have to issue a new gossip message. So if you wanted to do what rate cards is proposing and change how much you’re charging based on your capacity changes, you can do it today, but that would require you to be sending out new gossip updates every time your channel balanced stuff — you wouldn’t have to tell anyone you’re doing it, and I think right now, even, some people do update their channel costs pretty regularly, and that is expensive in terms of bandwidth on the network for gossip. Also it’s not very reliable — gossip is not the most reliable mechanism, so one of the goals of this rate card design is that we minimize the number of updates that you have to make to your channel rate by being able to publish a set of them all at once. So ideally you’d figure out what is good for you for the next two weeks or whatever and you publish a single rate card, and then hopefully that’s granular enough information that you can get the right pricing on your liquidity to not have to update it. So hopefully this minimizes the amount of gossip updates that you’re making on your channel stuff by giving you more granularity in what you’re pricing.

Q: [inaudible 56:01]?

Lisa Neigut: Yeah, so you will publish your old one, and then you’d also attach some extra information in the gossip — which is the rate card stuff — and anyone who understands what the rate cards are would be able to read it and take advantage of it. So I kind of lied — there’s two things you have to change about a node to make this useful: one is you have to start publishing it and make it such that people can publish it, the other thing is you have to make it such that your channels understand the relationship between what the rate card is currently and a current payment that’s being paid, and then you just reject it if it’s not in the bucket that you expect. But what you would do for that is you’d set your legacy or your old version to the highest one on your list. How they interact might be a little sketchy — not sketchy, but there’s a possibility that you would be like, Okay, my old one will just set to this 10ppm one — the old one — and then that would work for whatever percent of payments, and like for three-quarters of my liquidity, payments will work using the old published fee rate if I use this one, but if my channel liquidity is really low I will reject all those payments because they’re not paying the highest rate that I’ve published on my rate card — that’s probably fine.

Q: [inaudible 57:30]?

Lisa Neigut: Yeah, so Minisketch is a way of making gossip updates happen faster. Minisketch is a minification of the amount of information that you need to share to figure out what new updates you need to send between each-other — this is an attempt to cut down the amount of new information that’s being published, so this is reducing the total number of new gossip updates that need to be transmitted across the whole network. So Minisketch — if you publish new information — because of the way gossip works, technically that has to be sent to every other node on the network. So by cutting down the amount of new information that gets published, you reduce the amount of bandwidth on everyone’s Lightning node. So hopefully this will cut a lot of the bandwidth that gossip uses because you can do more condensed information — that’s the thought. It’s an experiment. It’ll be useful — maybe it won’t.

Q: Would this allow large routing nodes, their channels, to actually up their fees [inaudible 58:37]?

Lisa Neigut: Yes.

Q: So could that over time create a control structure?

Lisa Neigut: What do you mean by control structure?

Q: So they would have more power. There would be nodes where then everyone would want to route it through [them].

Lisa Neigut: But isn’t that public information about where the negative things are? And wouldn’t that incentivize people to open channels in places where they can earn more fees because it’s profitable to? So the idea is that by allowing people to have better signals about where liquidity is, it allows — in theory, then — the deployment or redeployment of existing capital to places where payments will be more reliable and cheaper for everyone, because ideally all of those expensive or negative things will get arbed out in a way such that it’s just balanced and payments can move through it. And the cool thing about this is the amount you have to pay changes based on the traffic in that direction, so high-traffic routes will hopefully be more in the middle, because as soon as they get unbalanced, it’ll get pushed back the other way. This is the thought.

Q: This is really cool. I love that it incentivizes Lightning liquidity providers rather than — it’s socialized profits for Lightning Network providers rather than just mining. Just because we were talking about splicing yesterday: Do you see splicing coming in adversarially, game theory-wise, where someone could add a bunch of liquidity and get a negative rate somehow adversarially?

Lisa Neigut: I haven’t thought about it that hard, but the cool thing about splicing is it lets you do more real-time reallocation of capital so that if there was the opportunity to — basically, you’re probably going to want to put money where it’s earning high fees for other people either so you can undercut them or figure out how to make your liquidity in a place so that people have to pay more. So ideally you’d probably want to put your capital in places where people are going to pay you more for it, but once you do that, that makes an opportunity for someone to undercut you by putting more liquidity in that place. So splicing makes it easier to redeploy capital to different places. This makes it such that the pricing of capacity is more dynamic, which gives you better signals, hopefully, about where to put the capacity with the now new splicing capability to re-allocate it.

Q: Yeah and there’s a 6-block wait so that people could be adding and changing my balance.

Lisa Neigut: Yeah. Maybe this will ruin everything and Lightning will totally stop working and it’ll be a really fun experiment, but I don’t think so — I think that this incentivizes channels to hang out in the middle. Maybe that’s fine — maybe that’s what we want? Maybe that’ll make payments more reliable? It definitely makes some of the stuff that René’s been doing — the problem with the stuff René’s been doing is: when channels get depleted, are people incentivized to make these channels workable again? Or is there an incentive to get people to make it such that there’s liquidity for payments to continue flowing? And I think that this helps with that. Okay, so at some point soon someone will be writing up a spec for this — probably me. I think Z-man already put out a whole thing on the mailing list about it — he thought it was cool. Great, thanks everyone.