From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CC376C51 for ; Thu, 25 May 2017 22:08:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 11DA414B for ; Thu, 25 May 2017 22:08:41 +0000 (UTC) Received: by mail-oi0-f45.google.com with SMTP id l18so297173902oig.2 for ; Thu, 25 May 2017 15:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=zOaOyE7a34kBDlx3NFg1Y+NzotBgoqnBY+2eb/Go/+g=; b=NGxscUyzD4DERPb7JfMyJAemqPGNT3ul3wOSfvFgpEqkSRaHIuas98SjQQ9SKvKfXo Mgm/8T4Y0b1SXPrWcvOvZdW3V05c5vjJITOmaQ4DR7TknGupBwEFItzHv3oo9X31jHhB 7I/ouoaYdrwsehc2npQJasqbRX5f29q77qJff/kc5qHnRtX6brJ9FHXkLLeIPB0WqBM+ CT2gRS2cIZZz4zDY4zQOddyleMAMkaGxxv8TdgijOhA3kmWxN0Elv4Xo+VRFJWQ/YRAQ vU+aThcQUNRR3ipCAo68rFSadaAFVJXG5PyRTz8HnPPgBeyUma4wOnCanl9mJeT907sr JiTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=zOaOyE7a34kBDlx3NFg1Y+NzotBgoqnBY+2eb/Go/+g=; b=X9kua7f9mpvsfNJB82ZJnocrnsVThxAKNt/ZGVK8A6B+8xGr87vuZ3H6hZFwzwTUgo E+LVFqBgGjzMqhPa57d4l0Gst3YmGntklVsTdxLSbdUWpNY323qTL2Im+8Vr9uiUh3OM YQmiYLVaNFV5jH1ysewedBJfn5zZ+q4n0O4VaiAXoGEbLAFbNgNzggGRNSogCRsCOlGx atbsj6vmzN00ty4czZj/ZVQ/ALoU0K0+EdZrEvhEr3rLtdSY1bIihSUXCo1XCOCBbjIB L4UJhJa+2z0UPZq5/L6/x4z8PUG9Utp9O5NYIR/uAOaai1D4LXhNX477dTDkFodUMyrW 4uWQ== X-Gm-Message-State: AODbwcBbha532BuifGmL9C9PDFzNC/0Uqhc8v2MhYMzQLDiSSxtP3vbC JHOoXxOVPpT2RuW33dbhy8vXvde6A5GZ X-Received: by 10.202.234.70 with SMTP id i67mr18461992oih.142.1495750121021; Thu, 25 May 2017 15:08:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.100.89 with HTTP; Thu, 25 May 2017 15:08:00 -0700 (PDT) In-Reply-To: <2b5567e1-2b6d-db4a-0f44-c66a24fe28ea@gmail.com> References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> <141a0cd1-9d4f-c137-a349-17248f9cafd4@gmail.com> <2b5567e1-2b6d-db4a-0f44-c66a24fe28ea@gmail.com> From: Tier Nolan Date: Thu, 25 May 2017 23:08:00 +0100 Message-ID: Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary="001a113d51f2a2e5ca0550607622" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, 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 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: Thu, 25 May 2017 22:08:42 -0000 --001a113d51f2a2e5ca0550607622 Content-Type: text/plain; charset="UTF-8" On Wed, May 24, 2017 at 6:32 PM, CryptAxe via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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. > I think it is better to have it locked to a particular bitcoin height and if it doesn't get included in that block, the sidechain miner can re-claim it. This could be taken to the extreme where the sidechain miner specifies a particular parent of the claiming block. The output should have a standard template, so miners can easily find bids. The template on my previous post was: IF OP_BRIBE_VERIFY ELSE OP_CHECKSIG ENDIF If the output is spent by the miner for block , then the sidechain miner has spent the funds. Otherwise, the sidechain miner can use the else branch to reclaim his money. The sidechain miner could also reclaim his money if the transaction was included in an earlier block. That would defeat the purpose of the bribe. Bitcoin miners would have a (justified) incentive to not allow Bribe outputs to be spent "early". The bribe transactions could be created with no fees. This would mean that it is pointless for bitcoin miners to include them in blocks unless they are claiming the outputs. The relay rules would need to be modified to handle that. Pools could allow bids to be made directly, but that is less decentralized. 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*) > I don't think OP_BRIBE should care about info for the side chain. The only thing that is necessary is to indicate which sidechain. You could just define the critical hash as Hash( SideChainHeight | blinded h* ) For bribe payout release, it needs to give that particular miner an advantage over all competitors, so their block forms the longest chain on the sidechain (assuming their block is actually valid). > 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. > The sidechain miner is saying that they will pay the bribe but only if their block is included in the main chain. The means that main chain height is important. They are paying for their block to be placed ahead of all competing blocks for their chain. It does mean that the side-chain can have at most the same number of blocks as bitcoin. > > 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? > Well, it depends on the exact rules for OP_BRIBE. The process I see is: - sidechain miner submits a bribe transaction which pays to op bribe - bitcoin miner includes that transaction in his block (or it could be included in a previous block) - bitcoin miner includes a claim transaction in his block The claim transaction spends the outputs from the bribe transaction. If the claim transaction is block height locked, then it violates the rules that previous soft-forks have followed. For previous opcode changes there was a requirement that if a transaction was accepted into block N, then it must also be acceptable in block (N+1). The only (unavoidable) exceptions were double spends and coinbases outputs. This means that the same protection should be added to your claim transaction. You could do it by requiring all outputs of the claim transaction to start with <100> CHECK_SEQUENCE_VERIFY DROP ... This is only a few bytes extra at the start of the output script. This means you can't use witness or P2SH output types for any of the outputs, but that isn't that important. The point of the transaction is to make a payment. An alternative would be to just add the rule as part of soft-fork definition. You could define a claim transaction as one that spends at least one OP_BRIBE output and therefore, all its outputs have a 100 block delay. --001a113d51f2a2e5ca0550607622 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, May 24, 2017 at 6:32 PM, CryptAxe via bitcoin-dev <= ;bitcoin-dev@lists.linuxfoundation.org> wrote:
=20 =20 =20

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.

