Sidechain headers on mainchain (unification of drivechains and spv proofs)



Summary:

The proposed solution for sidechains involves the integration of drivechains, blind merged mining, and SPV proofs. The author suggests that instead of using large SPV proofs, miner voting can be used to control the unlocking of mainchain funds in a sidechain. Merged mining is proposed for sidechain mining to maintain mainchain security. The "sidechain headers in mainchain" idea is introduced, where the sidechain header chain is embedded in the mainchain itself. This eliminates the need for SPV proofs to present new data to the mainchain, and reorg proofs are suggested to show that a previous SPV proof is invalid.However, the author raises concerns about the potential for centralization risk if miners participating in sidechains are required to check the sidechain in full. A possible solution is to require validation of SPV proofs on the mainchain without trusting anyone and without running sidechain software. The proposal aims to address issues with drivechains failing due to the ability of a group with >51% of mainchain miners to steal sidechain lockboxes. The process of creating a sidechain involves the creation of a data structure containing a sidechain block height, a side-to-main peg pointer, links to other forks of the same sidechain ID, and the top block header hash of the sidechain. The mainchain node creates this data structure, which is updated when the sidechain's block header is the direct descendant of the current sidechain tip. If there is a side-to-main peg on the sidechain block header and the pointer is NULL, it is initialized and given a block height at which the side-to-main peg exists. If there is already a pending side-to-main peg, the mainchain block is rejected. If the sidechain header for a mainchain block does not extend the most recent sidechain tip, a sidechain split condition is detected. In this case, a copy of the data structure for the tallest fork is created, and it is rolled back until the split point is reached. If there is only a single data structure for a sidechain, the sidechain is single-chained and not under attack. When there are multiple forks of a sidechain, the mainchain node keeps track of all of them. Mainchain fullnodes validate side-to-main transfers but do not need to run sidechain software. Sidechain users should protect themselves by ensuring they have mainchain miners who will protect the sidechain by only extending the valid longest sidechain, and by spending maincoin on OP_BRIBEVERIFY. A protector can also be hired to protect the sidechain via the OP_BRIBEVERIFY vulnerability. Such a protector will be paid in sidechain funds, at a premium, for use of its mainchain funds.Mainchain miners who wish to take on a "protector" role can act as if they are being paid OP_BRIBEVERIFY for the sidechain they wish to protect. However, mainchain miners should not treat sidechain rules at the same level as mainchain rules. Finally, the number 288 is a parameter that can be endlessly debated.


Updated on: 2023-05-20T03:40:14.582605+00:00