I'm going to talk about high-level incentive problems in the Lighting Network.

The first thing to think about is that we have two different mechanisms for making Bitcoin and lightning work. One mechanism is math — If you do a SHA 256 of something you don't have to worry about incentives, whether that's going to match to the expected result. There's no incentive there.

So the problem is we can't build a system that is completely based on math. That's a problem that started with the Bitcoin solution, that we're going to introduce this kind of workaround for determining...to prevent double spending, and we're going to create this incentive system to prevent that from happening. And if we could come up with a totally logical mathematical solution we should instantly get rid of this proof of work incentive system because a logical solution would be better. The more incentive based it is, depending on the strength of the incentive, it becomes weaker if it's just incentives and stronger if it's more math based.

And in lightning we really have to think about a lot of different incentives, and we have to think about them from two sides — Everything has a cost or a benefit. So with lightning as an overall network, we have all of these different components that we're introducing. So we have the CSV delays, like "how long before I get my money back” and that could be also the CLTV delays.

We have hardware costs like running a routing node. We have capital costs of funding channels with people. We have chain fees like in order to create channels you have to pay a chain fee (everyone puts down a chain fee) and then we have to compare those against the benefits. The number one benefit maybe is to get to buy stuff. So, that's pretty cool but I also have some other benefits, like running a routing node I get some routing fees. Or capital itself being allocated is kind of like a benefit. So if somebody's allocated a lot of capital towards my node I now have the ability to receive. So that itself is kind of like an asset.

And I could also think about it in reverse, so I've assigned my capital to very good nodes, and now I have great outbound liquidity; that's also kind of an asset that I can acquire. And there's trade-offs between the costs and the benefits and then there's some things that are in the middle. So there's altruism, maybe I just want to support the network. Maybe I just want to play around with it and see what it's like, or you know, gather data, or maybe build myself up for a future where I anticipate getting more benefits.

So the number one incentive to think about, like the key incentive problem I think for lightning is this capital requirement. To narrow down on it, I have this capital cost — I have to get the money, to put it out there in an addressable node, I have to rent this node, I need to pay chain fees to establish my node, and then I can get some specific benefits from that, so I can maybe get some data about how well are my payments succeeding, or how well am I routing.

I can get that fun, I can get that good experience of operating a routing node, and seeing if I can route the most payments of anybody in the world, and I can get directly paid, I can maybe sell my capital, so people want that inbound liquidity so I can just like kind of say you know this month I'll assign my capital to you and then the normal benefit for your capital cost is that you get to buy stuff.

I want to kind of drill in on this problem of capital assignment, to like highlight all the problems with capital assignment. So, I make a channel with somebody else in the network. We have a system where we have a unilateral funding — So whenever you create a channel, the funds start on your side and then they can flow over to the other side. What would happen if we had a system where everybody could equally contribute capital?

Well, somebody like LNBIG could come in and just get all of the capital from everybody in the network allocated to them, and that might not be what people want to select. A unilateral capital assignment gives people a lot of control over where they want their capital to be assigned.

So here are some problems like with even opening up the channel to somebody, like why you wouldn't want to do it. So opening up a channel, there’s a certain amount of capital assigned, like a certain amount of bitcoins and the more bitcoins you have in your wallet the more risk there is if something goes wrong with your hot wallet. There's some risk factor there.

So let's say I have five bitcoins and I take one of those bitcoins and I assign it in a channel towards you, and you go offline. Now assuming we're all networked together, only four of my bitcoins are now spendable. So there is some risk that you reduce the utility of my coins.

Another problem is that there's a marketplace kind of developing for this liquidity. So, I have five bitcoins, and I assign it to five different people but then I notice, "oh there's people paying for this liquidity.” So you're not paying me anything, and somebody else over here is paying something, so why don't I bring down my channel towards you (who are paying nothing) and assign it over to them, and they'll give me some money?

So there's opportunity cost to assign this liquidity and that applies even if you don't assume this capital market for people who are willing to pay for channels. You could say, well maybe I could get better routing fees somewhere else. You are not really using this channel and that's actually kind of like the healthy mode of the network is that people are somewhat assigning capital in somewhat the correct positions for payments to actually move across those.

