I might be wrong, but it seems to me that channel balancing through fees has some significant downsides. Let me try to explain them.
I personally witnessed a situation where I tried to make a payment from a mobile wallet and couldn't do it. The route went through my nodes. I started checking the logs and found that when the wallet sent the payment, it used fee parameters that were in the network graph several hours earlier. They were later changed to higher ones as liquidity decreased. At that time, I had an algorithm where if my channel's liquidity got depleted, the price would increase. For this reason, the payment couldn't go further. The sender's wallet used a lower fee because it saw that in the network graph, which didn't relay fresh data well due to the protocol's significant delay. Theoretically, when a payment doesn't go through due to fees, the intermediate node where it fails forms a response and sends new fees in that response. Upon receiving such a packet, the sender's wallet should, in theory, adjust the fees and resend it. Then, the payment would go through. But this doesn't always happen. It may be a bug in the system implementation or other reasons I can't fully understand. But at that time, I concluded that if I had fixed fees, that payment case would've succeeded, as the liquidity still allowed it.
Then it occurred to me that balancing channels based on such a scheme—setting low fees when you have a lot of liquidity and high fees when it depletes—creates a sort of logical contradiction. When you could earn from fees with your bitcoins locked on your side, with this algorithm, you earn very little while your bitcoins are locked and available. When the channel depletes and you have fewer locked bitcoins, you need to increase the fee. This makes it unlikely that you'll earn more than when you had funds in the channel. It all seemed somewhat illogical. Therefore, I thought it would be better to just set a fixed fee. After all, when the channel depletes, adjusting fees only signals to future senders that we can't process a large payment through this channel. We financially discourage them from sending through us. But there are other ways to avoid losing profit (since higher fees often encourage senders not to use your channel at all). For example, if we lack funds in a channel and someone tries to send through it, our Lightning Network server would simply send a packet to the sender indicating that funds can't be sent through this channel temporarily.
Login to reply
Replies (2)
Interesting. The first think you are discussing ... "The sender's wallet used a lower fee because it saw that in the network graph, which didn't relay fresh data well due to the protocol's significant delay. " -- this is something I've seen a lot on the Lightning Network, but I've never seen it quantified. But anecdotally, there do seem to be nodes that are used to for payments which often "cache" old fee information from the network. My assumption is that many might be mobile clients with poor connectivity. It's actually for this reason that none of our nodes use "fast" automatic fee changes ... my experience is that you shouldn't change fees more than maybe once or twice a week for any given channel, because of this "caching" behavior. I've also seen attempted payments which are clearly using fee information that is several days out-of-date.
Regarding this second issue, you write: "our Lightning Network server would simply send a packet to the sender indicating that funds can't be sent through this channel temporarily." Do you mean like with LND's "updatechanstatus" API? .... if so, wouldn't this prevent your depleting channel from "refilling" from the other side? Or maybe you are referring to a different strategy?
UpdateChanStatus | Lightning Labs API Reference
UpdateChanStatus attempts to manually set the state of a channel
Regarding your last question, I meant that the Lightning Network protocol includes an onion packet type, when a payment fails due to insufficient balance. It needs to be pushed further. Then the intermediate node on the route sends back an onion to the sender containing an error code indicating that the channel temporarily cannot send the payment due to fee changes. It also specifies the new fees in the same onion. I haven't looked at it right now, I don't have the protocol on hand, but it's definitely there. And it's described somewhere in the Bolt specifications.