Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 08BFF3EE for ; 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 ; 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 ; 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: References: <2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com> <98d35291-5948-cb06-c46a-9d209276cee2@gmail.com> From: Chris Stewart Date: Wed, 12 Jul 2017 13:02:30 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 OP_BV OP_ELSE OP_DUP OP_HASH160 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 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 OP_BV OP_ELSE OP_DUP OP_HASH160 > 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
3D""
Hi Russell/ZmnSCPxj,

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

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

OP_IF <id> &l= t;hash> OP_BV OP_ELSE OP_DUP OP_HASH160 <pubkey hash> OP_EQUALVERI= FY OP_CHECKSIG OP_ENDIF

That way, if the miner does *not*= include your bribe, he is *still* incentived to include your redemption. <= br>
If we decide to only an OP_RETURN output, we can replace the 'bribe'= =20 transaction with a transaction that double spends the prevout. Thus if=20 your 'bribe' 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

I'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.

Also if there is not a commitment=20 in the coinbase transaction it may be harder to search for drivechain=20 commitments. I've been floating around the idea of a 'drivechain=20 commitment tx' 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.

On Wed= , Jul 12, 2017 at 1:00 PM, Chris Stewart <stewart.chris1234@gmai= l.com> wrote:
Hi Russell/ZmnSCPxj,

I think you guys = are right. The only problem I can see with it is replaceability of the brib= e transaction. If the 'Bribe' is the fee on the transaction it isn&= #39;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_EL= SE OP_DUP OP_HASH160 <pubkey hash> OP_EQUALVERIFY OP_CHECKSIG OP_ENDI= F

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

If we decide to= only an OP_RETURN output, we can replace the 'bribe' transaction w= ith a transaction that double spends the prevout. Thus if your '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

I'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.
Also if there is not a commitment in the coinbase transacti= on it may be harder to search for drivechain commitments. I've been flo= ating around the idea of a 'drivechain commitment tx' 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.

-Chris

On W= ed, Jul 12, 2017 at 8:39 AM, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrot= e:


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

In any case, let= me propose actual improvements to the OP_BRIBEVERIFY proposal:

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.

2.=C2=A0 When verifying a block, kee= p a set of sidechain ID'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.

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.

_____________________________________= __________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev



--001a113eacdeae09000554229e44--