Thinking of spacechains as a way to scale Bitcoin and add new features is not new. Before Satoshi vanished, sidechains and merge mined chains had a fundamental “ancestor” concept. A week after the paper was released in 2014, many of the individuals who later founded Blockstream made the original sidechain proposal. Simply put, that suggestion
Thinking of spacechains as a way to scale Bitcoin and add new features is not new. Before Satoshi vanished, sidechains and merge mined chains had a fundamental “ancestor” concept.
A week after the paper was released in 2014, many of the individuals who later founded Blockstream made the original sidechain proposal. Simply put, that suggestion was the notion of having the same set of miners mine two entirely different and unrelated chains without being able to transport anything between them. Simple payment verification (SPV) proofs would 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 (all of which can be read about in section four of the Bitcoin white paper).
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 are done through federated consensus, which means that the peg is supported by a group of vetted “custodians” who are in charge of holding the funds until they are 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 Stztorc’s one-way peg mechanism. This means miners do not need to run additional software to get paid for mining the sidechain because coins can only enter the sidechain and never leave.
THE SPACECHAIN SUGGESTION
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 uses the fact that, in practice, Bitcoin miners only need to commit to the block header of the other chain; a third party can handle the actual process of assembling the block for the other chain.
By utilizing ANY PREVOUT (APO), Somsen’s suggested solution can ensure that only one block can be committed to each block on the Bitcoin main chain while allowing open competition for anybody to build the following sidechain block. The ability to deploy spacechains is made possible by Ruben’s suggestion without needing a specific soft fork, which is another advantage. Eltoo/ANYPREVOUT is being suggested as a benefit to the Lightning Network since it enables channel factories and flexible statechains. Spacechains are just one of the many possibilities that would be made possible by making ANYPREVOUT possible.
The basic tenet of his blind merge mining concept is that you may predefine many transactions that always commit to replicating the same initial UTXO using APO. Consider a single Satoshi UTXO, where each pre-created transaction ensures that the UTXO will be replicated as an output when completed. Consider this unique UTXO as a kind of flag that tells anyone browsing the main Bitcoin blockchain, “This is where I discover a commitment to sidechain X’s blocks,” One issue is still unresolved, though: miner fees. No funds are available to cover costs if that UTXO needs to be reproduced with the same sum.
Utilizing SIGHASH SINGLE (which only signs the input and its corresponding output) and SIGHASH ANYONECANPAY (which allows people to freely. As long as the input/output utilizing SIGHASH SINGLE is left as is, you can add other inputs, and it works without the signature being invalid. Is, not to invalidate that signature) can help with this. Then, anyone can change the production and add an input while paying the transaction’s nominal costs.
The sighash of a function is calculated by taking the first four bytes of the hash of “<function name>(<function input types>)”. For example, the sighash of the ERC20 transfer function is the first four bytes of the hash of “transfer(address,uint256)”.
— smartcontracts (✨🔴_🔴✨) (@kelvinfichter) August 10, 2021
The sidechain block’s block header is 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 engages the tree with various spending conditions by adjusting the Merkle root of the tree. The block header can then be revealed and relayed by sidechain nodes regarding a transaction in the main chain to demonstrate that it was indeed mined. Then, just as on the main chain, sidechain nodes would perform all the routine validation to ensure the sidechain block complies with the correct consensus rules and propagate the actual blocks over the sidechain network.
Suppose, On the main chain, one of the transactions used to commit to the sidechain blocks committed to an invalid partnership or even entirely trash data. In that case, two things can happen when sidechain nodes detect the commitment transaction used on the chain: If the information is never disclosed, the following sidechain block will build upon and commit to the previous one. A partnership that was announced and the unrevealed commitment will be ignored; or two, an invalid block will spread across the sidechain network and become orphaned when it fails to pass validation checks. Even if something were discovered later, it would still be orphaned in this second option since subsequent blocks would not have built on it because it adheres to the same long-chain logic as the main chain.
However, the issue of duplicate spending still exists. Any predetermined transaction to commit to sidechain blocks might be double spent by someone with access to the private key used to create the marker UTXO, invalidating the entire set.
This problem is resolved by including the signature in the UTXO’s locking routine. This secures the signature on the input and output and ensures that the marker UTXO will be recreated in the subsequent transaction that uses it. It is impossible to substitute a different signature and spend the UTXO to another destination since that signature will be automatically passed and checked when the UTXO is finished.
One problem needs to be solved still. Theoretically, it is conceivable to submit several transactions in a row into a single Bitcoin block, confirming many sidechain blocks by miners in a single main chain block. This could be used maliciously to attack the sidechain network via denial-of-service.
The marker UTXO script can be modified to include a CHECKSEQUENCEVERIFY (CSV) relative time lock, ensuring that only one transaction utilizing the marker UTXO can be confirmed inside a specific main chain block. It’s also important to remember that two variations of this design can be implemented either with CHECKTEMPLATEVERIFY (CTV) or entirely without any alterations. These two design alternatives merely have unfavorable trade-offs.
With the signature embedded into the UTXO locking script, the CTV variation would exploit the inherent capability to use CTV to commit to the chain of transactions rather than APO. CTV does not commit to any inputs other than itself but to all the outputs of a transaction that uses the CTV UTXO.
This means you can add inputs to a CTV transaction but not outputs. So, much like in the APO design, you can bring your charge, but you cannot include a commitment in the sidechain block header.
Since you cannot create a new change output in that transaction, all the input you add goes to fees. We need to complete a transaction outside the chain of CTV transactions for the sidechain commitment to make a UTXO that is just enough to pay the cost 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 achieve a sidechain block header through marketing 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. The following variation makes use of pre-signed transactions. It could be implemented immediately, but because of the restrictions of the script, the person who develops the spacechain would be responsible for paying all transaction fees upfront.
A series of events that starts with a single UTXO produces two outputs. The first output is a marker UTXO, indicating that the sequence of transactions is connected to a particular spacechain. 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 achieve their sidechain block header during this second transaction.
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 secondary marketing in the CTV variation. Because adding further information 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.
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 look at any point to double-spend the chain’s current marker UTXO.
Also, read –The economy of knowledge Fiat Currency
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 the deletion of a private key.
