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