Then I also have another problem where if you go offline and then I need my money back I potentially have to wait for a time lock period. So some percentage of my coins I have this risk maybe they're going to be locked up for weeks potentially. These are all the reasons why you wouldn't want to assign capital to somebody else. It seems like we have a good solution in this unilateral system where you choose who to assign your capital to so other people can't just come and introduce these costs to you. You have to take on these costs yourself. But if you think about people who have routing sinks, who already have some inbound liquidity or has someone else deal with liquidity, every time somebody makes the channel with you, even though the funds are not on your side, so you don't take on these risks in the beginning, if they pay through you to somebody else now the funds move to your side.

Even accepting channels from other people and introducing all these risks to you. Your defense against this is to set a routing fee basically. You don't have to let them move out all the funds over. So it's something to think about because the default mode right now is to just allow anybody to connect you, assign capital and move their capital through you and there's not a huge amount of sophistication about that right now.

Another thing to think about that's fundamental as an incentive problem is that lighting really depends on the layer one security model. Layer one security model fails, well all the assumptions that you made in lightning don't work.

We have all these time locks right? Let's say somebody broadcasts an out-of-date state of the channel. We have the assumption that, oh there's a certain amount of blocks I can have and I’m going to be able to broadcast this justice transaction and that's going to move the funds back to me to punish them for broadcasting this out-of-date state.

But in Bitcoin or you know any chain that can be reorged you can actually remove transactions from the chain. This especially applies to if you're trying to deploy lightning on a weak chain. There are certain chains out there where you can carry out very long reorgs. If you're not careful with your time locks in your construction of your channels and you say, oh you know always after six confirmations it will never be replaced, so just make sure that I had six confirmations to do the justice transaction. On a lot of different chains there's not enough proof of work to make that very secure so you could potentially lose money just based on the layer one assumptions being broken.

Another fundamental risk and benefit to think about is when you're forwarding transactions on Bitcoin which is an expensive network. Every HTLC that you get in it's a potential contract that could go to chain right? That's how you could get that money if something goes wrong. But going to chain actually has a cost. You actually don't really know who you're dealing with, so you don't actually know the source of somebody sending you an HTLC. Anybody could have been the originator of an HTLC to you. You get an HTLC and maybe it's for 150 satoshi's. You say oh well 150 satoshi's, I'm going to charge one satoshi. You know I'm a nice guy. I'm not going to charge too much in routing fees. So you charge one satoshi and then what happens is this HTLC, something goes wrong down the route and maybe your peers go offline or something.

At this point you need to go to the chain. Maybe they go to the chain. So technically you're still covered right? It's not like they can't just arbitrarily take money from you but there's all this hassle of going to the chain. The channel’s going to be dead. You're now going to have to have to sweep this out and move it into a new channel. So there's a lot of cost associated potentially with any HTLC that you move along. And what's the benefit? The benefit could just be one satoshi. You want to be careful about how you structure those incentives. Maybe you want to set up on your node like a minimum amount of fees to justify it. But there's this fundamental risk here which is every time you send this route you're taking it on this kind of risk that it does go to chain you have to pay this cost. In practice I don't think it's a major deal because of the incentives there's no huge incentive to make it fail but it potentially is a problem.

Reputation is difficult with this because you don't know who the sender is. If your peer closes you can think "oh they did something wrong.” In that case then you could say "I'm gonna avoid them again,” but they could also spin up a new node. So it's just a fundamental problem to think about. It's a limitation, so another thing to think about. This goes back to this reputation question. So every time you send out a payment, you send it out on the network, and it's all encrypted and stuff. What happens if the payment fails? There's a specific point in the route where it fails and then it fails back to you. And what's included in that message is the failure reason and it includes the originator of the failure, so I know kind of where it fails. I have an idea of where it failed and why. And so what we do with that information is we use it when we choose the next route.

So we try a route and it fails, and then we try another route and it fails. And if the target is not well connected, you could try 100 routes, I think by default we'll stop after like a minute of trying routes. But one thing to think about is these errors are kind of like voluntary so they're more for debugging than they are for modeled after incentives. In the spec there's not even really like a thing that you definitely have to do when you receive these errors. It's kind of your own choice of "how do I want to react to this error.” So we need to think about the incentive to return a correct error because maybe the node is gonna lie. And so an example of that would be like let's say that there's a fee insufficient error. So a fee insufficient error means that "oh your routing fee is too low, I advertised a fee of $1 and you gave me 50 cents, so I reject it.” But which side is at fault? Maybe the sender didn't send enough money, but maybe the receiver was contradicting their own advertisement, or you didn't see the advertisement.

