Top ways to Improve Lightning Network Payment Routing

The Lightning Network is a well-developed, fast-growing, Layer 2 deal solution on the Bitcoin network. Increasingly more services and exchanges are integrating it, the liquidity readily available for routing payments is growing, and more applications and ways for users to connect with it are being established each year. It likewise has numerous issues to get rid of 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 Agreement (HTLC) increasing as on-chain costs likewise increase, due to the fact that it has to be economical to settle.
There are likewise a slew of privacy concerns.

One major problem that is regularly talked about is the liquidity requirements for routing payments. In order to effectively 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 ideal side of the channel to be able to pass the payment along. This decides of where to release your coins on the network an extremely important one. It also suggests that the total amount of liquidity individuals are willing to release is a sort of upper limit on how much worth 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 just be utilized to path payments to that channel partner, and whoever they are linked to on the graph. Yes, eventually the idea of the Lightning Network is that, by making sufficient hops you can find a connection to nearly anywhere. However, the reality is that if another person can accomplish routing a payment to a location utilizing less hops than you can, that is the course that will more than likely be selected to path the payment. Lightning already needs overcollateralization to a large degree, i.e., to route a 1 BTC payment throughout 10 hops needs 10 BTC of collateral to be locked into payment channels along that path. The competitors over having good connections to make routing revenue worsens this by incentivizing even more redundant collateralization.

This is an issue arising from the fact that Lightning channels are two-party “tubes” that can simply push value backward and forward in those two instructions. Here’s the important things though: The problem is type of an imaginary one. Payments on Lightning usage HTLCs, a script in a Bitcoin output that states someone can claim the output and spend it by revealing the preimage to a hash, or another person can declare the output and spend it after waiting for a timelock to expire. This is a basic script that can be applied on-chain, in Lightning channels, on top of statechains, on sidechains, etc. As long as you can use an HTLC, in theory, anything can participate in routing a Lightning payment.

Statechains.

A statechain is successfully something like a Lightning channel, other than you can move ownership of the entire channel entirely off-chain. Their trust model depends on the operator (which can be a federation) of the statechain refusing to collude with previous owners and steal the statechain from the existing owner. It is not as trustless as a Lightning channel, however it is a lot more flexible as the ownership can be circulated without needing to perform an on-chain deal. Given that statechains are based on pre-signed transactions off-chain, you can include HTLCs to them.

This enables them to be used to optimize the performance of routing payments on Lightning by permitting 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 action to shifting need to locations they are not connected to (or not connected all right to). The only requirement is that the other party wishes to shift liquidity to relying on the statechain operator.

Sidechains.

Sidechains can execute any approximate guidelines they want. Block times can be different, block sizes can be various, anything can be changed. The only catch currently is that to move your Bitcoin to a sidechain, you need to rely on a federation that custodies the funds on the primary chain. You can use HTLCs on a sidechain that utilizes 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 stops working; you can do anything. As long as the blockchain supports conditionally providing money to one party if they produce a hash, and the other party after a timelock ends, they can assist path Lightning payments. Other blockchains can try out methods to make liquidity allocation more effective than the primary Bitcoin blockchain. You can even simply do something as basic as develop another Lightning Network on a chain that is more affordable to open and close channels on. Creativity is the limit.

Entire New Constructs.

Here’s a random concept of my own: Lots of people can all stack together into a single m-of-n (i.e., 3-of-5) multisig address with a few escrow agents, and merely rely on the escrow representatives to settle things correctly. Everyone in the address and the escrow agents can track and update “balances” based upon payment routing; record HTLCs that are used and whether they are successfully settled or refunded; and regularly settle the balances on-chain. You simply construct the multisig so that a single “routing” individual and all of the escrow agents are all that is necessary to spend from the multisig. You can even develop a timelocked refund transaction to reimburse everyone’s money after a specific period, the disadvantage of which would be all the cash anyone had actually acquired throughout the lifetime of the construct would be lost if that was used. This would need settling on-chain prior to the refund transaction ended up being legitimate to invest.

This would require relying on the escrow representatives, however the benefit would be that any person in this “group UTXO” could transfer funds or route an HTLC to any other individual in the group UTXO. This would be an enormous effectiveness gain in liquidity allotment.

Credit Relationships.

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

The One Problem And The Advantages.

The major advantage of all these possibilities is that, despite all of them having big differences in regards to trust design (most of them in fact clearly requiring you trust people you are connecting with if you select to use them), it doesn’t matter at all for the sender and receiver. If I have a standard trustless Lightning channel and want to pay someone who also has a trustless standard Lightning channel, how that payment gets there doesn’t matter to either people at all. When I send the money, that payment is updated and enforced in my Lightning channel with my peer trustlessly, just like regular. When the receiver actually gets the cash, that payment is updated and implemented in their Lightning channel with their peer, trustlessly, much like regular. The fact that somebody in the middle is simply relying on a pledge from their peer to pay them later is absolutely 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 issue is, how do I, as the sender, learn about these relationships? On Lightning, the sender is the one who picks the path for a payment, after looking at the routing table of public channels on the network happy to forward payments. To promote the ability to path a payment requires revealing the UTXO on-chain that financed your Lightning channel and showing it is an actual channel. Which is the issue here, none of the above concepts would have the ability to provide that, so the sender of a payment could be knowledgeable about these other alternatives to path a payment. If the chatter protocol and routing table structure was updated to enable these other things however, they could be warned of other alternatives.

The only genuine requirement is ensuring that marketing other “non-channel” methods to path payments does not open up denial-of-service vectors. The present plan, needing sharing the UTXO that moneyed a channel, is there as a protection versus individuals advertising channels that don’t exist, which could overload nodes with useless gossip data as well as result in users continuously attempting to make payments that never ever had a chance to be successful in the first place.

At the end of the day, there are issues to fix to increase the versatility of how payments can be routed on the network, however they are solvable issues. Believing that Lightning needs to continue to work in the way it does presently in order to work as a payment network is very narrow thinking, and to put it candidly, developing issues that are mostly imaginary.