<= /div>

I think it is better to have it locke= d to a particular bitcoin height and if it doesn't get included in that= block, the sidechain miner can re-claim it.

This could b= e taken to the extreme where the sidechain miner specifies a particular par= ent of the claiming block.

The output should h= ave a standard template, so miners can easily find bids.

= The template on my previous post was:

IF<= br>
=C2=A0=C2=A0 <block height> <c= hain_id> <critical hash> OP_BRIBE_VERIFY
ELSE
=C2=A0 <public key&g= t; OP_CHECKSIG
ENDIF
=C2=A0

If the out= put is spent by the miner for block <block height>, then the sidechai= n miner has spent the funds.

Otherwise, the sidechain min= er can use the else branch to reclaim his money.

The side= chain miner could also reclaim his money if the transaction was included in= an earlier block.=C2=A0 That would defeat the purpose of the bribe.=C2=A0 = Bitcoin miners would have a (justified) incentive to not allow Bribe output= s to be spent "early".

The bribe transactions c= ould be created with no fees.=C2=A0 This would mean that it is pointless fo= r bitcoin miners to include them in blocks unless they are claiming the out= puts.

The relay rules would need to be modified to handle= that.=C2=A0 Pools could allow bids to be made directly, but that is less d= ecentralized.

=20 Here's what I'm testing right now as I'm working on BMM:<= br>
script << OP_RETURN << CScriptNum::serialize(nSidechain) << CScriptNum(nSidechainHeight) << ToByteVector(sidechain blinded block hash h*)


= I don't think OP_BRIBE should care about info for the side chain.=C2=A0= The only thing that is necessary is to indicate which sidechain.

You could just define the critical hash as

Hash= ( SideChainHeight | blinded h* )

For bribe payout release= , it needs to give that particular miner an advantage over all competitors,= so their block forms the longest chain on the sidechain (assuming their bl= ock is actually valid).

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.

The sidechain miner is saying that they will pay the bribe bu= t only if their block is included in the main chain.=C2=A0 The means that m= ain chain height is important.

They are paying for their = block to be placed ahead of all competing blocks for their chain.

It does mean that the side-chain can have at most the same number = of blocks as bitcoin.


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?


Well, it depends on the exact rules for OP_BRIBE.

The process I see is:

- sidechain miner submi= ts a bribe transaction which pays to op bribe
- bitcoin miner= includes that transaction in his block (or it could be included in a previ= ous block)
- bitcoin miner includes a claim transaction in hi= s block

The claim transaction spends the outputs from the= bribe transaction.=C2=A0 If the claim transaction is block height locked, = then it violates the rules that previous soft-forks have followed.

F= or previous opcode changes there was a requirement that if a=20 transaction was accepted into block N, then it must also be=20 acceptable in block (N+1).

The only (unavoidable) excepti= ons were double spends and coinbases outputs.

This means = that the same protection should be added to your claim transaction.

=
You could do it by requiring all outputs of the claim transactio= n to start with

<100> CHECK_SEQUENCE_VERIFY DROP ..= .

This is only a few bytes extra at the start of the outp= ut script.

This means you can't use witnes= s or P2SH output types for any of the outputs, but that isn't that impo= rtant.=C2=A0 The point of the transaction is to make a payment.

An alternative would be to just add the rule as part of s= oft-fork definition.=C2=A0 You could define a claim transaction as one that= spends at least one OP_BRIBE output and therefore, all its outputs have a = 100 block delay.
--001a113d51f2a2e5ca0550607622--