So it's hard to know who's at fault in every single situation and we have to think that when we develop the pathfinding logic. We don't want to incentivize people to lie about what happened, try to cast blame somewhere else. Maybe they're gonna blow up the error, they're gonna say "I don't want you to even really have an idea that I had anything to do with this error because I want you to try me again in future payments.” So we need to be careful about how we implement this pathfinding, which can vary from wall to wall.

Watchtower is another interesting incentive problem. So that's something that we've just rolled out in LND. We have this Watchtower feature that you can turn on and it's designed to work against your own node, so we call it altruistic watchtowers. Let's say you tried to set up the altruistic watch tower as it is right now on the network. What could happen to you? Well, the way that watch towers work is they are kind of like they're holding these justice transactions in reserve so whenever they see something funny going on, on the blockchain they decrypt their store of justice transactions and they say "okay it's my time to shine, now I'm going to help you and broadcast this justice transaction that I've stored up.” But that means that you're actually having to give them these justice transactions, so they're building up a database of more and more of these justice transactions and they're scanning the database versus a chain to see if there's any unlocked keys it can unlock these justice transactions. Each transaction is like a real transaction. It’s a Bitcoin transaction, so it's maybe like two hundred bytes or something like that. So every time you just open up this altruistic Watchtower to everybody to use on the network, unless you've got some kind of identity from them, they could just give you tons and tons and tons of different transaction states and you don't know if they correspond to anything. Because every time you do an update with the channel peer, you're generating a new commitment transaction, you’re generating a new potential justice transaction.

So that's kind of the problem with just doing completely altruistic watch towers that are open to everybody. So we need kind of like an incentive model to say why should I have this database that's being filled and filled with more and more of these, you know, somewhat small transactions individually, but potentially millions of transactions.

So there's two kinds of reward models that I've heard about for watchtowers and one is that you could design a watchtower so that if there were a breach that one of the outputs would give the money to the watchtower. That would kind of be an incentive to be a great watchtower because the way you would get paid is by doing your job of punishing the people who, you know, are trying stuff. But it's complicated to do it and the bigger problem is there's hardly any breaches at all.

So like my node has had thousands of channels on its lifetime and the punishment for breaching is so severe that the benefit is so limited that,

Audience Member asks a question

Alex: Potentially, but at the moment it doesn't seem to make so much sense because it's just not that much breaching going on. Another model for watchtowers is more like what we're going along the lines of is kind of just having reliable watchtowers that I just pay them for kind of like their space and their time. That system can still be fairly private. We can use kind of like finding signatures to generate you know like so that you can't keep track of who I am. That's pretty important if you just have like these broad watchtowers to the world because you don't want your Watchtower to know that to be your peer as well right otherwise it's watching itself. So that's what we're thinking about as far as to deal with the problem of like why should I run a watchtower for people you would pay just straight.

Okay I have a bunch of grab bag problems, incentive problems

One issue in the urn is the network. If you think about routing nodes as service providers, they can have two types of "customers”: Firstly, a "customer” who has a mobile wallet. This mobile wallet is essentially one sided as we can't really route through them. Secondly, the "customer” may be another routing node. I can wrap back through such a node, so if I receive money I can push it out back through them. But in lightning we only have one type of fee, We have a fee that is based on outgoing from a channel. We don't have a type of fee that's based on incoming, so whenever one of these private channels potentially takes my money offline, who potentially I have to pay on-chain to get it back. Whenever they use my liquidity they pay the same amount as that very well connected routing node that I can always pay through them.

My connection to them is worth a lot as it is always available. I'm not going to go to chain because maybe I have a long-standing reputation with them. So we have kind of a missing piece in the way the fees are described.

Audience Member asks a question

It makes more sense to start simple: if you add pairwise fees between every set of peers, or maybe between every set of channels, you'd have an explosion. It’s something we have to think about. Another solution that we’re working on is channel acceptance policies: Current nodes talk to all other nodes, but you don't have to accept a channel from anybody.

