BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains



Summary:

In this email exchange, two individuals are discussing their different methods for implementing sidechains. The first individual expresses concern that the other's method would result in many unsuccessful bribe-attempts, taking up space in mainchain blocks. They suggest that miners may try to improve the situation by offering users the privilege of occupying transaction slot #2, introducing a cost friction that is pure deadweight loss. The second individual clarifies that their scheme forces the bribe to be in the earliest transaction and only occur once, unlike the other individual's scheme which doesn't refund the briber if the sidechain (but not the mainchain) reorganizes, creating additional risk. The first individual admits they don't understand this part, but clarifies that their scheme ensures a sidechain cannot reorganize unless the mainchain does, and suggests the other individual may be considering something like the Ethereum mutability feature, which they do not think is desirable in a sidechain. The second individual argues that their scheme is more space-efficient, requiring only one hash to be communicated compared to the other individual's two, and clarifies that there is no indicator byte in their scheme. They also ask about the ratchet, which is apparently for withdrawals from sidechain to mainchain, and suggest it should only appear in some of the sidechains.


Updated on: 2023-06-12T03:04:16.225003+00:00