path: root/dd/a64e73ef3836ddea303e55f8bd7ccd6fdf74d5

Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CC376C51
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 25 May 2017 22:08:41 +0000 (UTC)
Received: by mail-oi0-f45.google.com with SMTP id l18so297173902oig.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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>
	<dhstGQudLBiwjDlaRrmMfy-ixwvXcwMr1CzCkPKh285RLICGZixkbdwpTDc2Sgz8eYIqSem8lwxW6QeJCD7aFfwQjLDnZ2NmOw0Zzd-KgSs=@protonmail.com>
	<CA+XQW1jZpJ9wnEg47fouyywL09=_vU8dMP3owkkuNqRvzTZUDg@mail.gmail.com>
	<CAE-z3OUYuAXE2+h60A=r4UyGU4CSQuF98oFgHnD7iaj-=Z=yOw@mail.gmail.com>
	<CA+XQW1hRhcxJBoOJ57YG0t5y5j1Qm3RO4wr2eXV5V-UzDaiPPw@mail.gmail.com>
	<CAE-z3OVWXN58X-+nAFTm61G1=v_1xrniyrBy8x=VRG4N149aXQ@mail.gmail.com>
	<141a0cd1-9d4f-c137-a349-17248f9cafd4@gmail.com>
	<CAE-z3OXY2YiQ5fzxZBw4FooRsUzXricHmpv_+t+HbTf0MxP0kg@mail.gmail.com>
	<CAE-z3OXLb0QOjACfvToxf9TfLJhBHiboAaieLA4V9gx6V4CjoQ@mail.gmail.com>
	<2b5567e1-2b6d-db4a-0f44-c66a24fe28ea@gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Thu, 25 May 2017 23:08:00 +0100
Message-ID: <CAE-z3OWF8PabC3314Aj_9cyu+sjZnSe2N-Rfoh8T6vhPgrkn8Q@mail.gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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
   <block height> <chain_id> <critical hash> OP_BRIBE_VERIFY
ELSE
  <public key> OP_CHECKSIG
ENDIF


If the output is spent by the miner for block <block height>, 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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, May 24, 2017 at 6:32 PM, CryptAxe 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><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF">
    <p>Also the block number can only change
      by +1 or -1, so when a new h* is added to the <br>
      queue it must be compared to the most recent h* in the queue.
      std::abs(queue.back().nHeight - ToAdd.nHeight) must equal 1.<br></p><=
/div></blockquote><div><br></div><div>I think it is better to have it locke=
d to a particular bitcoin height and if it doesn&#39;t get included in that=
 block, the sidechain miner can re-claim it.<br><br></div><div>This could b=
e taken to the extreme where the sidechain miner specifies a particular par=
ent of the claiming block.<br></div><div><br></div><div>The output should h=
ave a standard template, so miners can easily find bids.<br><br></div><div>=
The template on my previous post was:<br><br><div class=3D"gmail_extra">IF<=
br></div><div class=3D"gmail_extra">=C2=A0=C2=A0 &lt;block height&gt; &lt;c=
hain_id&gt; &lt;critical hash&gt; OP_BRIBE_VERIFY<br></div><div class=3D"gm=
ail_extra">ELSE<br></div><div class=3D"gmail_extra">=C2=A0 &lt;public key&g=
t; OP_CHECKSIG<br></div>ENDIF</div><div>=C2=A0<br><br></div><div>If the out=
put is spent by the miner for block &lt;block height&gt;, then the sidechai=
n miner has spent the funds.<br><br></div><div>Otherwise, the sidechain min=
er can use the else branch to reclaim his money.<br><br></div><div>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 &quot;early&quot;.<br><br></div><div>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.<br><br></div><div>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.<br></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div bgcolor=3D"#FFFFFF"><p>
     =20
      Here&#39;s what I&#39;m testing right now as I&#39;m working on BMM:<=
br>
      <br>
      script &lt;&lt; OP_RETURN &lt;&lt;
      CScriptNum::serialize(<wbr>nSidechain) &lt;&lt;
      CScriptNum(nSidechainHeight) &lt;&lt; ToByteVector(sidechain
      blinded block hash h*)<br></p></div></blockquote><div><br></div><div>=
I don&#39;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.<br><br></=
div><div>You could just define the critical hash as <br><br></div><div>Hash=
( SideChainHeight | blinded h* )<br><br></div><div>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).<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div bgcolor=3D"#FFFFFF"><p>
      One other thing I want to make sure is clear enough is that the
      block number in the critical hash script is <br>
      a sidechain block number, not a mainchain block number.</p></div></bl=
ockquote><div>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.<br><br></div><div>They are paying for their =
block to be placed ahead of all competing blocks for their chain.<br><br></=
div><div>It does mean that the side-chain can have at most the same number =
of blocks as bitcoin.<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div bgcolor=3D"#FFFFFF"><p>
      <br>
      We were thinking about making bribe outputs have a maturity period
      like generated coins. You<br>
      think that they should be locked for &gt;100 blocks by having
      OP_BRIBE also check the lock time?</p></div></blockquote><div><br></d=
iv><div>Well, it depends on the exact rules for OP_BRIBE.<br><br></div><div=
></div><div>The process I see is:<br><br></div><div>- sidechain miner submi=
ts a bribe transaction which pays to op bribe<br></div><div>- bitcoin miner=
 includes that transaction in his block (or it could be included in a previ=
ous block)<br></div><div>- bitcoin miner includes a claim transaction in hi=
s block<br><br></div><div>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.<br><br>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).<br><br></div><div>The only (unavoidable) excepti=
ons were double spends and coinbases outputs.<br><br></div><div>This means =
that the same protection should be added to your claim transaction.<br><br>=
</div><div>You could do it by requiring all outputs of the claim transactio=
n to start with<br><br></div><div>&lt;100&gt; CHECK_SEQUENCE_VERIFY DROP ..=
.<br><br></div><div>This is only a few bytes extra at the start of the outp=
ut script.<br></div><div><br></div><div>This means you can&#39;t use witnes=
s or P2SH output types for any of the outputs, but that isn&#39;t that impo=
rtant.=C2=A0 The point of the transaction is to make a payment.<br></div><d=
iv><br></div><div>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.<br></div></div></div></div>

--001a113d51f2a2e5ca0550607622--