Say I had two types of nodes: I have one type where I classify all of my inbound to be the same type of person, so it makes sense then that they all have the same type of outbound. Then I have another type of node which has all. I only allow channel channels from people who are well connected and then I charge them a different class of fees because the liquidity is worth a different amount. It's just something that we have to think about more as more of this differentiation in the network appears, if this happens.

Another issue that's being worked on is the way that on-chain fees are paid. Let's say I have a channel with you, you initiated the channel and I want to close the channel. Maybe I went to LNBIG and I said "LNBIG please give me a channel” and LNBIG opened up a channel to me. So now I want my funds back on chain. Let’s say I want to get them back right away.

Well, I have all the cards here because as the initiator is paying into that commitment transaction fee, all I really need them to do is to broadcast that commitment transaction and then the funds go into the remote output and I can spend them unilaterally. Maybe I can negotiate with them and say "let's cooperatively close to be cheap” but I'm in a really good negotiating position because all I have to do is get them to broadcast a commitment transaction. In the future this will be addressed to some degree with the addition of time locks on both sides. Right now the remote output doesn't constrain your funds, it just says "go to a standard key”, but it's something to think about in the current setup. Maybe LNBIG should think about that.

Another incentive problem is that failures are free in the network. If I send a failed PLC through you, that consumes some of your, that costs youI lock up some of your funds and that's a cost to you. If to take your funds you have to hold one of your output slots open for the HTLC and then the payment fails. What did you get out of it? You got nothing because you only get paid the routing fees when the payment succeeds.

In Bitcoin the mechanism says you always pay if you broadcast. If something enters the mempool and its cost is paid by somebody else they have to pay that fee, otherwise they're not allowed into the mempool. That's how the mempool fee is designed to work, but we don't have the same concept in lightning at the moment, i.e. the concept of always having to pay if you do something that incurs cost on somebody else.

Another thing to think about is that we have this method of backups called static channel backups in LND. The way that it works is you retain a file that is updated whenever you make a channel. This file contains information about how to get back in touch with another node on the network. The idea is if you lose your entire database you lose all your information but you still have this way to get in touch with the peer and information about the channel. You could reach out to them. You could then say "I need you to force close this channel” since they have the latest up-to-date version of the channel. Once it goes back to chain you’re going to be able to use your mnemonic. Also the peer is going to supply you with a little bit of data about the to-remote output or just a general commitment transaction that will allow you to sweep all my funds back.

That's how our current system works: if you lost your database, as long as you have the channel back up and as long as you can connect to that peer and the peer is complying with the data loss protection protocol, you can use that information to sweep back your funds. But there are certain problems with it. One problem is that they could use the information that you've lost your data and try to breach you. We can kind of counteract that problem with watchtowers. If you have your state backed up with a watchtower, your counterparty can't really try that, plus they don't know if you're trying something on them.

Maybe you’re trying to goose them into publishing a bad state so another problem is not everybody has to use the data loss protection so LND now will actually refuse to connect anybody who doesn't do data loss protection if they don't signal it. Another problem though is what if you signal it but you don't do it exactly in the same way that we expect it to work? So potentially you've already force closed the channel by the time that I come and ask for the channel to be force closed. In that case I would hope that you would have retained the state about the channel so that it will allow me to sweep back my funds but once you force close the channel like your whole entire relationship with this channel is dead now so why not just delete the information well and the way that the commitment transactions are designed is that there's a nonce that goes into the keys in the commitment transaction. And even though the to remote output is paying to normal public key is paying to a normal public key that's that's combined with this nonce that runs through the entire commitment transaction and so you're not able to even with all the information about the channel like and you can see that there's this one simple public key constraint output you won't be able to sweep it back and less the channel partner gives you back that random number. So we need to think about how we make that more of a standard or you know make sure that people are like keeping that around. Also that there we need to make sure that nodes are connected well again if we want the static panel backup system to work well.

Okay this is my last slide. I heard a lot of people talking about rebalancing so people have this in their mind like okay my channel gets unbalanced and then what I'm going to do is I'm going to rebalance it. A lot of people have in their mind that a great way to rebalance would be to do it off chain. I don't want to do on chain stuff. I just want to keep it all off chain because it’s cheap. I kind of just want to run through what it means to do octane rebalancing.

