path: root/22/72d3e9c10dc6f1d2464bfee499e15849b6873e

Return-Path: <bounce+33760e.2c141-bitcoin-dev=lists.linuxfoundation.org@suredbits.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 08BFF3EE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Jul 2017 18:02:44 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from so254-16.mailgun.net (so254-16.mailgun.net [198.61.254.16])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9CB316F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Jul 2017 18:02:42 +0000 (UTC)
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=suredbits.com;
	q=dns/txt; 
	s=mailo; t=1499882562; h=Content-Type: Cc: To: Subject: Message-ID:
	Date: From: References: In-Reply-To: MIME-Version: Sender;
	bh=nQf4dnCHxiPKEQq65Rfj3aTtRQ7S4loSPn11ZhNMX0Y=;
	b=hfdono+qZhgONgGQ5aSiS6hKhYC8h0VxnmEE4bVH2Ny/oO5HbjK8jycIbTnqXwijprVgZ3Bu
	q2JXKUfE26jzzau9IQYSUxkTB8uNyS3/0itJ4VcSieKP4r0rKVxtVQxkyYjf+2IBUjwL6kxO
	2+J/ZG6DMPgILZyM3FbI0qC5md0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=suredbits.com; s=mailo;
	q=dns; h=Sender: MIME-Version: In-Reply-To: References: From: Date:
	Message-ID: Subject: To: Cc: Content-Type;
	b=f7g3plaaUrhukQwSYN7NDystvbvObwXVOkQQ1u3p7iOtXrre60a2Cyoozl03Vqrr6L0v5Z
	EBIHkegs5IjVlxwLrrN5vfTMLKjn1vqdS6tspzpztA+HrO7OqfB4J9Nc4++q+lw/UDGLLjTM
	ouOwB0kJ+DG8mnKq8wtnY92aZLyqc=
Sender: chris@suredbits.com
X-Mailgun-Sending-Ip: 198.61.254.16
X-Mailgun-Sid: WyI5MGYzNyIsICJiaXRjb2luLWRldkBsaXN0cy5saW51eGZvdW5kYXRpb24ub3JnIiwgIjJjMTQxIl0=
Received: from mail-it0-f47.google.com (mail-it0-f47.google.com
	[209.85.214.47])
	by mxa.mailgun.org with ESMTP id 59666438.7fe7185bcc70-smtp-out-n01;
	Wed, 12 Jul 2017 18:02:32 -0000 (UTC)
Received: by mail-it0-f47.google.com with SMTP id k192so19387953ith.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Jul 2017 11:02:32 -0700 (PDT)
X-Gm-Message-State: AIVw111RZbHhVhwBXkEGWL5Gheg10hlt/4dgkZ/cFd4Zw6J6Amvp9fHP
	gf2H3HlIiYVOWn8dewjzYeN8I0c1DQ==
X-Received: by 10.107.134.141 with SMTP id q13mr6050127ioi.191.1499882551372; 
	Wed, 12 Jul 2017 11:02:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.174.131 with HTTP; Wed, 12 Jul 2017 11:02:30 -0700 (PDT)
In-Reply-To: <CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.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>
	<CAMZUoK==7OATOJ=46CYJWkq=WAXnJ8-JjvL25E1ijhnRbqj_Jg@mail.gmail.com>
	<CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Wed, 12 Jul 2017 13:02:30 -0500
X-Gmail-Original-Message-ID: <CAGL6+mE9TF=LeNwN2a6Ky+B=jqmW=1HqGOj6bPq2G3Aq8+FZAw@mail.gmail.com>
Message-ID: <CAGL6+mE9TF=LeNwN2a6Ky+B=jqmW=1HqGOj6bPq2G3Aq8+FZAw@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113eacdeae09000554229e44"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 12 Jul 2017 19:25:17 +0000
Subject: Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jul 2017 18:02:44 -0000

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

Hi Russell/ZmnSCPxj,

