path: root/50/a5e3ffe280082e54013f47fefac45ba8a333bb

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 37955412
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 18 Jun 2017 14:41:31 +0000 (UTC)
X-Greylist: delayed 00:05:02 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 F08AFFC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 18 Jun 2017 14:41:29 +0000 (UTC)
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=suredbits.com;
	q=dns/txt; 
	s=mailo; t=1497796889; h=Content-Type: Cc: To: Subject: Message-ID:
	Date: From: References: In-Reply-To: MIME-Version: Sender;
	bh=QVpo5y3Rt3bJMsgi4mXrmk/F3zQhuSBeeBuavpQbsoA=;
	b=keqOeY9qlY3PXZ+MezMOw7RyHPvtokAsML1BS/7V3zV4yZLKW5Icq+uP5fYK2vG7uMq87pUC
	xUzlOJWizNZruC6NMONEWZ3WyPl9AKIk9rP7WzUFIAwyp313VtHMTn/zBHdAc7qfPgRiJKQn
	6A+xxtx+wrqSheNxnQAkRT6B4dY=
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=NZpGUxTCoSE8lFNAGvGWNEA9GJN0i87O9DZoEeuaGqAnyZ1NmeVYf7PMs6THdomLCuxAG2
	VU7GoGqt/z2w5XKuPYhKAoHBPL4hf35qc0xW2pN3LP/voT7QYP19PmO0mTmZVPsqU487c0eE
	8UK2/MuS0cwA/L4sFR2a2szJaz43g=
Sender: chris@suredbits.com
X-Mailgun-Sending-Ip: 198.61.254.16
X-Mailgun-Sid: WyI5MGYzNyIsICJiaXRjb2luLWRldkBsaXN0cy5saW51eGZvdW5kYXRpb24ub3JnIiwgIjJjMTQxIl0=
Received: from mail-io0-f178.google.com (mail-io0-f178.google.com
	[209.85.223.178])
	by mxa.mailgun.org with ESMTP id 59468fea.7fa7587ef2f0-smtp-out-n02;
	Sun, 18 Jun 2017 14:36:26 -0000 (UTC)
Received: by mail-io0-f178.google.com with SMTP id y77so51328840ioe.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 18 Jun 2017 07:36:25 -0700 (PDT)
X-Gm-Message-State: AKS2vOx36rIGbNcxW3EX/EP6LE4FlOzf/t4G/BfNwMe/0VufTeJ9Tmfl
	0jVqeMeWgvEQvIo/eMGS1wPWSKpazA==
X-Received: by 10.107.137.26 with SMTP id l26mr17529110iod.13.1497796585408;
	Sun, 18 Jun 2017 07:36:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.185.3 with HTTP; Sun, 18 Jun 2017 07:36:24 -0700 (PDT)
In-Reply-To: <CAE-z3OXY2YiQ5fzxZBw4FooRsUzXricHmpv_+t+HbTf0MxP0kg@mail.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>
From: Chris Stewart <chris@suredbits.com>
Date: Sun, 18 Jun 2017 09:36:24 -0500
X-Gmail-Original-Message-ID: <CAGL6+mFu-W9BXs+ipDQod33XZn85Rj=cDzhanVDY5wLzRbkFTQ@mail.gmail.com>
Message-ID: <CAGL6+mFu-W9BXs+ipDQod33XZn85Rj=cDzhanVDY5wLzRbkFTQ@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary="001a113fc4046b5ec105523cf14a"
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: Sun, 18 Jun 2017 15:24:46 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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: Sun, 18 Jun 2017 14:41:31 -0000

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

>OP_RETURN <sidechain_id> <critical hash>

I think it is redundant here to have the <sidechain id>, we can implicitly
assume what the sidechain_id is since we have a fixed set of drivechains.
I.e. mining reward is index 0, mimblewimble sidechain is index 1, etc.
CryptAxe has specific indexes defined already in his implementation:
https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/sidechain.h#L26-L30
.

I think it would be wise to include a version byte to allow us to upgrade
this commitment structure in the future. Similar to how witness program's
are now versioned.

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

If <block height> is an argument that OP_BRIBE_VERIFY takes, doesn't that
mean the mainchain miner has to validate this *is* the actual block height
on the sidechain? Does that take the 'blindness' away from BMM?

Overall, I think we need to work on the commitment structure to the
coinbase tx. If I understand the current implementation correctly we can
have up to 256 OP_RETURNs embedded in the coinbase tx signifying new blocks
mined on drivechains.. this seems less than ideal. It might be prudent to
make these outputs ANYONECANSPEND, and then have miners spending these
outputs to themselves for every block mined.. maybe this doesn't have a
benefit over using OP_RETURNs though?

The structure could be something like:
<version> <critical hash>

and then in a subsequent block the miner spends that output to themselves.
I will admit I'm not super familiar with how OP_RETURNs work with the UTXO
set -- maybe this scheme doesn't have any benefit.

