Hyperloop: A New Concept by Lightning Aiming to Solve Liquidity Problems

About two months ago, Lightning Labs released Lightning Loop, a service that allows users to fill or empty Lightning channels without closing them, thus reducing on-chain fees. The service, developed by Lightning Labs developers Alex Bosworth and Bryan Vu, was created to help users manage their liquidity.

The Loop service, says Bosworth, is helpful for managing liquidity because “it sidesteps the liquidity problem for Lightning, which is that you can’t do flow rebalancing. If you run out of channel capacity in one direction, there’s no possibility that you can get more in a totally self contained, only-Lightning world. You need to go outside in order to rebalance.”

So, the natural step for users to mitigate this problem today is to perform a swap, which occurs on-chain and thus requires a transaction fee — and transaction fees on the Bitcoin blockchain can be quite substantial. With the alpha version of Loop available to the public, Bosworth and Lightning Labs had to think about how to make managing liquidity as efficient as possible.

Making Liquidity More Efficient

To address this issue, Bosworth developed a concept called “Hyperloop” as a next step toward solving this problem. Hyperloop is a concept that aggregates swaps so that individual transactions don’t occur on-chain with individualized signatures and outputs. Hyperloop batches inputs together using a method called signature aggregation.

“With signature aggregation, if you can manage to get a bunch of people all together to sign cooperatively, you can take the normal signature cost of moving funds on-chain from however many parties there are on-chain to one signature. I don’t think there’s any limitation to that.”

While this saves costs, one of the requirements is cooperation between many parties over a short period of time, which can be more challenging than it sounds.

Coordinating a Hyperloop Transaction

The Hyperloop concept mediates coordination between so many parties by essentially creating a limited-time, multiparty channel for all parties to join. So, in practice, if there were a lot of users who needed inbound liquidity, a “Loop Out” event would be created using Lightning Loop.

Lightning Loop also acts as a coordinator for these multiparty events, which solves the problem of dealing with malicious actors who might join these events with the intent to mess them up. And it does all of this in a noncustodial fashion.

While Hyperloop offers significant savings for batching the input side of multiple transactions, another big advantage of Hyperloop is savings on output scripts. “The output script, at a minimal level, is only 30 bytes,” says Bosworth. “A normal, on-chain swap is around 300 bytes. So, Hyperloop offers at least 10 times’ savings here.”

Hyperloop also allows for aggregation off-chain as well. For example, if a user has two channels, both 0.1 BTC, and wants to change the balance so that both 0.1 BTC are on the same side, they could ] accomplished this today with two swaps, resulting in two on-chain transactions. This issue of funds sitting on two separate channels can be solved through a proposal called Atomic Multipath Payments (AMPs). Without getting too technical, AMPs essentially allow a user to receive multiple transactions as if they were one, reducing the on-chain cost of sending multiple transactions to the same party.

According to Bosworth, there are two ways to approach AMPs. “Ideally it will be something that we allow with improved signatures like Schnorr, but we also have another way we can do it in the short term called ‘base AMPs,’ and this works really well with Loop.”

As such, base AMPs will be used in Hyperloop as well.

How AMPs Will Benefit Hyperloop

AMPs will benefit individual users who have many open channels. For example, if a user has 100 channels, Hyperloop can be split up between all those channels and wait for all those payments to come through before the swap is executed.

This offers a significant cost savings to another concept called “splicing,” which allows for an on-chain payment (resulting in an on-chain fee) out of a channel without requiring that the channel itself be closed. In this specific use case, a base AMP makes a lot more sense.

Upcoming developments in Bitcoin are a big consideration for all of this tech. Specifically, MuSig, a new multisignature standard that serves as a building block for technologies like Taproot, is the key to achieving these huge savings. Once Schnorr and Taproot are implemented into Bitcoin, MuSig, according to Bosworth, will be helpful in providing a protocol for safe signature aggregation.

As well, it is worth noting that Lighting Labs has also been working on signature aggregation for ECDSA, in case MuSig takes longer to implement than expected.

This article originally appeared on Bitcoin Magazine.

from Bitcoin Magazine http://bit.ly/2WcXmwJ