Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CF452B7A for ; Wed, 24 May 2017 17:35:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f45.google.com (mail-pg0-f45.google.com [74.125.83.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2089916D for ; Wed, 24 May 2017 17:35:23 +0000 (UTC) Received: by mail-pg0-f45.google.com with SMTP id u187so68931581pgb.0 for ; Wed, 24 May 2017 10:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=AryL7kW9AevQ8k4BSIL6WSx3du2dq2WjbQowSlJkZcU=; b=nnFiROJJ04X4h29bz8GOWw9YkRqdFJGccaixrnQwZBF14Uo5T4+VhTzsNst/I/NgMs 7/QGaCMp1vogDR5todzcT9aFeSTeYiOIGIeEs3T5thJXhy/O66c2pFAAymW2IlBfEscn HPaeNufWB5oEpbkvqjxhruGiLPJwESaDI92o7zZPAkhgglueO42EHsipWNw06lunrpax 8Bn8CnA0wAFpRdYMZHrksjgyKWvC0nmMzFD5kAyFDLJo8T9qnaIXt9m0YSnCrLhF6EqH 6ESOIBRGOoyQbj7GoEFdzruIYk6AoMNo3nmlS2bvazpF91NbpfCIzMQ12ANy+b6QkVza MkCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AryL7kW9AevQ8k4BSIL6WSx3du2dq2WjbQowSlJkZcU=; b=azW643UG4njIdu1y8WIsNLh1ihgSBhYawzCeS36WAwQZHsP76m9MYWmKLlAKDYJWt8 ZbKk11fDg80pVKkHtflAJvBQswNOeus+oySlBnJT31RdJuLZn1hXnAMhH4SWhbMZhY2u MErYH4JnshPn4pv/EMr3hw4Pg7xNosDwb6T8yx8POBOzOBRG2WvVo3vs5sUEQ6lggLl7 uhROB8PK/cHrO5Rd7XtDSZDhy/S4mlN6hV8enOgb/6QvNGu+nrNIMJTdSmgVvgxkrMwa rV7dM7/+8kIkFJMmdfQQRy0q+jKln9p3Aex5ZGkZ7ZR+Ul1kVH86OMmjcEcyKHo1WtDO KScQ== X-Gm-Message-State: AODbwcB6rZ2ZfVppxFVzT/7smWekxsCjgiHuu10oJ204EI1EXJhZA0WY yIwsdCNd+GpgQej7JjU= X-Received: by 10.84.176.3 with SMTP id u3mr28219638plb.119.1495647322343; Wed, 24 May 2017 10:35:22 -0700 (PDT) Received: from [192.168.1.109] (c-73-240-45-119.hsd1.or.comcast.net. [73.240.45.119]) by smtp.gmail.com with ESMTPSA id 80sm9076695pfx.80.2017.05.24.10.35.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 10:35:21 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> <141a0cd1-9d4f-c137-a349-17248f9cafd4@gmail.com> From: CryptAxe Message-ID: <2b5567e1-2b6d-db4a-0f44-c66a24fe28ea@gmail.com> Date: Wed, 24 May 2017 10:32:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------28869D4A0AC941D5998AB3B2" Content-Language: en-US X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no 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, 24 May 2017 17:38:00 +0000 Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion 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, 24 May 2017 17:35:23 -0000 This is a multi-part message in MIME format. --------------28869D4A0AC941D5998AB3B2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Your assumptions of the bribe process are indeed correct you seem to have a pretty good handle on all of that. Hopefully I can clear up a few things. BMM among other things is still a work in progress so you'll have to wait a bit longer before any reorg code is on github. The "ratchet" system on github right now just has the block hash part of the critical hash script. The completed version needs to check the sidechain number (ID) and the sidechain block number in the script. Also the block number can only change by +1 or -1, so when a new h* is added to the queue it must be compared to the most recent h* in the queue. std::abs(queue.back().nHeight - ToAdd.nHeight) must equal 1. Here's what the script looks like on github: Note that the h* is just a block hash. script << OP_RETURN << ToByteVector(h*); Here's what I'm testing right now as I'm working on BMM: script << OP_RETURN << CScriptNum::serialize(nSidechain) << CScriptNum(nSidechainHeight) << ToByteVector(sidechain blinded block hash h*) One other thing I want to make sure is clear enough is that the block number in the critical hash script is a sidechain block number, not a mainchain block number. That might mess up the new format you have suggested for bribes. And the reason a sidechain miner would want to refund their bribe is if the h* doesn't end up in a coinbase after a number of blocks, making their blinded block on the sidechain invalid as tx's will be spent in other blocks that do get their h* in a coinbase. We were thinking about making bribe outputs have a maturity period like generated coins. You think that they should be locked for >100 blocks by having OP_BRIBE also check the lock time? I like all of your suggestions so far, thank you for taking a look! On 05/24/2017 03:05 AM, Tier Nolan via bitcoin-dev wrote: > On Wed, May 24, 2017 at 9:50 AM, Tier Nolan > wrote: > > OP_BRIBE_VERIFY could then operate as follows > > OP_BRIBE_VERIFY > > This causes the script to fail if > does not match the block height, or > is not the hash for the sidechain with > , or > there is no hash for that sidechain in the block's coinbase > > > I was thinking more on the process for these transactions. > > I assume that the process is > > - sidechain miner broadcasts transaction with OP_BRIBE output > - this transaction ends up in the memory pool of miners > - Miners add the transaction to their next block > - Miners add a transaction which spends the output to one of their own > addresses > > I think you need an additional rule that OP_BRIBE checks fails unless > the output is locked 100 or more blocks. > > The output script would end up something like > > IF > OP_BRIBE_VERIFY > ELSE > OP_CHECKSIG > ENDIF > > This output acts like "anyone can spend" for the one block height. > Otherwise, only the sidechain miner can spend the output. > > This allows the sidechain miner to reclaim their coins if the > transaction ends up in a different block. > > OP_BRIBE_VERIFY would have an additional rule > > The script to fails if > one or more of the transaction outputs start with something other > than the template > does not match the block height, or > is not the hash for the sidechain with > , or > there is no hash for that sidechain in the block's coinbase > > The template is > <100> OP_CHECKSEQUENCE_VERIFY > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------28869D4A0AC941D5998AB3B2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Your assumptions of the bribe process are indeed correct you seem to have a pretty good handle on all of that.

Hopefully I can clear up a few things. BMM among other things is still a work in progress so you'll have to wait a
bit longer before any reorg code is on github. The "ratchet" system on github right now just has the block hash
part of the critical hash script. The completed version needs to check the sidechain number (ID) and the sidechain
block number in the script. Also the block number can only change by +1 or -1, so when a new h* is added to the
queue it must be compared to the most recent h* in the queue. std::abs(queue.back().nHeight - ToAdd.nHeight) must equal 1.

Here's what the script looks like on github:
Note that the h* is just a block hash.

script << OP_RETURN << ToByteVector(h*);

Here's what I'm testing right now as I'm working on BMM:

script << OP_RETURN << CScriptNum::serialize(nSidechain) << CScriptNum(nSidechainHeight) << ToByteVector(sidechain blinded block hash h*)

One other thing I want to make sure is clear enough is that the block number in the critical hash script is
a sidechain block number, not a mainchain block number. That might mess up the new format you have
suggested for bribes. And the reason a sidechain miner would want to refund their bribe is if the h* doesn't
end up in a coinbase after a number of blocks, making their blinded block on the sidechain invalid as tx's
will be spent in other blocks that do get their h* in a coinbase.

We were thinking about making bribe outputs have a maturity period like generated coins. You
think that they should be locked for >100 blocks by having OP_BRIBE also check the lock time?

I like all of your suggestions so far, thank you for taking a look!


On 05/24/2017 03:05 AM, Tier Nolan via bitcoin-dev wrote:
On Wed, May 24, 2017 at 9:50 AM, Tier Nolan <tier.nolan@gmail.com> wrote:
OP_BRIBE_VERIFY could then operate as follows

<block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY

This causes the script to fail if
  <block height> does not match the block height, or
  <critical hash> is not the hash for the sidechain with <sidechain_id>, or
  there is no hash for that sidechain in the block's coinbase


I was thinking more on the process for these transactions.

I assume that the process is

- sidechain miner broadcasts transaction with OP_BRIBE output
- this transaction ends up in the memory pool of miners
- Miners add the transaction to their next block
- Miners add a transaction which spends the output to one of their own addresses

I think you need an additional rule that OP_BRIBE checks fails unless the output is locked 100 or more blocks.

The output script would end up something like

IF
   <block height> <chain_id> <critical hash> OP_BRIBE_VERIFY
ELSE
  <public key> OP_CHECKSIG
ENDIF

This output acts like "anyone can spend" for the one block height.  Otherwise, only the sidechain miner can spend the output.

This allows the sidechain miner to reclaim their coins if the transaction ends up in a different block.

OP_BRIBE_VERIFY would have an additional rule

The script to fails if
  one or more of the transaction outputs start with something other than the template
  <block height> does not match the block height, or
  <critical hash> is not the hash for the sidechain with <sidechain_id>, or
  there is no hash for that sidechain in the block's coinbase

The template is
  <100> OP_CHECKSEQUENCE_VERIFY


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--------------28869D4A0AC941D5998AB3B2--