MIME-Version: 1.0
Reply-To: adam@cypherspace.org
In-Reply-To: <201706280520.29105.luke@dashjr.org>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<201706280520.29105.luke@dashjr.org>
From: Adam Back <adam.back@gmail.com>
Date: Tue, 27 Jun 2017 22:28:31 -0700
Message-ID: <CALqxMTE7jXdnXvsXoyTqTv6m1xQDQXCXsu7mh3oHmw8aXhrB0w@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: text/plain; charset="UTF-8"
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
Precedence: list

On 27 June 2017 at 22:20, Luke Dashjr via bitcoin-dev
<bitcoin-dev@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