Last year, I wrote about the Mercury Commerceblock Wallet, an implementation of the state chain and CoinSwaps. It simultaneously introduces a new blending tool as well as the first wallet to implement a new second layer scaling solution. The team built from Ruben Somsen’s original statechain proposal with some changes to make it work without the need for ANYPREVOUT / Eltoo sighash flag, and the integration of the new CoinSwap design to allow users to mix multiple times without the need for transactions on the chain for each mix.
The background
Just to quickly summarize for those who haven’t read my previous articles: statechain is an off-chain mechanism to freely transfer between anyone off-chain. The original owner/user collaborates with the statechain operator to build the ECDSA-MPC address where the private key is split with half held by the user and the other half by the operator, then a locked and signed withdrawal transaction is created and signed, with the operator before sending the funds to the address new.
No party controls the private key, and users have signed transactions that allow them to unilaterally withdraw their coins after locking time. When a user wants to transfer a statechain, he informs the operator who then cooperates with the receiver. The receiver and operator generate a new set of private keyshares corresponding to the same address, and generate a new signed transaction with a lower time key than the last one, then the operator deletes the old keyshare.
The way cryptography works, the operator’s new keyshare can only be used with the new user’s keyshare, so if they delete the old one, they can’t even collaborate with the old user to spend coins. Also, with newer withdrawal transactions having a lower time lock, the transaction can always be confirmed before the previous owner. This limits the number of times the statechain can be transferred before it must be shut down, but if operators act honestly, it prevents old owners from stealing funds.
Lightning Channel Above Statechain
Commerceblock is currently working on a new BLIP (Bitcoin Lightning Improvement Proposal) to implement the design for something proposed in Somsen’s initial statechain proposal: creating a Lightning channel on top of the statechain.
One of the disadvantages of the statechain itself is that all UTXOs must be transferred at once. However, if a statechain withdrawal transaction spends on a Lightning channel instead of a single user address, then statechain fragments can be transferred through the initial balance distribution on the channel and the channel can be used conventionally to make Lightning payments.
The process starts with the user creating a statechain. The creator and operator go through the normal process of creating a sharded key and entering a backup withdrawal transaction with a timelock, then the creator (Alice) finds a partner (Bob) who will receive the state chain. Alice and Bob participate in the same protocol used to create a sharded key that Alice does with the statechain operator and generates its own shared key. Both then share the cumulative public key and the individual public key to the statechain operator. This allows operators to challenge both parties to sign in and prove that they agree with the current balance for the cooperative cap without waiting for the statechain to withdraw.
From here, with Bob’s authorization, Alice and the statechain operator enter the transaction directly dumping the statechain into the Lightning channel multisig and handling the creation of the Lightning channel transaction. At this point, the statechain address is still controlled by only Alice and the operator but the transaction opening the Lightning channel now belongs to Bob with a lower time than the original statechain withdrawal, ensuring that it can be confirmed before Alice can unilaterally close the statechain. to himself. Then Alice and Bob complete the protocol by completing the final update with the statechain entity, creating the final statechain transaction with a further reduced timelock using the shared key with the operator to create a withdrawal transaction that commits funds to the Lightning channel. Both sides can now advertise the Lightning channel as open and the protocol is complete.
Improving the Utility of Statechains
This proposal will improve the utility of the statechain by releasing the strict liquidity dynamics of how it works. If someone is willing to accept the statechain but the denomination does not match the payment, the sender can simply open a Lightning channel between them and wait until they have to spend more funds (or finally receive what was sent. back) to complete the transfer of the entire statechain balance. These possibilities not only increase the utility of statechain, but also increase the utility of the Lightning Network if properly supported.
Channel rebalancing is a necessity for nodes in the network, both routing nodes as well as edge nodes only send and receive transactions. When the funds flow fully to one side of the channel, the channel is useless for making payments in one direction (if all the money is on your side, you can’t receive payments; if it’s on the other side, then you can’t send payments). This requires shuffling money from one channel to another, which also contributes to channel imbalance along the way to rebalance. Eventually this dynamic reaches a point where it needs to be rebalanced by exchanging funds between Lightning and the base layer on the chain.
Statechains allow liquidity to be moved with the same freedom provided by doing it on-chain, without the need to create an on-chain footprint or pay fees. Say you have a low channel, with all the liquidity on the other side leaving you, no spending capacity and you also have statechain. The statechain is freely transferable to anyone who will receive it, and can have a Lightning channel on top if you don’t send all the value, and can be used to balance funds in regular channels on your side. .
This allows for more efficiency in terms of the number of channels you have to go through to balance your channel (remember, you contribute to changing the balance of every other channel you go through), it’s best to post directly. to the same peer as you have an open channel again. If you want to close a channel with one friend and open it with another, you can rebalance it so that you have the entire balance of the channel and move it all to the new friend if it is built on top. country chain.
The Future of Statechains and Lightning
Discussing our plans moving forward, Nicolas Gregory of Commerceblock said: “Our goal is to create a standardized approach to integrate statechains and Lightning technology in order to facilitate the balance of the Lightning channel using the state channel. This specification will be the foundation for achieving this goal.”
From the beginning, statechain has always been proposed to interact with Lightning to solve the problem of using it yourself: you need to transfer all the UTXO values. They also provide a level of flexibility that Lightning doesn’t have in terms of how liquidity is managed and transferred across the network.
Now that Lightning is at a healthy stage in the beginning of its growth, and the concrete implementation of the statechain has been around for more than a year, it is time to start considering how the two technologies can interact. Lightning as a network is a system for atomic-escrowing transfers between two parties that are not directly connected in the network graph. How each connection in the graph works is, strictly speaking, not a problem for the sender and receiver of the payment, as long as it works.
Statechains and Lightning channels both have a lot to offer in terms of benefits, all that needs to be done is to standardize the two that interact.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.