path: root/ad/9ba31b8b9747972dbeca79af86727ab0aabb02

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 4DEE4C16
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  4 Dec 2017 20:11:18 +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 5AE70271
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  4 Dec 2017 20:11:16 +0000 (UTC)
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=suredbits.com;
	q=dns/txt; 
	s=mailo; t=1512418275; h=Content-Type: Cc: To: Subject: Message-ID:
	Date: From: References: In-Reply-To: MIME-Version: Sender;
	bh=u3rsThJD0lSyjQG/mbm+H9zjrIXBLLDEh7eU1P2ZC8k=;
	b=uBVXQ1r3TeELQ3BU+ruf69iu07Z6XbPYVS8xAqYjKxt4yBXl3NgGfU1k3RNjRL2rfN12V09K
	c/ofpoMHnLMymFgQ+p4GTKoVE1e6rMjri/rJ3ycFbGEUnqyRsMx1DdMwrjZyC2MfFUwsL6uf
	34Te2ciPZmHQqaVx23qhipgGyoE=
Sender: chris@suredbits.com
X-Mailgun-Sending-Ip: 198.61.254.16
X-Mailgun-Sid: WyI5MGYzNyIsICJiaXRjb2luLWRldkBsaXN0cy5saW51eGZvdW5kYXRpb24ub3JnIiwgIjJjMTQxIl0=
Received: from mail-it0-f43.google.com (mail-it0-f43.google.com
	[209.85.214.43])
	by mxa.mailgun.org with ESMTP id 5a25abe3.7f2964b476b0-smtp-out-n02;
	Mon, 04 Dec 2017 20:11:15 -0000 (UTC)
Received: by mail-it0-f43.google.com with SMTP id x28so15862603ita.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 04 Dec 2017 12:11:15 -0800 (PST)
X-Gm-Message-State: AKGB3mLHkPt32DgG1ysmENzbVNqe9Nqxh8tXpspDRw2nuZLj+gDFOJp7
	+bJr8AA1y7KLYakUCq+iJUqqH15MUfVRxLrTs/4=
X-Google-Smtp-Source: AGs4zMaBTQqnEs5Hi9CSXV+3FoT4TuCUjI/URsOxF8zs5pSicMqUM2NMeGZ33PeVk+FGF3HnQsQ9RTcO/8K9FHvF1sM=
X-Received: by 10.36.62.3 with SMTP id s3mr14761052its.113.1512418274456; Mon,
	04 Dec 2017 12:11:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.128.94 with HTTP; Mon, 4 Dec 2017 12:11:13 -0800 (PST)
In-Reply-To: <CAB+qUq4wNv=-ZSibUvVCwYSE7Qw8xe8EH91KG6znUp1d7X=mdA@mail.gmail.com>
References: <d3497397-33c3-90c1-1be8-a733736eac0b@gmail.com>
	<1bb6cccd-3f6d-d62a-2825-4e6f46a4b525@mattcorallo.com>
	<dd2781a6-3e10-9f0c-6ee0-a2c070b7cf67@gmail.com>
	<CAB+qUq4wNv=-ZSibUvVCwYSE7Qw8xe8EH91KG6znUp1d7X=mdA@mail.gmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Mon, 4 Dec 2017 14:11:13 -0600
X-Gmail-Original-Message-ID: <CAGL6+mF1YbjZ28MtvPxTye-HndEqmd6LkaFVr9BWvPiK-kfVTA@mail.gmail.com>
Message-ID: <CAGL6+mF1YbjZ28MtvPxTye-HndEqmd6LkaFVr9BWvPiK-kfVTA@mail.gmail.com>
To: Chris Pacia <ctpacia@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1140ac7c00528c055f8952c3"
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: Tue, 05 Dec 2017 19:34:21 +0000
Subject: Re: [bitcoin-dev] Two Drivechain BIPs
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: Mon, 04 Dec 2017 20:11:18 -0000

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

>As far as I can tell there is no opportunity cost to casting a malicious
vote, no repercussions, and no collective action barrier that needs to be
overcome.