Let's say that you have two nodes: you have node A and node B and they're starting at the initial state and you can see no where they've run out of their liquidity. But node a has as good liquidity. Well rebalancing is actually if you do it off chain what you're doing is you're actually taking liquidity from somebody else and assigning it to yourself. This is kind of like an incentive problem potentially because what if my fee rate to go to the store is a hundred and somebody else's fee rate to go to the store is one and I detect that well is this there's a limited number of people who have these candles to the store. Also assume that there's liquidity from the store so I am the person who has zero liquidity and so assume if the store can pay it to me and then also assume that I can pay it to A, the node that does have liquidity. So what I'm gonna do is I'm going to initiate a rebalance.

So what I do is as node B I pay to A and I have A pay to the store and I have the store pay to me. That's what an off chain rebalance is. You can see in this state and now I have the liquidity and the other the other guy he has no liquidity and now I'm in a pretty good position because every time somebody tries to go through that cheap route that one one satoshi cost route they're going to hit that wall of zero and they're gonna have no liquidity and it's gonna fail. Then they're gonna have to retry and then they're going to come to me and I'm gonna say oh great I got some liquidity for you but it's going to cost you a hundred times what it cost you before and you also have to think that like information isn't like perfectly distributed so you could say like a solution to this would be, "oh well the market will realize that there's this like this market opportunity here. Everybody will want to like pile on to the store more liquidity because you know they'll want to undercut that 100 person peak per person.” But information is not like we're designing a private system; nobody can really see what's going on.

So you don't know who's doing a lot of business by design. Potentially you're marketizing that information and you're marketizing the liquidity itself. The reaction that I would suggest, which would be a good reaction, is for people to set their fees such that if they get depleted they now have enough from routing fees to reassign capital so they can continue to make that channel work. But it requires that the routing fees have to be connected to the chain fees and you have to be proactive about it. A lot of times people set up these channels and they say "Oh I'm gonna help the network" and they say "I'm going to set my fees at zero". Then as soon as the channel gets depleted they're like "Oh that Raspberry Pi in the corner... It's not doing any routing, I'll complain on Twitter or something". So we have to think about ways where the network can kind of be more reactive and that when somebody depletes you, you have an incentive to make the situation more balanced.

somebody else and assigning it to yourself. This is kind of like an incentive problem potentially because what if my fee rate to go to the store is a hundred and somebody else's fee rate to go to the store is one and I detect that well is this there's a limited number of people who have these candles to the store. Also assume that there's liquidity from the store so I am the person who has zero liquidity and so assume if the store can pay it to me and then also assume that I can pay it to A, the node that does have liquidity. So what I'm gonna do is I'm going to initiate a rebalance.

So what I do is as node B I pay to A and I have A pay to the store and I have the store pay to me. That's what an off chain rebalance is. You can see in this state and now I have the liquidity and the other the other guy he has no liquidity and now I'm in a pretty good position because every time somebody tries to go through that cheap route that one one satoshi cost route they're going to hit that wall of zero and they're gonna have no liquidity and it's gonna fail. Then they're gonna have to retry and then they're going to come to me and I'm gonna say oh great I got some liquidity for you but it's going to cost you a hundred times what it cost you before and you also have to think that like information isn't like perfectly distributed so you could say like a solution to this would be, 'oh well the market will realize that there's this like this market opportunity here. Everybody will want to like pile on to the store more liquidity because you know they'll want to undercut that 100 person peak per person.' But information is not like we're designing a private system; nobody can really see what's going on.

So you don't know who's doing a lot of business by design. Potentially you're marketizing that information and you're marketizing the liquidity itself. The reaction that I would suggest, which would be a good reaction, is for people to set their fees such that if they get depleted they now have enough from routing fees to reassign capital so they can continue to make that channel work. But it requires that the routing fees have to be connected to the chain fees and you have to be proactive about it. A lot of times people set up these channels and they say 'Oh I'm gonna help the network' and they say 'I'm going to set my fees at zero'. Then as soon as the channel gets depleted they're like 'Oh that Raspberry Pi in the corner... It's not doing any routing, I'll complain on Twitter or something'. So we have to think about ways where the network can kind of be more reactive and that when somebody depletes you, you have an incentive to make the situation more balanced.