Ways to Upgrade Lightning Payment Routing

The Lightning Network is a well-developed and rapidly 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 increasing, and more applications and ways for users to interact with it are being developed every year. It also has many problems to overcome in the long run:

  • Scalability limits the number of channels that can be opened or closed on the chain at a time.
  • There is a problem with the minimum size Contract locked in hash time (HTLC) increasing as on-chain fees also increase, as it must be economical to settle.
  • There are also a host of privacy issues.

One of the main issues frequently mentioned concerns the liquidity needs for the routing of payments. In order to successfully route a payment, there must be a link of channels, from the sender to the receiver, that has enough liquidity on the right side of the channel to be able to route the payment. This makes the decision of where to deploy your coins on the network very important. It also means that the overall amount of cash that people are willing to deploy is a kind of upper limit of how much value the network can handle.

Ultimately, it comes down to saying that when you open a channel, you decide to lock that money down so that it can only be used to route payments to that channel partner, and who they’re connected to on the graph . Yes, at the end of the day, the idea of ​​the Lightning Network is that by making enough jumps, 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 fewer hops than you, that is the path that will most likely be selected to route the payment. Lightning already requires over-provisioning to a large extent, i.e. to route a payout of 1 BTC over 10 hops requires 10 collateral BTC to be locked in the payout channels along that route. Competition for good connections to generate routing revenue exacerbates this by incentivizing even more redundant collateral.

This is a problem resulting from the fact that Lightning channels are two-part “tubes” that can simply push value back and forth in those two directions. Here’s the thing though: The problem is a bit imaginary. Payments on Lightning uses HTLCs, a script in Bitcoin output that says a 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 the output. expiration of a time limit. This is a general script that can be applied in-chain, in lightning channels, above status chains, on side-chains, etc. As long as you can use an HTLC, in theory, anything can help route a Lightning payment.

Status strings

A state channel is actually something like a lightning channel, except you can transfer ownership of the entire channel entirely off-chain. Their trust model depends on the operator (which may be a federation) of the state channel refusing to agree with the former owners and steal the state channel from the current owner. It’s not as reliable as a lightning channel, but it’s much more flexible because ownership can be passed without having to do an on-chain transaction. Since status chains are based on off-chain pre-signed transactions, 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 reallocate liquidity on the fly off-chain. Instead of having to open channels and pour liquidity into them to be well connected in advance, their funds can be dynamically reallocated on the fly off-chain in response to shifting demand to places they are not connected (or not well enough connected for ). The only requirement is that the other party wants to transfer cash to the trust of the state chain operator.

Side chains

Sidechains can implement any arbitrary rules they want. Block times can be different, block sizes can be different, everything can be changed. The only catch currently is that to move your Bitcoin to a sidechain, you have to trust a federation that keeps the funds on the mainchain. You can apply HTLC on a sidechain that uses Bitcoin’s scripting system; you can have a script system closer to Ethereum that allows dozens of people to share an account that splits balances and updates them based on the success or failure of an HTLC; You can do anything. As long as the blockchain supports conditionally paying out money to one party if it produces a hash, and to the other party after a time expires, it can help route Lightning payments. Other blockchains may experiment with ways to make liquidity allocation more efficient than the main Bitcoin blockchain. You can even do something as simple as create another Lightning Network on a chain that’s cheaper to open and close. Imagination is the limit.

Brand new constructions

Here’s an idea I picked up at random: many people can all stack into one m-of-not (i.e., 3 out of 5) multisig address with a few escrow agents, and just trust the escrow agents to sort things out right. Each person at the address and 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 on-chain balances. You simply build the multisig so that a single “routing” participant and all escrow agents are all there is to spend from the multisig. You can even create a time-locked refund transaction to refund everyone’s money after a certain period of time, the downside of which would be that all the money someone earned during the lifetime of the build would be lost if used. This would require on-chain settlement before the refund transaction becomes valid to be spent.

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

Credit relationships

The easiest way to gain efficiency would be to simply trust people. If you could make money by routing a payment over the network for someone, but you don’t have an open channel to the node needed 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 tremendous degree of flexibility and not have to invest capital. in payment channels across the network. Just settle honestly at the end of the day, and people will continue to trust you to make payments for you based on an honor system.

The only problem and the advantages

The main advantage of all these possibilities is that, although they all have huge differences in terms of the trust model (most of them explicitly requiring you to trust the people you interact with if you choose to utilize), it doesn’t matter to sender and receiver. If I have a Conventional Lightning Channel with no trust and I want to pay someone who also has a Conventional Lightning Channel with no trust, how that payment gets there doesn’t matter to both of us. When I send money, that payment is updated and applied in my lightning channel with my untrusted peer as usual. When the recipient actually receives the money, that payment is updated and applied in their Lightning channel with their peer, trustless, as usual. That someone in the middle would simply trust a promise from their peer to pay them later is totally irrelevant to both of us. I sent my money and I no longer have control of it, and the recipient has indeed received their money and is now in control of it, without trust.

The problem is how can I, as a sender, know these relationships? On Lightning, the sender is the one who chooses the route for a payment, after consulting the routing table of public channels in the network willing to transfer payments. Advertising the ability to route a payment requires showing the UTXO channel that funded your Lightning channel and proving that it is a real channel. What’s the problem here, none of the ideas above would be able to provide this, so the sender of a payment might be aware of these other options for routing a payment. If the gossip protocol and routing table structure were updated to allow these other things, they might be made aware of other options.

The only real requirement is to ensure that advertising other “out-of-channel” means of routing payments does not open vectors for denial of service. The current scheme, requiring sharing of the UTXO that funded a channel, is there to protect against people advertising channels that don’t exist, which could overload nodes with unnecessary gossip data and lead users constantly trying to make payments that never happened. a chance to succeed in the first place.

Ultimately, there are problems to be solved to increase the flexibility of routing payments on the network, but they are solvable problems. To think that Lightning needs to continue operating as it does now to function as a payment network is very narrow thinking, and to put it bluntly, making up problems that are mostly imaginary.

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

Source link

Elaine R. Knight