📅 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
Adam Back [ARCHIVE] /
npub1ac…lswfj
2023-06-07 18:03:40
in reply to nevent1q…7l7f
Author Public Key
npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfjPublished at
2023-06-07 18:03:40Event JSON
{
"id": "b75f358a797ef64dece7a970524188335e467dc1a312903393860e207d67fbed",
"pubkey": "ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a",
"created_at": 1686161020,
"kind": 1,
"tags": [
[
"e",
"ceb90cc04617646a4ed9dd447660214398effadc094de82e24452613b40f4a5e",
"",
"root"
],
[
"e",
"8a985cf7f936ed4e45f01f3621c57e9384eede1db4b840556145a16ae3b480c7",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 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",
"sig": "c18bfc08d30811caf7454a06456ba8893bbe06e58a734e36ecf1f9644196da7893df8e06c36314d449e6f594c6922b01b0d6a397434ddffe5d47bba8fe8fc208"
}