There is another interesting analysis on BMM and drivechains from /u/almkglor
on reddit
<https://www.reddit.com/r/Bitcoin/comments/6ztp3b/lets_discuss_something_techrelated_for_a_change/dn0rsdo/>.
I'm going to share here for visibility.

The problem with drivechains and blind merged mining is the disconnect
> between voting and "blind" merge mining. With BMM, a miner can do:
>
>    1. Not accept BMM, not vote.
>    2. Not accept BMM, operate their own sidechain node, mine sidecoin,
>    and vote correctly.
>    3. Not accept BMM, always upvote (i.e. allow theft).
>    4. Not accept BMM, always downvote (i.e. strangle).
>    5. Accept BMM, not vote.
>    6. Accept BMM, operate their own sidechain node, and vote correctly.
>    (not mine sidecoin directly: they get paid in maincoin by sidecoin-only
>    miners).
>    7. Accept BMM, always upvote (i.e. allow theft).
>    8. Accept BMM, always downvote (i.e. strangle).
>
> 3 and 7 will mean that non-verifying miners will be (inadvertently)
> complicit in theft. Drivechains have 1008-block cycles ostensibly to
> protect against theft, so that someone can "raise the alarm" and tell
> miners to downvote a particular theft withdrawal, but that sounds too much
> like centralized collusion to me.
>
> Strategy 8 will dominate over strategy 6, since the miner does not have to
> run a sidechain node (reduced cost) while still earning the same as
> strategy 6.
>
> Strategies 5->8 are all strictly superior to 1->4, so BMM does not really
> change anything: strategy 8 (equivalent to strategy 4 if BMM is not
> implemented) will still choke strategy 6 (equivalent to strategy 2 if BMM
> is not implemented)
>
> It seems Drivechain's security model is: miners always upvote by default.
> If a theft withdrawal is done on the mainchain, some sidechain nodes call
> up their miner friends (which makes me worry about miner centralization) to
> downvote it instead.
>
> The problem is: what if after a theft withdrawal is defeated, another
> theft withdrawal is done? And another, and another? This weakens the peg:
> while a theft withdrawal is on-going, a genuine withdrawal can't be posted
> (at least as I understand Sztorc's explanation). This chokes the sidechain
> withdrawal.
>
> The difference from maincoin is that attempts to choke the block are
> somewhat costly and a maincoin user can offer a higher transaction fee to
> beat the spam. If side->main is choked, no amount of sidecoin can be
> offered to beat the spammed theft transactions.
>
> I don't know, it seems like very weak security to me.
>
TLDR: a miner is most profitable if he always accepts BMM bribes, but
downvotes withdrawal transactions (WT). This obviously isn't ideal because
a withdrawal will never occur from the drivechain if enough miners employ
this strategy -- which seems to be the most profitable strategy.

-Chris


On Mon, Dec 4, 2017 at 1:36 PM, Chris Pacia via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> I think you are missing a few things.
>
> First of all, I think the security model for sidechains is the same as
> that of every blockchain
>
> People will say things, like "but with sidechains 51% hashrate can steal
> your coins!", but as I have repeated many times, this is also true of
> mainchain btc-tx.  is something else?
>
>
> There are substantial opportunity costs as well as a collective action
> problem when it comes to re-writing the mainchain.
>
> Is there anything similar for drivechains? As far as I can tell there is
> no opportunity cost to casting a malicious vote, no repercussions, and no
> collective action barrier that needs to be overcome.
>
> Unless I'm missing something I wouldn't liken the security of a drivechain
> to that of the mainchain.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><div><div>&gt;As far as I can tell there is no opportunity=
 cost to casting a malicious
 vote, no repercussions, and no collective action barrier that needs to=20
be overcome.<br><br></div>There is another interesting analysis on BMM and =
drivechains from <a href=3D"https://www.reddit.com/r/Bitcoin/comments/6ztp3=
b/lets_discuss_something_techrelated_for_a_change/dn0rsdo/">/u/almkglor on =
reddit</a>. I&#39;m going to share here for visibility.=C2=A0 <br></div><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"><p>The problem with driv=
echains and blind merged mining is the=20
disconnect between voting and &quot;blind&quot; merge mining.  With BMM, a =
miner=20
can do:</p><ol><li> Not accept BMM, not vote.</li><li> Not accept BMM, oper=
ate their own sidechain node, mine sidecoin, and vote correctly.</li><li> N=
ot accept BMM, always upvote (i.e. allow theft).</li><li> Not accept BMM, a=
lways downvote (i.e. strangle).</li><li> Accept BMM, not vote.</li><li> Acc=
ept BMM, operate their own sidechain node, and vote correctly.=20
(not mine sidecoin directly: they get paid in maincoin by sidecoin-only=20
miners).</li><li> Accept BMM, always upvote (i.e. allow theft).</li><li> Ac=
cept BMM, always downvote (i.e. strangle).</li></ol><p>3 and 7 will mean th=
at non-verifying miners will be (inadvertently)=20
complicit in theft.  Drivechains have 1008-block cycles ostensibly to=20
protect against theft, so that someone can &quot;raise the alarm&quot; and =
tell=20
miners to downvote a particular theft withdrawal, but that sounds too=20
much like centralized collusion to me.</p><p>Strategy 8 will dominate over =
strategy 6, since the miner does not=20
have to run a sidechain node (reduced cost) while still earning the same
 as strategy 6.</p><p>Strategies 5-&gt;8 are all strictly superior to 1-&gt=
;4, so BMM does=20
not really change anything: strategy 8 (equivalent to strategy 4 if BMM=20
is not implemented) will still choke strategy 6 (equivalent to strategy 2
 if BMM is not implemented)</p><p>It seems Drivechain&#39;s security model =
is: miners always upvote by=20
default.  If a theft withdrawal is done on the mainchain, some sidechain
 nodes call up their miner friends (which makes me worry about miner=20
centralization) to downvote it instead.</p><p>The problem is: what if after=
 a theft withdrawal is defeated, another
 theft withdrawal is done?  And another, and another?  This weakens the=20
peg: while a theft withdrawal is on-going, a genuine withdrawal can&#39;t b=
e
 posted (at least as I understand Sztorc&#39;s explanation).  This chokes=
=20
the sidechain withdrawal.</p><p>The difference from maincoin is that attemp=
ts to choke the block are=20
somewhat costly and a maincoin user can offer a higher transaction fee=20
to beat the spam.  If side-&gt;main is choked, no amount of sidecoin can
 be offered to beat the spammed theft transactions.</p><p>I don&#39;t know,=
 it seems like very weak security to me.</p></blockquote><div>TLDR: a miner=
 is most profitable if he always accepts BMM bribes, but downvotes withdraw=
al transactions (WT). This obviously isn&#39;t ideal because a withdrawal w=
ill never occur from the drivechain if enough miners employ this strategy -=
- which seems to be the most profitable strategy. <br></div><div><br></div>=
<div>-Chris<br></div><div>=C2=A0</div>















</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Dec=
 4, 2017 at 1:36 PM, Chris Pacia via bitcoin-dev <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"auto"><div><br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"m_4849272993808656596quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D""><div class=3D"m_4849272993808656596quoted-text">I think you are mi=
ssing a few things.<br></div>
<br>
First of all, I think the security model for sidechains is the same as<br>
that of every blockchain<br>
<br>
People will say things, like &quot;but with sidechains 51% hashrate can ste=
al<br>
your coins!&quot;, but as I have repeated many times, this is also true of<=
br></span>
mainchain btc-tx. =C2=A0is something else?<br></blockquote></div></div></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">There are substantial oppor=
tunity costs as well as a collective action problem when it comes to re-wri=
ting the mainchain.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">Is there anything similar for drivechains? As far as I can tell there is =
no opportunity cost to casting a malicious vote, no repercussions, and no c=
ollective action barrier that needs to be overcome.=C2=A0</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">Unless I&#39;m missing something I wouldn=
&#39;t liken the security of a drivechain to that of the mainchain.</div><d=
iv dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bloc=
kquote class=3D"m_4849272993808656596quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div></d=
iv>
<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>

--001a1140ac7c00528c055f8952c3--