A group of Bitcoin programmers led by Tom Trevethan, started work on the implementation of Statechains. innovatory protocol second layer scaling for Bitcoin, will probably see its second view.
For the first time, the Statechain concept was presented to a wider audience at technical conference by Ruben Somsen in 2018. In a fairly extensive presentation, he presented participants with his vision of Bitcoin scalability. At that time, the idea did not gain significant approval and little was said about it in the development community BTC.
Exactly a week ago, the idea returned to mailing lists Bitcoin-Dev thanks to Tom Trevethan. In a short post, he announced that he and a group of programmers are starting work on implementing Statechains.
As it stands, the Bitcoin code does not contain the functions needed to implement Statechain, such as SIGHASH_NOINPUT. Tom and a group of programmers proposed two alternative solutions that, if modified, would work with the latest version of Bitcoin.
According to the idea SomsenStatechain would be the protocol of the second layer, which means that in fact the transactions carried out in them would not generate traffic on the first layer, so that the Bitcoin network would not be burdened. Statechaines use blockchaina only when they enter or exit the system.
In a nutshell, Statechain works on the principle of transfer private keys (interim) between interested parties. Let’s now discuss the general technical issues of this protocol.
The potential benefits of such a solution include:
- more effective Bitcoin blockchain scaling
- smaller fees
Statechaines use Bitcoin features such as:
- Schnorr Signatures (mainly MuSig)
- Signatures adapter
- Graftroot (optional)
Each time funds are transferred to Statechain (B to C), a Bitcoin transaction is created outside the chain. Eltoo ensures that only the final recipient can withdraw funds without the help of the Statechain entity.
Schnorr Signatures they allow to achieve several signatures (multisig) using one key. Eltoo, allows you to create non-expiring channels with multiple participants. The most important functionality are Signatures adapter, thanks to which transaction security is maintained by disclosing each signature that individual Sidechain units place. Graftroot simplifies the way users can exit the system and avoids potential problems in the event of a possible occurrence hard FORK.
Among the new modifications proposed by Treventhan in the post on Bitcoin-Dev, we can distinguish two basic adaptations.
- Removal of the eltoo mechanism used as backup / refund transaction. This role would be taken over by a decreasing parameter nLocktime. It specifies the minimum time (shown in Unix time or block height) before which the transaction cannot be accepted in the block. In this particular case, the use of nLocktime has one major drawback: it limits the use time of UTXO. On the other hand, it doesn’t require that the current owner be always online.
- Another modification directly touches on issues related to transaction security and concerns the method of generating keys and transferring them between interested parties. Details can be found on Bitcoin-Dev.
It is difficult to assess whether further discussion about Statechains will bring something new. Of course, we will follow this topic for you.
Don’t you think we already have a good enough solution to the Bitcoin scalability problem in the form of LN? It is true that it still needs some refinement but everything is going for the better.
Get notifications about important new market events.