-Chris

On Wed, May 24, 2017 at 3:50 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, May 23, 2017 at 3:22 PM, Paul Sztorc <truthcoin@gmail.com> wrote:
>
>>
>> If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is
>> probably the most human-readable description.
>>
>
> I guess I was looking for the detail you get in the code, but without
> having to read the code.
>
> My quick reading gives that the sidechain codes (critical hashes) are
> added when a coinbase is processed.
>
> Any coinbase output that has the form "OP_RETURN <32 byte push>" counts as
> a potential critical hash.
>
> When the block is processed, the key value pair (hash, block_height) is
> added to a hash map.
>
> The OP_BRIBE opcode checks that the given hash is in the hash map and
> replaces the top element on the stack with the pass/fail result.
>
> It doesn't even check that the height matches the current block, though
> there is a comment that that is a TODO.
>
> I agree with ZmnSCPxj, when updating a nop, you can't change the stack.
> It has to fail the script or do nothing.
>
> OP_BRIBE_VERIFY would cause the script to fail if the hash wasn't in the
> coinbase, or cause a script failure otherwise.
>
> Another concern is that you could have multiple bribes for the same chain
> in a single coinbase.  That isn't fair and arguably what the sidechain
> miner is paying for is to get his hash exclusively into the block.
>
> I would suggest that the output is
>
> OP_RETURN <sidechain_id> <critical hash>
>
> Then add the rule that only the first hash with a particular sidechain id
> actually counts.
>
> This forces the miner to only accept the bribe from 1 miner for each
> sidechain for each block.  If he tries to accept 2, then only the first one
> counts.
>
> 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
>
> If you want reduce the number of drops, you could serialize the info into
> a single push.
>
> This has the advantage that a sidechain miner only has to pay if his block
> is accepted in the next bitcoin block.  Since he is the only miner for that
> sidechain that gets into the main bitcoin block, he is pretty much
> guaranteed to form the longest chain.
>
> Without that rule, sidechain miners could end up having to pay even though
> it doesn't make their chain the longest.
>
> How are these transactions propagated over the network?  For relaying, you
> could have the rule that the opcode passes as long as <block height> is
> near the current block height.  Maybe require that they are in the future.
> They should be removed from the memory pool once the block height has
> arrived, so losing miners can re-spend those outputs.
>
> This opcode can be validated without needing to look at other blocks,
> which is good for validating historical blocks.
>
> I am still looking at the deposit/withdrawal code.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><div>&gt;OP_RETURN &lt;sidechain_id&gt; &lt;critical hash&=
gt;<br><br></div><div>I think it is redundant here to have the &lt;sidechai=
n id&gt;, we can implicitly assume what the sidechain_id is since we have a=
 fixed set of drivechains. I.e. mining reward is index 0, mimblewimble side=
chain is index 1, etc. CryptAxe has specific indexes defined already in his=
 implementation:=C2=A0 <a href=3D"https://github.com/drivechain-project/bit=
coin/blob/mainchainBMM/src/sidechain.h#L26-L30">https://github.com/drivecha=
in-project/bitcoin/blob/mainchainBMM/src/sidechain.h#L26-L30</a>.<br><br></=
div><div>I think it would be wise to include a version byte to allow us to =
upgrade this commitment structure in the future. Similar to how witness pro=
gram&#39;s are now versioned. <br></div><div><br>&gt;&lt;block height&gt; &=
lt;sidechain_id&gt; &lt;critical hash&gt; OP_BRIBE_VERIFY<br><br></div><div=
>If &lt;block height&gt; is an argument that OP_BRIBE_VERIFY takes, doesn&#=
39;t that mean the mainchain miner has to validate this *is* the actual blo=
ck height on the sidechain? Does that take the &#39;blindness&#39; away fro=
m BMM?<br><br></div><div>Overall, I think we need to work on the commitment=
 structure to the coinbase tx. If I understand the current implementation c=
orrectly we can have up to 256 OP_RETURNs embedded in the coinbase tx signi=
fying new blocks mined on drivechains.. this seems less than ideal. It migh=
t be prudent to make these outputs ANYONECANSPEND, and then have miners spe=
nding these outputs to themselves for every block mined.. maybe this doesn&=
#39;t have a benefit over using OP_RETURNs though? <br><br></div><div>The s=
tructure could be something like: <br>&lt;version&gt; &lt;critical hash&gt;=
 <br><br>and then in a subsequent block the miner spends that output to the=
