[ad_1]
Last year, I wrote about Commerceblock’s Mercury Wallet, an implementation of both statechains and CoinSwaps. This simultaneously introduced a new mixing tool as well as the first wallet to implement a new second-layer scaling solution. The team built off of Ruben Somsen’s original statechain proposal with some changes to make it work without the needed ANYPREVOUT/Eltoo sighash flag, and integrated a new CoinSwap design to allow users to mix multiple times without needing to transact on chain for each mix.
Background
To just quickly summarize for those who didn’t read my previous piece: a statechain is an off-chain mechanism for transferring freely between anyone completely off-chain. The original owner/user collaborates with a statechain operator to construct a ECDSA-MPC address where the private key is sharded with one half held by the user and the other half by the operator, then a timelocked, pre-signed withdrawal transaction is created and signed, with the operator before sending funds to the new address.
Neither side fully controls the private key, and the user has a pre-signed transaction that allows them to unilaterally take the coins back after the timelock. When the user wishes to transfer the statechain, they notify the operator who then collaborates with the receiver. The receiver and operator generate a new set of private key shares that correspond with the same address, and generate a new pre-signed transaction with a lower timelock than the last one, and then the operator deletes their old keyshare.
The way the cryptography works, the operator’s new keyshare will only work with the new user’s keyshare, so if they delete the old one, it is not even possible for them to collaborate with the old user to spend the coins. Also, with the newer withdrawal transaction having a lower timelock, that transaction can always be confirmed before the prior owner’s. This limits the number of times the statechain can be transferred before it has to be closed, but if the operator acts honestly, this prevents older owners from stealing funds.
A Lightning Channel On Top of A Statechain
Commerceblock is now working on a new BLIP (Bitcoin Lightning Improvement Proposal) to implement a design for something proposed in Somsen’s initial statechain proposal: establishing a Lightning channel on top of a statechain.
One of the shortcomings of a statechain by itself is that the entire UTXO has to be transferred at once. If, however, the statechain withdrawal transaction spends into a Lightning channel instead of a single user’s address, then fractions of the statechain can be transferred through the initial balance distribution in a channel and that channel can be used conventionally to make Lightning payments afterward.
The process first begins with a user creating a statechain. The creator and operator go through the normal process of creating the sharded key and signing a backup withdrawal transaction with a timelock, then the creator (Alice) finds a counterparty (Bob) that will accept statechains. Alice and Bob engage in the same protocol used to create a sharded key that Alice did with the statechain operator and generate their own shared key. Both of them then share both the cumulative public key and their individual public key shares to the statechain operator. This allows the operator to challenge both of them to individually sign and prove that they agree on the current balance for cooperative closes without waiting for the statechain withdrawal timelock to expire.
From here, with Bob’s authorization, Alice and the statechain operator sign a transaction directly spending the statechain into the Lightning channel multisig and handle the Lightning channel transaction creation. At this point, the statechain address is still controlled by just Alice and the operator but the transaction opening a Lightning channel is now in Bob’s possession with a lower timelock than the original statechain withdrawal, guaranteeing it can be confirmed before Alice can unilaterally close the statechain to herself. Then Alice and Bob finalize the protocol by completing one last update with the statechain entity, creating a final statechain transaction with a further decremented timelock using their combined key with the operator’s to make a withdrawal transaction that spends the funds to the Lightning channel. They can both now advertise the Lightning channel as open and the protocol is complete.
Improving The Utility Of Statechains
This proposal would greatly improve the utility of a statechain by loosening the strict liquidity dynamics of how they work. Whenever someone would be willing to accept a statechain but the denomination doesn’t match the payment, the sender can simply open a Lightning channel between them instead and wait until they need to spend the rest of the funds (or wind up receiving what they sent back) to finalize a transfer of the entire statechain balance. Such a possibility not only increases the utility of a statechain, but also increases the utility of the Lightning Network if properly supported.
Channel rebalancing is a necessity for nodes on the network, both routing nodes as well as edge nodes simply sending and receiving transactions. When funds flow completely to one side of a channel, it makes the channel useless for passing payments in one direction (if all of the money is on your side, then you can’t receive payments; if it’s on the other side, then you can’t send payments). This necessitates shuffling money from one channel to another, which also contributes to unbalancing the channels along the way to rebalance your own. Eventually this dynamic gets to a point where things must actually be rebalanced by swapping funds between Lightning and the base layer on-chain.
Statechains allow liquidity to be moved around with the same freedom provided by doing so on-chain, without needing to create the on-chain footprint or pay fees for it. Say you have a depleted channel, with all of the liquidity on the other side leaving you, no spending capacity and you also have a statechain. That statechain can be freely transferred to anyone who will accept it, and it can even have a Lightning channel on top of it if you aren’t sending the entire value, and it can be used to rebalance funds in your regular channel on your side.
This allows for much more efficiency in terms of how many channels you have to route through in order to rebalance your channel (remember, you are contributing to shifting the balances of every other channel you route through), in the best case literally sending it directly to the same peer that you have the channel that you are rebalancing open with. If you wish to close a channel with one peer and open it with another, you can even rebalance things so you have all of the balance of the channel and move it entirely off-chain to the new peer if it is built on top of a statechain.
The Future Of Statechains And Lightning
Discussing their plans going forward, Nicolas Gregory from Commerceblock said: “Our goal is to establish a standardized approach for combining statechains and Lightning technology in order to facilitate off-chain balancing of Lightning channels through the use of state channels. This specification will serve as the foundation for achieving this objective.”
From the very beginning, statechains were always proposed to interact with Lightning in order to solve the issue of using them by themselves: that you must transfer the entire value of the whole UTXO. They also provide a degree of flexibility to Lightning that it does not have on its own in terms of how liquidity is managed and transferred around the network.
Now that Lightning is at a healthy stage in its early growth, and a concrete implementation of statechains has existed for over a year, it’s time to start considering how these two technologies can interact together. Lightning as a network is a system for atomically-escrowing transfers between two parties that are not directly connected on the network graph. How each connection on that graph works, strictly speaking, should not matter to senders and receivers of payments, as long as it works.
Statechains and Lightning channels both have a lot to offer each other in terms of benefits, all that needs to be done is to work out standardizing the two interacting with each other.
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.
[ad_2]
Source link