Published on: 2017-07-13T20:45:13+00:00
In a Bitcoin development mailing list conversation, Chris Stewart asked for clarification on the purpose of 'Ratchet' in BMM (blind merge mining). Paul explained that BMM aims to validate sidechains with minimal validation on the mainchain. They introduced a new rule that requires h* to be accompanied by the modulus of its sidechain block number (BlockMod) to ensure accurate validation. The mainchain also has a rule that restricts the new BlockMod to a specific range relative to the old BlockMod. Additionally, BMM implemented a rule that prevents payment of bribes unless the sidechain block has been buried by a certain number of sidechain blocks to prevent orphaning.The discussion continued with Chris seeking opinions on Lightning bribes. Paul argued that in equilibrium, the coinbase version may be more efficient than the OP_RETURN version. A miner can redeem an OP Bribe through the Lightning Network. Sidechains running in SPV mode know where to find the necessary information to discover the longest chain. However, the OP_RETURN version requires a spend in the UTXO set and additional data storage.The conversation then shifted to the efficiency of Bitcoin in equilibrium, including Lightning Network or similar solutions. Two versions of sidechains were discussed: coinbase and OP_RETURN. The coinbase version involves a single event per N, with hash commitments and ratchet's block counter instances per block. The OP Bribe can be negotiated through the Lightning Network. In the OP_RETURN version, there are also hash commitments per block, but it requires a spend in the UTXO set and extra data storage to locate the necessary information.The email thread also included discussions on the implementation of sidechains and blind merge mining. The sender argued that a block list node is valid only if its block is valid, which seemed to contradict the "blind" aspect of blind merge mining. However, they explained their scheme, which includes storing sidechain block headers on the mainchain using OP_RETURN data. The sidechain block headers are reduced to only the previous-block-header commitment and the current-block-data commitment. If the current-block-data is invalid, another sidechain block header based on the previous block header will be searched for.Another topic discussed was the issue of replaceability of bribe transactions. Several proposals were made, including having the amount in the output instead of the fee and replacing the bribe transaction with a double spend transaction. There were also suggestions to remove the necessity of coinbase commitments and use a special OP_RETURN output or include the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY.The conversation also touched upon blind merge mining and the need to ensure that a sidechain cannot be reorged without the mainchain. Proposals were made to improve the OP_BRIBEVERIFY proposal by removing the necessity of coinbase commitments and using the hash of the sidechain's name or genesis block to identify them instead of numbering them. It was suggested that miners could maximize their fee income by imposing a blocksize limit on themselves and orphaning non-compliant blocks.In another discussion, the sender proposed improvements to the OP_BRIBEVERIFY proposal. They suggested removing the need for coinbase commitments and having the miner commit to the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY. Another improvement was to keep a set of sidechain IDs when verifying a block and fail the script processing if an OP_BRIBEVERIFY already exists for that specific sidechain ID. There was also a suggestion to eliminate the use of scripting altogether and use a special non-standard OP_RETURN output to hold the sidechain ID and h*. A soft fork rule could be implemented to limit this output to one per block per sidechain ID.The email thread discussed the challenges of blind merge mining and ensuring the validity of sidechain blocks. The sender argued that a block list node is only valid if its block is valid, which seemed contradictory to the blind merge mining concept. However, they explained their scheme, which involves storing the OP_RETURN data representing sidechain block headers on the mainchain. The sender also proposed the use of a ratchet system to link h* data from bribes to sidechain blocks.In a conversation between Chris Stewart, Russell O'Connor, and ZmnSCPxj, they discussed the issue of replaceability of bribe transactions. They proposed different solutions, such as having the amount in the output instead of the fee or using a double spend transaction to replace the bribe. They also discussed the issue of coinbase commitments and searching for drivechain commitments in the Bitcoin blockchain. Suggestions were made to remove the necessity of coinbase commitments and have the miner commit to the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY.The discussion also covered blind merge mining and the need to ensure that a sidechain cannot be reorged without the mainchain.
Updated on: 2023-08-01T21:12:55.577190+00:00