mselves. I will admit I&#39;m not super familiar with how OP_RETURNs work w=
ith the UTXO set -- maybe this scheme doesn&#39;t have any benefit.<br><br>=
</div><div>-Chris<br></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Wed, May 24, 2017 at 3:50 AM, Tier Nolan via bitcoin-de=
v <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:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><span class=3D"">On Tue, May 23, 201=
7 at 3:22 PM, Paul Sztorc <span dir=3D"ltr">&lt;<a href=3D"mailto:truthcoin=
@gmail.com" target=3D"_blank">truthcoin@gmail.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"m_-3891736=
0626246564gmail-m_-1252449154618151496gmail-"></span><span class=3D"m_-3891=
7360626246564gmail-m_-1252449154618151496gmail-"><br>
</span>If you haven&#39;t seen <a href=3D"http://www.truthcoin.info/blog/dr=
ivechain/" rel=3D"noreferrer" target=3D"_blank">http://www.truthcoin.info/b=
log<wbr>/drivechain/</a> , that is<br>
probably the most human-readable description.<br></blockquote><div><br></di=
v></span><div>I guess I was looking for the detail you get in the code, but=
 without having to read the code.<br><br></div>My quick reading gives that =
the sidechain codes (critical hashes) are added when a coinbase is processe=
d.<br><br></div><div class=3D"gmail_quote">Any coinbase output that has the=
 form &quot;OP_RETURN &lt;32 byte push&gt;&quot; counts as a potential crit=
ical hash.<br><br></div><div class=3D"gmail_quote">When the block is proces=
sed, the key value pair (hash, block_height) is added to a hash map.<br><br=
></div><div class=3D"gmail_quote">The OP_BRIBE opcode checks that the given=
 hash is in the hash map and replaces the top element on the stack with the=
 pass/fail result.<br><br></div><div class=3D"gmail_quote">It doesn&#39;t e=
ven check that the height matches the current block, though there is a comm=
ent that that is a TODO.<br></div><div class=3D"gmail_quote"><br></div><div=
 class=3D"gmail_quote">I agree with ZmnSCPxj, when updating a nop, you can&=
#39;t change the stack.=C2=A0 It has to fail the script or do nothing.<br><=
br></div><div class=3D"gmail_quote">OP_BRIBE_VERIFY would cause the script =
to fail if the hash wasn&#39;t in the coinbase, or cause a script failure o=
therwise.<br><br></div><div class=3D"gmail_quote">Another concern is that y=
ou could have multiple bribes for the same chain in a single coinbase.=C2=
=A0 That isn&#39;t fair and arguably what the sidechain miner is paying for=
 is to get his hash exclusively into the block.<br><br></div><div class=3D"=
gmail_quote">I would suggest that the output is<br><br></div><div class=3D"=
gmail_quote">OP_RETURN &lt;sidechain_id&gt; &lt;critical hash&gt;<br><br></=
div><div class=3D"gmail_quote">Then add the rule that only the first hash w=
ith a particular sidechain id actually counts.<br><br></div><div class=3D"g=
mail_quote">This forces the miner to only accept the bribe from 1 miner for=
 each sidechain for each block.=C2=A0 If he tries to accept 2, then only th=
e first one counts.<br><br></div><div class=3D"gmail_quote">OP_BRIBE_VERIFY=
 could then operate as follows<br><br></div><div class=3D"gmail_quote">&lt;=
block height&gt; &lt;sidechain_id&gt; &lt;critical hash&gt; OP_BRIBE_VERIFY=
<br><br></div><div class=3D"gmail_quote">This causes the script to fail if<=
br></div><div class=3D"gmail_quote">=C2=A0 &lt;block height&gt; does not ma=
tch the block height, or<br></div><div class=3D"gmail_quote">=C2=A0 &lt;cri=
tical hash&gt; is not the hash for the sidechain with &lt;sidechain_id&gt;,=
 or<br></div><div class=3D"gmail_quote">=C2=A0 there is no hash for that si=
dechain in the block&#39;s coinbase<br><br></div><div class=3D"gmail_quote"=
>If you want reduce the number of drops, you could serialize the info into =
a single push.=C2=A0 <br><br></div><div class=3D"gmail_quote">This has the =
advantage that a sidechain miner only has to pay if his block is accepted i=
n the next bitcoin block.=C2=A0 Since he is the only miner for that sidecha=
in that gets into the main bitcoin block, he is pretty much guaranteed to f=
orm the longest chain.<br><br></div><div class=3D"gmail_quote">Without that=
 rule, sidechain miners could end up having to pay even though it doesn&#39=
;t make their chain the longest.<br></div><div class=3D"gmail_quote"><br></=
div><div class=3D"gmail_quote">How are these transactions propagated over t=
he network?=C2=A0 For relaying, you could have the rule that the opcode pas=
ses as long as &lt;block height&gt; is near the current block height.=C2=A0=
 Maybe require that they are in the future.=C2=A0 They should be removed fr=
om the memory pool once the block height has arrived, so losing miners can =
re-spend those outputs.<br><br><div class=3D"gmail_quote">This opcode can b=
e validated without needing to look at other blocks, which is good for vali=
dating historical blocks.<br></div><div class=3D"gmail_quote"><br></div><di=
v class=3D"gmail_quote">I am still looking at the deposit/withdrawal code.<=
br></div></div></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.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-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a113fc4046b5ec105523cf14a--