MIME-Version: 1.0
In-Reply-To: <hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com>
	<98d35291-5948-cb06-c46a-9d209276cee2@gmail.com>
	<GDZ42AMqaETJGYZovJzkVZkxZE3UmCQ8q5fFTAajV6sX2LHFol6iEYahkY_sMrPv5m11lHZvuKXmD_PwXa5_S7x18vcP1FkQr0ZBROxj6HE=@protonmail.com>
	<CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
	<hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Wed, 12 Jul 2017 09:39:17 -0400
Message-ID: <CAMZUoK==7OATOJ=46CYJWkq=WAXnJ8-JjvL25E1ijhnRbqj_Jg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114157f4895b5a05541ef21a"
Subject: Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
Precedence: list

--001a114157f4895b5a05541ef21a
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

In any case, let me propose actual improvements to the OP_BRIBEVERIFY
> proposal:
>
> 1.  Remove the necessity of coinbase commitments.  The miner commits to
> the sidechain_id and h* in the transaction that pays the OP_BRIBEVERIFY
> anyway.  That way the h* commitment occurs only once in the block, in the
> transaction that does the OP_BRIBEVERIFY.  In addition, there is no need to
> impose particular ordering on the coinbase outputs, which would be
> problematic as pointed out by others, for example if the miner is
> interested only in merge mining for sidechain id #35 and nobody else.
>
> 2.  When verifying a block, keep a set of sidechain ID's.  When processing
> a transaction in that block with OP_BRIBEVERIFY, check if the sidechain ID
> is in that set.  If not in that set, add it to that set and continue script
> processing.  If already in the set, fail the script processing.  This
> ensures that at most one OP_BRIBEVERIFY exists for each sidechain_id in a
> mainchain block.
>

At this point can we eliminate the need to use the scripting system at all
and just use a special, currently non-standard, OP_RETURN output to hold
the sidechain_id and h* instead?  We can soft fork in a rule that at most
one such output can appear in a block per sidechain_id.

--001a114157f4895b5a05541ef21a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev <span dir=3D"=
ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><span class=3D""></span><div>In any case, l=
et me propose actual improvements to the OP_BRIBEVERIFY proposal:<br></div>=
<div><br></div><div>1.=C2=A0 Remove the necessity of coinbase commitments.=
=C2=A0 The miner commits to the sidechain_id and h* in the transaction that=
 pays the OP_BRIBEVERIFY anyway.=C2=A0 That way the h* commitment occurs on=
ly once in the block, in the transaction that does the OP_BRIBEVERIFY.=C2=
=A0 In addition, there is no need to impose particular ordering on the coin=
base outputs, which would be problematic as pointed out by others, for exam=
ple if the miner is interested only in merge mining for sidechain id #35 an=
d nobody else.<br></div><div><br></div><div>2.=C2=A0 When verifying a block=
, keep a set of sidechain ID&#39;s.=C2=A0 When processing a transaction in =
that block with OP_BRIBEVERIFY, check if the sidechain ID is in that set.=
=C2=A0 If not in that set, add it to that set and continue script processin=
g.=C2=A0 If already in the set, fail the script processing.=C2=A0 This ensu=
res that at most one OP_BRIBEVERIFY exists for each sidechain_id in a mainc=
hain block.<br></div></blockquote><div><br></div><div>At this point can we =
eliminate the need to use the scripting system at all and just use a specia=
l, currently non-standard, OP_RETURN output to hold the sidechain_id and h*=
 instead?=C2=A0 We can soft fork in a rule that at most one such output can=
 appear in a block per sidechain_id.<br></div></div></div></div>

--001a114157f4895b5a05541ef21a--