I think you guys are right. The only problem I can see with it is
replaceability of the bribe transaction. If the 'Bribe' is the fee on the
transaction it isn't clear to me what the best way to replace/remove it is.

If we have the amount in the output (instead of the fee) we can construct a
contract like this

OP_IF <id> <hash> OP_BV OP_ELSE OP_DUP OP_HASH160 <pubkey hash>
OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF

That way, if the miner does *not* include your bribe, he is *still*
incentived to include your redemption.

If we decide to only an OP_RETURN output, we can replace the 'bribe'
transaction with a transaction that double spends the prevout. Thus if your
'bribe' transaction is not included in a block, a miner can still include
your double spend transaction to refund yourself (and a miner gets to
collect his normal mining fee).

I'm not 100% sure if there are mempool policies that would reject this
double spend tx or not -- but I guess this is an implementation detail not
a high level design one.

Also if there is not a commitment in the coinbase transaction it may be
harder to search for drivechain commitments. I've been floating around the
idea of a 'drivechain commitment tx' so we could easily see where all of
the voting is happening for withdrawal transactions -- but that is very
much up in the air.

On Wed, Jul 12, 2017 at 1:00 PM, Chris Stewart <stewart.chris1234@gmail.com>
wrote:

> Hi Russell/ZmnSCPxj,
>
> I think you guys are right. The only problem I can see with it is
> replaceability of the bribe transaction. If the 'Bribe' is the fee on the
> transaction it isn't clear to me what the best way to replace/remove it is.
>
> If we have the amount in the output (instead of the fee) we can construct
> a contract like this
>
> OP_IF <id> <hash> OP_BV OP_ELSE OP_DUP OP_HASH160 <pubkey hash>
> OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF
>
> That way, if the miner does *not* include your bribe, he is *still*
> incentived to include your redemption.
>
> If we decide to only an OP_RETURN output, we can replace the 'bribe'
> transaction with a transaction that double spends the prevout. Thus if your
> 'bribe' transaction is not included in a block, a miner can still include
> your double spend transaction to refund yourself (and a miner gets to
> collect his normal mining fee).
>
> I'm not 100% sure if there are mempool policies that would reject this
> double spend tx or not -- but I guess this is an implementation detail not
> a high level design one.
>
> Also if there is not a commitment in the coinbase transaction it may be
> harder to search for drivechain commitments. I've been floating around the
> idea of a 'drivechain commitment tx' so we could easily see where all of
> the voting is happening for withdrawal transactions -- but that is very
> much up in the air.
>
> -Chris
>
> On Wed, Jul 12, 2017 at 8:39 AM, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> 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.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

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

<div dir=3D"ltr"><div class=3D"gmail-ajy" tabindex=3D"0"><img class=3D"gmai=
l-ajz" id=3D"gmail-:25p" src=3D"https://mail.google.com/mail/u/0/images/cle=
ardot.gif" alt=3D""></div><div><div><div>Hi Russell/ZmnSCPxj,<br><br></div>=
<div>I
 think you guys are right. The only problem I can see with it is=20
replaceability of the bribe transaction. If the &#39;Bribe&#39; is the fee =
on=20
the transaction it isn&#39;t clear to me what the best way to replace/remov=
e
 it is. <br><br></div>If we have the amount in the output (instead of the f=
ee) we can construct a contract like this <br><br></div>OP_IF &lt;id&gt; &l=
t;hash&gt; OP_BV OP_ELSE OP_DUP OP_HASH160 &lt;pubkey hash&gt; OP_EQUALVERI=
FY OP_CHECKSIG OP_ENDIF<br><br></div><div>That way, if the miner does *not*=
 include your bribe, he is *still* incentived to include your redemption. <=
br><br>If
 we decide to only an OP_RETURN output, we can replace the &#39;bribe&#39;=
=20
transaction with a transaction that double spends the prevout. Thus if=20
your &#39;bribe&#39; transaction is not included in a block, a miner can st=
ill=20
include your double spend transaction to refund yourself (and a miner=20
gets to collect his normal mining fee).=C2=A0 <br><br></div><div>I&#39;m no=
t 100%
 sure if there are mempool policies that would reject this double spend=20
