A Few Ways We Can Upgrade Lightning Network Payment Routing

In order to develop into a protocol usable by the entire world, certain scaling improvements for Lightning need to be considered.

The Lightning Network is a well-developed, fast-growing, Layer 2 transaction solution on the Bitcoin network. More and more services and exchanges are integrating it, the liquidity available for routing payments is growing, and more applications and ways for users to interact with it are being developed each year. It also has many problems to overcome in the long run: 

• The scalability limits how many channels can be opened or closed on-chain at a time.
• There’s an issue with the minimum size Hash Time Locked Contract (HTLC) increasing as on-chain fees also increase, because it has to be economical to settle.
• There are also a slew of privacy issues.

One major issue that is frequently discussed is the liquidity requirements for routing payments. In order to successfully route a payment, there has to be a link of channels, all the way from the sender to the receiver that has enough liquidity on the right side of the channel to be able to pass the payment along. This makes the decision of where to deploy your coins on the network a very important one. It also means that the overall amount of liquidity people are willing to deploy is a sort of upper limit on how much value the network can process.

Ultimately, what this comes down to is, when you open a channel, you are deciding to lock that money up so that it can only be used to route payments to that channel partner, and whoever they are connected to on the graph. Yes, ultimately the idea of the Lightning Network is that, by making enough hops you can find a connection to almost anywhere. However, the reality is that if someone else can accomplish routing a payment to a destination using less hops than you can, that is the path that will most likely be selected to route the payment. Lightning already requires overcollateralization to a large degree, i.e., to route a 1 BTC payment across 10 hops requires 10 BTC of collateral to be locked into payment channels along that route. The competition over having good connections to make routing revenue exacerbates this by incentivizing even more redundant collateralization.

This is a problem resulting from the fact that Lightning channels are two-party “tubes” that can just push value back and forth in those two directions. Here’s the thing though: The problem is kind of an imaginary one. Payments on Lightning use HTLCs, a script in a Bitcoin output that says one person can claim the output and spend it by revealing the preimage to a hash, or another person can claim the output and spend it after waiting for a timelock to expire. This is a general script that can be applied on-chain, in Lightning channels, on top of statechains, on sidechains, etc. As long as you can utilize an HTLC, in theory, anything can participate in routing a Lightning payment.

Statechains

A statechain is effectively something like a Lightning channel, except you can transfer ownership of the whole channel entirely off-chain. Their trust model is dependent on the operator (which can be a federation) of the statechain refusing to collude with past owners and steal the statechain from the current owner. It is not as trustless as a Lightning channel, but it is much more flexible as the ownership can be passed around without having to perform an on-chain transaction. Given that statechains are based on pre-signed transactions off-chain, you can add HTLCs to them.

This allows them to be used to optimize the efficiency of routing payments on Lightning by allowing node operators to reassign liquidity on the fly off-chain. Instead of having to open channels and sink liquidity in them to be well connected ahead of time, their funds can be dynamically reassigned on the fly off-chain in response to shifting demand to places they are not connected to (or not connected well enough to). The only requirement is that the other party wants to shift liquidity to trusting the statechain operator.

Sidechains

Sidechains can implement any arbitrary rules they want. Block times can be different, block sizes can be different, anything can be changed. The only catch currently is that to move your Bitcoin to a sidechain, you have to trust a federation that custodies the funds on the main chain. You can apply HTLCs on a sidechain that uses Bitcoin’s scripting system; you can have a more Ethereum-like scripting system that lets dozens of people share an account that splits balances and updates them according to whether an HTLC succeeds or fails; you can do anything. As long as the blockchain supports conditionally giving money to one party if they produce a hash, and the other party after a timelock expires, they can help route Lightning payments. Other blockchains can experiment with ways to make liquidity allocation more efficient than the main Bitcoin blockchain. You can even just do something as basic as build another Lightning Network on a chain that is cheaper to open and close channels on. Imagination is the limit.

Whole New Constructs

Here’s a random idea of my own: Many people can all pile together into a single m-of-n (i.e., 3-of-5) multisig address with a few escrow agents, and simply trust the escrow agents to settle things properly. Every person in the address and the escrow agents can track and update “balances” based on payment routing; record HTLCs that are used and whether they are successfully settled or refunded; and periodically settle the balances on-chain. You simply construct the multisig so that a single “routing” participant and all of the escrow agents are all that is necessary to spend from the multisig. You can even create a timelocked refund transaction to refund everyone’s money after a certain period, the downside of which would be all the money anyone had gained during the lifetime of the construct would be lost if that was used. This would require settling on-chain before the refund transaction became valid to spend.

This would require trusting the escrow agents, but the benefit would be that any person in this “group UTXO” could transfer funds or route an HTLC to any other person in the group UTXO. This would be a massive efficiency gain in liquidity allocation.

Credit Relationships

The simplest way to gain efficiency would be to simply trust people. If you could make money routing a payment across the network for someone, but you don’t have a channel open to the node necessary to route that payment, then you can just promise to pay them later if they trust you. If you were a particularly trustworthy person or entity, and many people on the network were willing to trust you in this way, then you could route payments with a massive degree of flexibility and not have to sink capital into payment channels all over the network. Just settle up honestly at the end of the day, and people will continue trusting you to pass payments for you on an honor system basis.

The One Problem And The Benefits

The major benefit of all these possibilities is that, despite all of them having huge differences in terms of trust model (most of them actually explicitly requiring you trust people you are interacting with if you choose to use them), it doesn’t matter at all for the sender and receiver. If I have a conventional trustless Lightning channel and want to pay someone who also has a trustless conventional Lightning channel, how that payment gets there doesn’t matter to either of us at all. When I send the money, that payment is updated and enforced in my Lightning channel with my peer trustlessly, just like normal. When the receiver actually gets the money, that payment is updated and enforced in their Lightning channel with their peer, trustlessly, just like normal. The fact that someone in the middle is just trusting a promise from their peer to pay them later is totally irrelevant to both of us. I sent my money and no longer have control of it, and the receiver actually got their money and now has control of it, trustlessly.

The problem is, how do I, as the sender, find out about these relationships? On Lightning, the sender is the one who picks the route for a payment, after looking at the routing table of public channels on the network willing to forward payments. To advertise the ability to route a payment requires showing the UTXO on-chain that funded your Lightning channel and proving it is an actual channel. Which is the problem here, none of the above ideas would be able to provide that, so the sender of a payment could be aware of these other options to route a payment. If the gossip protocol and routing table structure was updated to allow these other things though, they could be made aware of other options.

The only real requirement is making sure that advertising other “non-channel” ways to route payments does not open up denial-of-service vectors. The current scheme, requiring sharing the UTXO that funded a channel, is there as a protection against people advertising channels that don’t exist, which could overload nodes with useless gossip data as well as lead to users constantly trying to make payments that never had a chance to succeed in the first place.

At the end of the day, there are problems to solve to increase the flexibility of how payments can be routed on the network, but they are solvable problems. Thinking that Lightning must continue to function in the way it does currently in order to work as a payment network is very narrow thinking, and to put it bluntly, inventing problems that are mostly imaginary.

This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.