It’s not new to think of new bitcoin sidechain proposal as a way to scale Bitcoin and add new features. Even before Satoshi vanished, sidechains and merge mined chains had a kind of fundamental “ancestor” concept.
Simply put, that suggestion the notion of having the same set of miners mine two entirely different and unrelated chains without able to transport anything between them. A week or so after the paper released in 2014, many of the individuals who later founded Blockstream made the original sidechain proposal.
Simple payment verification (SPV) proofs would used to demonstrate the validity of transactions sent from one sidechain to another, allowing funds to move back and forth between the main Bitcoin blockchain and other sidechains. Due to difficulties in implementation surrounding network reorganizations, the possibility of theft, and the dangers of mining centralization, this never materialized.
There are Two Types of Peg Systems For Sidechains: One-Way And Two-Way
Coins can flow back and forth between the parent chain and the sidechain in a two-way peg, but they can only move from the parent chain to the sidechain and never the other way, in a one-way peg. The only two-way sidechain pegs currently used on Bitcoin done. So through federated consensus, which means that the peg supported by a group of vetted “custodians” who are in charge of holding the funds until they withdrawn from the sidechain.
However, Efforts to Develop Different Non-Federated Sidechain Peg Designs Have Continued
I’ll use Ruben Somsen’s Spacechain idea as an illustration here. It uses a blind merge mine design similar to Paul Sztorc’s one-way peg mechanism. This means that miners do not need to run additional software in order to get paid for mining the sidechain. Because coins can only enter the sidechain and never leave.
The Space chain Suggestion
In order to build the blocks for both chains and commit to them in the Bitcoin block header they are mining, merge mining requires miners to run the nodes of both the Bitcoin chain and whatever other chain they are mining. Blind merge mining makes use of the fact that, in practise. Bitcoin miners only need to commit to the block header of the other chain; the actual process of assembling the block for the other chain can handled by a third party.
By utilizing ANYPREVOUT (APO), Somsen’s suggested solution can ensure that only one block committed each block on the Bitcoin main chain while allowing open competition for anybody to build the following sidechain block. The ability to deploy spacechains made possible by Ruben’s suggestion without the need for a specific soft fork, which another advantage.
Eltoo/ANYPREVOUT suggested as a benefit to the Lightning Network since it enables channel factories and flexible statechains. Spacechains are only one of the numerous possibilities that would made possible by making ANYPREVOUT possible.
Bitcoin sidechain proposal
The basic tenet of his blind merge mining concept is that you may predefine a large number of transactions that always commit to replicating the same initial UTXO by using APO. Consider a single Satoshi UTXO, where each pre-created transaction ensures that the UTXO replicated as an output when the transaction completed. Consider this unique UTXO as a kind of flag that tells anyone browsing the main Bitcoin blockchain, “This where I discover a commitment to sidechain X’s blocks,”. One issue still unresolved, though: miner fees. There are no funds available to cover fees if that UTXO needs reproduced with the exact same sum.
Utilizing SIGHASH SINGLE (which only signs the input and its corresponding output) and SIGHASH ANYONECANPAY (which allows people to freely add additional inputs and outputs without invalidating the signature as long as the input/output using SIGHASH SINGLE is left as is, to not invalidate that signature) can help with this. Then, anyone can change the output and add an input while still paying the transaction’s miner costs.
The Sidechain Block’s Block Header Committed Using a Similar Approach
Anyone can modify the standard public key with the block header hash of the sidechain block in the same way that Taproot commits to the tree with various spending conditions by modifying the Merkle root of the tree. The block header can then revealed and relayed by sidechain nodes together with a reference to a transaction in the main chain to demonstrate that indeed mined. Then, just as on the main chain, sidechain nodes would perform all the routine validation to make sure the sidechain block complies with the correct consensus rules and propagate the actual blocks over the sidechain network.
If one of the transactions used to commit to the sidechain blocks on the main chain used to commit to an invalid block, or even entirely trash data, then two things can happen when sidechain nodes detect the commitment transaction used on chain. One of two things will happen: either the data 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 ignored; or two, an invalid block will spread across the sidechain network and become orphaned when it fails to pass validation checks.
Bitcoin Sidechain Proposal
Even if something was discovered later, it would still orphaned in this second option. Since subsequent blocks would not have built on it. Because it adheres to the same type of longest-chain logic as the main chain.
However, the issue of duplicate spending still exists. Any predetermined transaction used to commit to sidechain blocks might possibly be doublespent by someone with access to the private key used to create the marker UTXO, invalidating the entire set going forward.
By actually including the signature in the UTXO’s locking routine, this problem resolved. This secures the signature on the input and output and ensures that the marker UTXO will recreated in the subsequent transaction that uses it.
It is not possible to simply substitute a different signature and spend the UTXO to a different destination. Since that signature automatically passed and checked when the UTXO spent.
There still one issue resolved. Theoretically, it is conceivable to submit several transactions in a row into a single Bitcoin block, resulting in the confirmation of many sidechain blocks by miners in a single main chain block. This could used maliciously to attack the sidechain network via denial-of-service.
The marker UTXO script can modified to include a CHECKSEQUENCEVERIFY (CSV) relative time lock, which will ensure that only one transaction utilizing the marker UTXO can confirmed inside of a specific main chain block.
In Total, It Appears as Follows
It’s also important to keep in mind that two variations of this design can implemented either with CHECKTEMPLATEVERIFY (CTV) or completely without any alterations. These two design alternatives merely have unfavourable trade-offs.
With the signature embedded into the UTXO locking script, the CTV variation would exploit that functionality to commit to the chain of transactions using CTV rather than APO. CTV does not commit to any inputs other than itself, but it commits to all the outputs of a transaction that uses the CTV UTXO.
This means that you can add inputs to a CTV transaction but not outputs. So, much like in the APO design, you can bring your own charge, but you cannot include a commitment in the sidechain block header.
bitcoin sidechain proposal
Since you cannot create a new change output in that transaction, all of the input you add goes to fees, what we need to do is create a transaction entirely 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. Then, inside the transaction preparing the fee UTXO, we commit to a sidechain block header.
Therefore, the first step is to commit to a sidechain block header through a transaction that generates a fee-paying output. The second stage is to add the fee output as an input to the CTV transaction, which when approved “mines” the block for our particular sidechain. This variation appears as follows:
A sidechain for Bitcoin called Spacechains considered, and it provides a one-way peg mechanism using a blind merge mine design.
Source
The following variation just makes use of pre-signed transactions. It could implemented right away, but because to the restrictions of script, the person who develops the spacechain would be responsible for paying all transaction fees up front.
A sequence of transactions that begins with a single UTXO eventually produces two outputs. The first output is a marker UTXO that indicates that the series of transactions connected to a particular spacechain, and the second is a small value UTXO that is freely spendable by anyone and can have further inputs or outputs attached to it. Anyone can publicly commit to being the first to spend the second output from the spacechain transaction chain and use it to commit to their sidechain block header during this second transaction.
It is not possible to simply substitute a different signature and spend the UTXO to a different destination. Since that signature automatically passed and checked when the UTXO spent.
Bitcoin sidechain proposal
Because CTV does not permit adding new outputs in a transaction spending an input locked by CTV, the sidechain block had to be committed to in a secondary transaction in the CTV variation. Because adding new inputs or outputs to the pre-signed chain will change the transaction’s TXID and render all subsequent pre-signed transactions invalid, this variant necessitates the inclusion of a secondary transaction. This variation appears as follows:
A sidechain for Bitcoin called Spacechains is being considered, and it provides a one-way peg mechanism using a blind merge mine design.
The only drawback of this final option is that, if the person who pre-signed all of the transactions to be used for sidechain block commitments does not destroy the private keys used to do so, they can at any point double spend the chain’s current marker UTXO.
There you have it, then. It is possible to implement this most recent sidechain architecture on Bitcoin in three different methods, with the obvious limitation that the only one that may currently be taken involves needing the deletion of a private key.
Visit us on: www.bitcoiva.com