tx or not -- but I guess this is an implementation detail not a high=20
level design one. <br><br></div>Also if there is not a commitment=20
in the coinbase transaction it may be harder to search for drivechain=20
commitments. I&#39;ve been floating around the idea of a &#39;drivechain=20
commitment tx&#39; so we could easily see where all of the voting is=20
happening for withdrawal transactions -- but that is very much up in the
 air.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed=
, Jul 12, 2017 at 1:00 PM, Chris Stewart <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:stewart.chris1234@gmail.com" target=3D"_blank">stewart.chris1234@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div><div><div>Hi Russell/ZmnSCPxj,<br><br></div><div>I think you guys =
are right. The only problem I can see with it is replaceability of the brib=
e transaction. If the &#39;Bribe&#39; is the fee on the transaction it isn&=
#39;t clear to me what the best way to replace/remove it is. <br><br></div>=
If we have the amount in the output (instead of the fee) we can construct a=
 contract like this <br><br></div>OP_IF &lt;id&gt; &lt;hash&gt; OP_BV OP_EL=
SE OP_DUP OP_HASH160 &lt;pubkey hash&gt; OP_EQUALVERIFY OP_CHECKSIG OP_ENDI=
F<br><br></div><div>That way, if the miner does *not* include your bribe, h=
e is *still* incentived to include your redemption. <br><br>If we decide to=
 only an OP_RETURN output, we can replace the &#39;bribe&#39; transaction w=
ith a transaction that double spends the prevout. Thus if your &#39;bribe&#=
39; transaction is not included in a block, a miner can still include your =
double spend transaction to refund yourself (and a miner gets to collect hi=
s normal mining fee).=C2=A0 <br><br></div><div>I&#39;m not 100% sure if the=
re are mempool policies that would reject this double spend tx or not -- bu=
t I guess this is an implementation detail not a high level design one. <br=
><br></div><div>Also if there is not a commitment in the coinbase transacti=
on it may be harder to search for drivechain commitments. I&#39;ve been flo=
ating around the idea of a &#39;drivechain commitment tx&#39; so we could e=
asily see where all of the voting is happening for withdrawal transactions =
-- but that is very much up in the air.<span class=3D"HOEnZb"><font color=
=3D"#888888"><br></font></span></div><span class=3D"HOEnZb"><font color=3D"=
#888888"><div><br></div><div>-Chris<br></div></font></span></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On W=
ed, Jul 12, 2017 at 8:39 AM, Russell O&#39;Connor via bitcoin-dev <span dir=
=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;</span> wrot=
e:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><di=
v dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
><span>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" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt;</span> wrot=
e:<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span></span><div>In any case, let=
 me propose actual improvements to the OP_BRIBEVERIFY proposal:<br></div><d=
iv><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 pa=
ys the OP_BRIBEVERIFY anyway.=C2=A0 That way the h* commitment occurs only =
once in the block, in the transaction that does the OP_BRIBEVERIFY.=C2=A0 I=
n addition, there is no need to impose particular ordering on the coinbase =
outputs, which would be problematic as pointed out by others, for example i=
f the miner is interested only in merge mining for sidechain id #35 and nob=
ody else.<br></div><div><br></div><div>2.=C2=A0 When verifying a block, kee=
p 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 processing.=C2=
=A0 If already in the set, fail the script processing.=C2=A0 This ensures t=
hat at most one OP_BRIBEVERIFY exists for each sidechain_id in a mainchain =
block.<br></div></blockquote><div><br></div></span><div>At this point can w=
e eliminate the need to use the scripting system at all and just use a spec=
ial, 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 c=
an appear in a block per sidechain_id.<br></div></div></div></div>
<br></div></div><span class=3D"">______________________________<wbr>_______=
__________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>

--001a113eacdeae09000554229e44--