Author: Chris Stewart 2017-07-04 15:06:06
Published on: 2017-07-04T15:06:06+00:00
In this email thread, the discussion revolves around the implementation of sidechains and blind merge mining. The sender of the email argues that in their scheme, a block list node is valid only if its block is valid which seems to contradict the "blind" part of blind merge mining. However, they explain that their scheme includes the OP_RETURN data as the sidechain block headers stored on the mainchain. This allows for the reduction of the sidechain block headers to only the previous-block-header commitment and the current-block-data commitment to save space. If the current-block-data is invalid, the sidechain block header is invalid, and another sidechain block header based on the previous block header will be searched for.The sender also points out that both their scheme and the recipient's scheme need to include two 32 bit hashes in the blockchain. In response, the recipient explains that their scheme requires only one hash to be communicated (plus an indicator byte and a ~2 byte counter for the ratchet), whereas the sender's scheme requires two. The discussion then shifts towards the topic of sidechain reorgs, with the recipient arguing that their proposal is more desirable because it follows what actually happens in the bitcoin mining process where chain splits can occur when miners simultaneously find a block. They replace PoW with a bribe, which is conceptually similar to PoW. The sender raises concerns about rich attackers stalling mining progress on the drivechain, but the recipient argues that the same argument can be made with a rich miner on the bitcoin blockchain. Finally, the discussion touches upon the ratchet system, which links the h* data from bribes to sidechain blocks. The recipient explains that their OP_RETURN scheme is superior as the sidechain block headers are visible directly on the mainchain, and the mainchain node does not even need to be "local".
Updated on: 2023-06-12T03:05:29.820661+00:00