Statechain-based Lightning Network Channels

Original Title: Lightning Network Channels Based on Statechain

Original Author: SHINOBI

background

background

Just a quick summary for those who haven't read my previous post: a statechain is an off-chain mechanism for transferring money between anyone completely off-chain for free. The original owner of the funds cooperates with a statechain operator to construct an ECDSA-MPC address. The private key of the address is divided into two halves, one half is in the hands of the user, and the other half is in the hands of the operator. A withdrawal transaction with a time lock is signed, and then the user sends the money to this address.

No one party has full control of this private key, and the user holds a pre-signed transaction, so they can unilaterally get those funds back after the timelock is unlocked. When users wish to transfer this asset, they notify the operator, who works with the recipient of the payment to create a new set of private key shards (but with the same real estate as the original private key shards), and then generate another A transaction with a timelock (and a shorter timelock) is signed; finally, the operator deletes the fragment of the previous private key.

In this way, the private key fragments in the hands of the current operator will only be combined with the private key fragments in the hands of the new owner of the funds, so as long as they delete the old private key fragments, they cannot be combined with the old owner of the funds. spend money. In addition, newer withdrawal transactions have shorter timelocks, so the new owner of the funds can always withdraw the funds faster than the old owner. This mechanism limits the number of times statechain funds can be transferred, and must be withdrawn at the point (otherwise it may be taken away by the old owner).

Lightning channel based on statechain

Commerceblock is now writing a new BLIP (Bitcoin Lightning Network Upgrade Proposal) to achieve something that was in Somsen's original proposal: a lightning channel on a statechain fund.

One of the shortcomings of the statechain itself is that every time it is transferred, the entire UTXO is transferred together. But what if the statechain withdrawal transaction transfers funds not to an ordinary user's address, but to a lightning channel? A portion of the statechain funds can then be transferred through the channel's initial balance distribution, and the channel can then routinely initiate Lightning Payments.

The whole process also starts with a user creating a statechain fund. The creator and the operator of this Statechain go through the usual process: create a shared private key and sign a block transaction with a time lock; then the creator (Alice) finds a channel counterparty (Bob) who is willing to accept statechain funds. Together, Alice and Bob follow the same process in which Alice and the operator split the private key to create their own shared public key. Both then share their public public key and fragments of their personal public key with the Statechain operator. This allows the operator to challenge them to each sign and certify that they agree to cooperate to close the statechain on the latest balance without having to wait for the statechain withdrawal timelock to expire.

From here, with Bob's authorization, Alice and the operator of this Statechain can sign a transaction to spend the funds in the statechain directly into a multi-signature Lightning channel, and handle the creation process of the Lightning Network channel (translated Author's Note: This channel is the channel between Alice and Bob).

At this time, the Statechain address is still in the hands of Alice and the operator, but the transaction that opened the lightning channel is now in Bob's hands, and its time lock is shorter than the original withdrawal transaction, which ensures that this transaction can be unilaterally processed by Alice. Take effect before closing the Statechain. Alice and Bob then complete a final update with the operator, using their shared public key to create a withdrawal transaction with the operator that spends the statechain funds into the Alice-Bob channel Bob's shared public key becomes the new owner of the statechain), and the timelock for this withdrawal transaction is shorter. Now, Alice and Bob can announce that they have a Lightning channel.

(Translator's Note: The purpose of this set of agreements is to create a channel between the current owner and the intended payer based on a statechain fund, allowing the current owner to split the statechian funds and pay only part of the funds to the intended payer. After the agreement ends, the relevant Statechain will no longer belong to the original owner (here, Alice), because the private key fragment matching Alice has been destroyed by the operator; it will be replaced by the Alice-Bob channel.

(Translator's Note: Its shortcoming, or incompleteness, is that Alice can't actually transfer all the channel (or her remaining balance) to Carol, because it needs to transfer all the transactions between Alice and Bob in the channel. The records of the interaction are all transferred to Carol, otherwise Alice and Bob can conspire to defraud Carol; but there is no mechanism designed to ensure that Alice has transferred all the data, which requires Alice/Bob to submit a commitment after each lightning payment is initiated. However , based on the principle described above, it can also be considered as a multi-party coinpool instead of a two-party lightning channel.)

Improve the utility of the statechain

This proposal would greatly increase the utility of the statechain because it relaxes the statechain's otherwise strict liquidity requirements. Whenever someone wants to accept a statechain fund but finds that the denomination does not match the payment amount, the sender can solve this problem by opening a lightning channel with TA until one party spends the remaining funds (or channel All funds in the statechain belong to one of the parties), and then complete a transfer to transfer all statechain funds. Such possibilities not only increase the usefulness of the statechain, but also the utility of the Lightning Network (if the protocol is properly supported).

The rebalancing of the balance in the channel is a necessary function for nodes in the Lightning Network, whether you are a routing node or an edge node that only sends and receives transactions. When all the funds in the channel have moved to one end of the channel, this channel loses its function of transmitting payment in a certain direction (if all the funds are on your side, you cannot receive payment through this channel; if all The funds are all on your opponent's side, then you can't use this channel to pay). So, you need to move funds from one channel to another, rebalancing your own channel by causing an imbalance in the other channel. Ultimately, this dynamic ends with a channel somewhere having to exchange funds across the Lightning Network and on-chain.

Statechain allows liquidity to move on-chain, but without creating an on-chain footprint or paying fees for it. Suppose you have a drained channel, all balances are with your counterparty, you run out of capacity to spend, and you have a Statechain fund. Well, you can transfer this Statechain funds to whoever is willing to accept it, and if you can't spend all of your Statechain funds, then you can build a Lightning channel on top of it, and this channel can also be used to rebalance your Ordinary lightning channel.

This will allow for increased efficiency in terms of the number of channels that need to go through to rebalance your channels (don't forget that when you want to rebalance your channels, it will unbalance every channel that money flows through), optimal In this case, you can rebalance your channel by sending funds directly to the same counterparty. If you want to close a certain channel and open another channel with another person, you can even rebalance all the balances in this channel and transfer them all to the new channel you established with your new opponent based on the statechain.

The Future of Statechain and the Lightning Network

Discussing their future plans, Commerceblock’s Nicolas Gregory said: “Our plan is to establish a standard approach to combining statechain and Lightning technology to assist Lightning in rebalancing off-chain using state channels. The current A set of norms will be the cornerstone of this goal.”

From the very beginning, the statechain was proposed to integrate with the Lightning Network to solve a problem of its own: the value of the entire UTXO must be transferred when making a payment. This also provides a degree of flexibility to the Lightning Network, which does not have its own liquidity management method.

Now that the Lightning Network is in a healthy early growth phase and a solid statechain implementation has been around for over a year, it's time to consider combining the two. The Lightning Network, as a network, is a system for automatically processing money transfers between any two parties that are not directly connected. As for how each channel in the network map works internally, strictly speaking, it doesn't matter to both the sender and the receiver; as long as the two parties who establish the channel can get by themselves.

Both Statechain and Lightning Channels offer many benefits to each other, all we need to do is develop a standardized way for the two to interact.