A Few Ways We Can Upgrade Lightning Network Payment Routing

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: 

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.

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 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.

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. 
























Post a Comment

Previous Post Next Post