Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4DEE4C16 for ; 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 ; 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 ; 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: References: <1bb6cccd-3f6d-d62a-2825-4e6f46a4b525@mattcorallo.com> From: Chris Stewart Date: Mon, 4 Dec 2017 14:11:13 -0600 X-Gmail-Original-Message-ID: Message-ID: To: Chris Pacia , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 . 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
>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.

There is another interesting analysis on BMM and = drivechains from /u/almkglor on = reddit. I'm going to share here for visibility.=C2=A0

The problem with driv= echains and blind merged mining is the=20 disconnect between voting and "blind" merge mining. With BMM, a = miner=20 can do:

  1. Not accept BMM, not vote.
  2. Not accept BMM, oper= ate their own sidechain node, mine sidecoin, and vote correctly.
  3. N= ot accept BMM, always upvote (i.e. allow theft).
  4. Not accept BMM, a= lways downvote (i.e. strangle).
  5. Accept BMM, not vote.
  6. 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).
  7. Accept BMM, always upvote (i.e. allow theft).
  8. Ac= cept BMM, always downvote (i.e. strangle).

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 "raise the alarm" and = tell=20 miners to downvote a particular theft withdrawal, but that sounds too=20 much like centralized collusion to me.

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.

Strategies 5->8 are all strictly superior to 1->= ;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)

It seems Drivechain'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.

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't b= e posted (at least as I understand Sztorc's explanation). This chokes= =20 the sidechain withdrawal.

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->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 withdraw= al transactions (WT). This obviously isn'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.

=
-Chris
=C2=A0

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

I think you are mi= ssing 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 ste= al
your coins!", but as I have repeated many times, this is also true of<= br> mainchain btc-tx. =C2=A0is something else?

There are substantial oppor= tunity costs as well as a collective action problem when it comes to re-wri= ting the mainchain.=C2=A0

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

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--