From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, Chris Stewart <chris@suredbits.com>
Date: Wed, 28 Jun 2017 05:20:27 +0000
User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.32; x86_64; ; )
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
In-Reply-To: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201706280520.29105.luke@dashjr.org>
Subject: Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
	Merge Mined drivechains
Precedence: list

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.

> This enables sidechains in Bitcoin.

There are different kinds of sidechains...

Federated peg: this already works on Bitcoin.
SPV/SNARK peg: this isn't enabled by your BIP.
Drivechains: this isn't enabled by your BIP.

How do you say this enables any kind of sidechain?

> A new block rule is added which requires that the miner's coinbase reward
> be at index 0 in the coinbase transaction's output vector.
> 
> It also fixes the witness commitment output to be at index 1 of the
> coinbase transaction's output vector.

This is unacceptable, for reasons Greg already pointed out.

> This document is placed in the public domain.

Note that this is not acceptable for BIPs anymore.

https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#BIP_licensing