The idea of sidechains as a scaling and feature extension mechanism for Bitcoin is a very old concept. A kind of basic “ancestor” idea of sidechains, merge mined chains, even goes back to before Satoshi disappeared.
That proposal was simply the idea of two completely separate and unrelated chains being mined by the same group of miners, with no ability to move anything between chains. The original sidechain proposal was made in 2014 by many of the people who went on to found Blockstream literally a week or so after the paper was published. The basic idea was to be able to have coins move back and forth between the main Bitcoin blockchain and other sidechains, with simple payment verification (SPV) proofs being used to prove things are valid when you send coins from one chain to the other. This never came to fruition due to complexities in implementation around chain reorganizations, the potential for theft and risks of mining centralization (all of which can be read about in section four of the Bitcoin white paper).
Peg mechanisms for sidechains can be of two varieties, one way and two way. The meanings should be obvious — in a two-way peg coins can move back and forth between the parent chain and the sidechain, and in a one-way peg, they can only move from the parent chain to the sidechain and never move back. Currently, the only form of two-way sidechain pegs implemented on Bitcoin are through federated consensus, meaning the peg is guaranteed by a trusted set of “custodians” who maintain control of funds pegged into the sidechain in a multisig wallet until they are withdrawn.
People, however, have continued working on other designs for sidechain pegs that are not federated. Here I am going to go through Ruben Somsen’s Spacechain proposal as one example. It is a one-way peg mechanism using a blind merge mine design, similar to Paul Stztorc‘s. This means that coins can only go into the sidechain and never leave, and that miners do not have to run new software to get compensation for mining the sidechain (however, as I will go into later, they can benefit more by doing so).
The Spacechain Proposal
Merge mining requires miners to run the nodes of both the Bitcoin chain and whatever other chain they are mining, in order to compile the blocks for both chains and commit to them in the Bitcoin block header they are mining. Blind merge mining takes advantage of the fact that in reality, the Bitcoin miners only really need to have the other chain’s block header to commit to in their Bitcoin block, someone else can actually take the trouble of putting together the block for the other chain.
Somsen’s proposed mechanism for this can utilize ANYPREVOUT (APO) to allow open competition for anyone to be able to compete to construct the next sidechain block while guaranteeing only one block can be committed per the Bitcoin main chain block. Another benefit of Ruben’s proposal is that it does not require a specific soft fork to enable the possibility of deploying spacechains. Eltoo/ANYPREVOUT is being proposed for benefits to the Lightning Network, enabling flexible statechains, as well as channel factories. Spacechains are simply another possibility of the many things that enabling ANYPREVOUT would pave the way for.
The general idea of his blind merge mining proposal is that, by making use of APO, you can predefine a long set of transactions that take the same initial UTXO fed into them and commit to always recreating it. So, imagine a single satoshi UTXO, with each pre-created transaction guaranteeing that that same UTXO is recreated as an output when confirmed. Think of it like a sort of marker, this special UTXO is the identifier that allows anyone looking at the main Bitcoin blockchain to know, “This is where I find a commitment to sidechain X’s blocks.” This leaves open one problem though: miner fees. If that UTXO has to be recreated with the same amount, there are no funds to pay fees with.
This can be dealt with by utilizing SIGHASH_SINGLE (the signature from an input only signs that single input, and the corresponding output) and SIGHASH_ANYONECANPAY (people are freely able to add additional inputs and outputs without invalidating the signature as long as the input/output using SIGHASH_SINGLE is left as it is, to not invalidate that signature). Then anyone can add an input and change output to pay miner fees for the transaction.
This is also the mechanism used to commit to the block header of the sidechain block. The same way that Taproot commits to the tree of different spending conditions by tweaking the normal public key with the Merkle root of the tree, anyone can tweak the normal public key with the block header hash of the sidechain block. Sidechain nodes can then reveal and relay that block header with a pointer to transaction in the main chain to prove it was actually mined. From there, sidechain nodes would do all the normal validation to ensure the sidechain block is following proper consensus rules, and relay the actual blocks across the sidechain network just like on the main chain.
If one of the transactions used to commit to the sidechain blocks on the main chain was used to commit to an invalid block, or even completely garbage data, then when sidechain nodes see the commitment transaction used on chain, two things can happen: One, an invalid block will be propagated across the sidechain network, and when it fails to pass validation checks it will be orphaned; or two, the data is never revealed, in which case the next sidechain block will build on top of and commit to the last block actually revealed, and the unrevealed commitment will be ignored. This second possibility follows the same kind of longest-chain logic as the main chain, so even if something was revealed later, it will still be orphaned because of future blocks that did not build on it.
But there is still the problem of double spending. Anyone with the private key used to generate the marker UTXO could potentially doublespend any one of the predefined transactions used to commit to sidechain blocks and invalidate the entire set from that point forward.
This is solved by actually inserting the signature into the locking script of the UTXO itself. This locks in the signature on the input and output, guaranteeing the recreation of the marker UTXO in the next transaction using it. Because that signature is going to be automatically passed and checked when the UTXO is spent, it’s not possible to simply replace it with another one and spend it to a different destination.
This leaves one last outstanding problem. It would be possible, in theory, to submit multiple transactions all in a row into a single Bitcoin block, so that a vast number of sidechain blocks are confirmed by miners all in a single main chain block. This could be abused to denial-of-service attack the sidechain network.
In order to solve this problem, a CHECKSEQUENCEVERIFY (CSV) relative time lock can be inserted into the marker UTXO script to guarantee that only one transaction using the marker UTXO can be confirmed inside a single given main chain block.
Altogether it looks like this:
It is also worth noting that two variants of this design can be implemented with CHECKTEMPLATEVERIFY (CTV) or without any changes at all. These two design variants simply have suboptimal tradeoffs.
The CTV variant would use that functionality to commit to the chain of transactions using CTV instead of APO with the hack including the signature inside the UTXO locking script. CTV commits to all the outputs of a transaction spending the CTV UTXO, but it doesn’t commit to any input besides itself.
This means you can add inputs, but not outputs, to a CTV transaction. So you can bring your own fee just like in the APO design, but you cannot add a commitment to the sidechain block header.
So, what we need to do here is create a transaction completely outside of the chain of CTV transactions for the sidechain commitment to create a UTXO that is just enough to pay the fee for the CTV transaction (because you cannot create a new change output in that transaction, 100% of the input you add goes to fees), and inside the transaction preparing the fee UTXO is where we commit to a sidechain block header. So, first step: a transaction creating a fee paying output and a commitment to a sidechain block header. Second step: we take the fee output and add it as an input to the CTV transaction, which when confirmed, “mines” our specific sidechain block. This variant looks like this:
The next variant simply uses pre-signed transactions. It could be deployed today, but because of the limitations of what script can do, it requires all the fees for the transactions to be paid up front by whoever creates the spacechain.
The chain of transactions starts with a single UTXO, and in a chain creates two outputs. The first output is the marker UTXO, which signals that the chain of transactions is related to a specific spacechain, the second one is a small value UTXO that is spendable openly by anyone allowing for attaching another input/output to it. This second transaction is where anyone can openly commit to be the first to spend that second output from the spacechain transaction chain, and use it to commit to their sidechain block header.
In the CTV variant, the sidechain block had to be committed to in a secondary transaction because CTV does not allow adding new outputs in a transaction spending an input locked by CTV. This variant requires using a secondary transaction because if you add any new inputs or outputs to the pre-signed chain, you would alter the TXID of the transaction and invalidate all the pre-signed transactions that come after it. This variant looks like this:
The one downside of this last variant is that if whoever pre-signed all of the transactions to use for sidechain block commitments does not delete the private keys used to do so, they can effectively halt the chain by double spending the current marker UTXO at any time.
And there you have it. This is the most recent proposal for a sidechain design on Bitcoin, and it can be implemented in three different ways, with the obvious caveat that the implementation path that can be done now has the issue of requiring someone to delete a private key.
This article is simply the first in a series relating to the major sidechain design proposals that have been published for Bitcoin since the original 2014 design. Keep an eye out for the rest.
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.
