Two Proposals for Bitcoin Sidechains
One of the biggest weaknesses of bitcoin is the inability of its blockchain to be scaled in order to facilitate the addition of features.
Bitcoin’s security consultant Sergio Demian Lerner went as far as comparing it with repairing an aircraft in flight.
Sidechains aim to enhance the versatility of the bitcoin network by allowing users to conduct transactions from the main bitcoin blockchain to other sidechains that operate under different guidelines.
The Potential behind Sidechains
Previously, adding new features onto the original bitcoin platform was difficult due to its original design.
Sidechains prove to be a solution that is capable of working successfully for the bitcoin network’s security problems.
This is because it will allow features such as private transactions and a smart contract system not unlike that of ethereum to be installed on the bitcoin blockchain without necessarily altering the blockchain itself.
Lerner is heading one of the teams working on the so-called “drivechain” proposals while another unrelated group that is headed by Bloq economist Paul Sztorc is working on another. He released the proposal for the code of the sidechain he is currently working on late last year shortly after Sztorc introduced them.
Sztorc and Lerner Insist on Working Separately
Despite the similar goals of both teams working on the separate sidechains, the two projects are using different ideologies to find ways with which to implement the opcode or the operation code to the currently existing bitcoin blockchain using an update called a soft fork.
A soft fork update looks like the ideal way to introduce features to the bitcoin blockchain as upgrading the blockchain will not require all the nodes.
As of now, however, there are no indications that the two teams will start working together.
Transferring bitcoin from one blockchain to another essentially does not translate to the actual transfer of the bitcoin.
Instead, it means that the bitcoins on the main blockchain are locked while on the sidechain that they are being transferred to, they become unlocked or activated to allow the user to access them from there.
The only distinction between sidechains and the proposed drivechains is who between the users and the miners control the information that facilitates the transfer of bitcoin from the main blockchain to the authorized sidechain.
In Lerner’s proposal, miners are the “algorithmic proxy custodians,” meaning that his drivechain relies on their awareness of the other sidechains involved.
This can also be achieved using programs that will alert the miners about the sidechains that are attached to the bitcoin network.
In summary, Lerner explained that the miners will be tasked with verifying the consent of the specific sidechain from which the command has come from and after proving consent, executing a coordination protocol that will ensure everyone is at par with the authenticity of the command.
If the consent is unanimous, payment can then be made using the locked funds.
Alongside Lerner’s drivechain proposal, there is another improvement to bitcoin called Segregated Witness that basically facilitates soft-forking.
It promises to add the new opcodes to the bitcoin system better than the previous soft-forking system, which was marred by a number of limitations.
The code for Segregated Witness, or SegWit, was added to the existing system earlier last month.
While the SegWit has been mostly received as a viable scaling solution for bitcoin it does carry other notable benefits.
Lerner’s drivechain proposal brings forth a new bitcoin script, the OP_COUNT_ACKS.
This serves to enhance the drivechain functionality in 600 lines of code.
Sztorc maintains that his project is going to be different from Lerner’s.
Despite the two having previously worked together, the complicated differences of their projects have necessitated that they both work on them separately.
Sztork’s main issue with Lerner’s implementation is that rather than using a copy of bitcoin, it opted to using the sidechain from Rootstock.
Sztorc feels that drivechains, being a new idea, should be developed first and individually before other ideas can be incorporated in order for it to grow.
Save for the implementation of the two opcodes, Sztorc has admitted that ultimately, there is little difference between the two proposals.