rich1.0npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfjhttps://nostr.ae/npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfjnjumphttps://nostr.ae📅 Original date posted:2017-06-28 📝 Original message:On 27 June 2017 at 22:20, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > On Wednesday 28 June 2017 12:37:13 AM Chris Stewart via bitcoin-dev wrote: >> BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given >> critical hash is included at the given vout index in the coinbase >> transaction the script evaluates to true. Otherwise, the script will fail. >> >> This allows sidechains to be merged mined against >> bitcoin without burdening bitcoin miners with extra resource requirements. > > I don't see how. It seems like the logical outcome from this is "whoever pays > the most gets the next sidechain block"... That's not particularly useful for > merge mining. Maybe that's phrased badly but the point of the "blind merge mining" is just that the sidechain fees are paid in main chain bitcoin (rather than in sidechain bitcoin). That means that a miner who solo mines the main chain could still mine the sidechain by requesting a block-proposal from a trusted sidechain fullnode. The sidechain fullnode would actually pay the mainchain fee, and pay itself the sidechain fees as part of the side-chain block-proposal. This was viewed as less centralising than forcing miners to directly process sidechain blocks, which could in principle be bandwidth and CPU expensive to process, construct and validate. Adam