Author: ZmnSCPxj 2017-09-15 04:34:12
Published on: 2017-09-15T04:34:12+00:00
ZmnSCPxj, a member of the Bitcoin Protocol Discussion group, has proposed using OP_WITHDRAWPROOFVERIFY with the sidechain-headers-on-mainchain approach. This approach would have no need for reorg proofs, as the mainchain can see in real-time which branch of the sidechain is being extended. Merge mining of sidechains is implied under this approach, with the sidechain's entire history recorded on the mainchain and visible to all nodes. One advantage of sidechain-headers-on-mainchain is a two-way peg between any two chains, whether side or main.The proposal also introduces a withdrawal transaction (WT) format that is compatible with an OP_WITHDRAWPROOFVERIFY Bitcoin transaction, where a lockbox UTXO on one chain is a WT on another chain. Sidechains do not need to follow the mainchain format for its normal transactions, only for WT transactions that move coins across chains. The message suggests that mainchain should also have its own "sidechain ID".However, there is a problem with the sidechain-headers-on-mainchain approach. In a sidechain, new sidecoin can be created for free if they are in a lockbox. Unlocking that lockbox would require a valid WT on the chain that the lockbox is dedicated to. A lockbox on one chain is a WT on the other chain. Thus, the fee paid by sidechain-only miners to mainchain miners will approach TRANSFERLIMIT / 288 to protect against theft, and then sidechain miners will be unable to replenish their maincoin stock (to pay for the blind-merge-mine) if they do not transfer *only* their sidecoins earned.The article discusses the implementation of side-to-side pegs in blockchain technology through the use of lockboxes as wrapped tokens (WT). A new parameter, wtFlag, is added to OP_WITHDRAWPROOFVERIFY and is used to determine if it is a WT. Sidechain consensus should require that freely-created lockboxes set this parameter to 0 so that a side block that creates free lockboxes where this parameter is non-zero is an invalid side block.The article also highlights how side-to-side pegs are just like side-to-main pegs. The author suggests that mainchain full nodes may even provide an RPC for checking OP_WITHDRAWPROOFVERIFY, so as to reduce risk that a sidechain breaks consensus due to buggy code.However, all is still not well with side-to-side pegs. If a sidechain dies, it can affect all other sidechains due to the interconnected nature of the system. The economic majority can kill a sidechain by spamming the headers slot or softforking to prevent the creation and spending of lockboxes. This requires all other sidechains to do the same. The article also mentions the increased risk for thieves attempting to steal from sidechains.Side-to-side pegs are useful for better liquidity and quick arbitrage between sidechains, but they make attacks more lucrative and require all pegs to have the same bitcoin value transferred. Drivechain cannot implement side-to-side pegs, and the author suggests that the pegging supported by drivechain may be less flexible than other options. Overall, the article highlights the complex and interconnected nature of blockchain technology and the importance of security measures.
Updated on: 2023-05-20T03:56:40.810797+00:00