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 385A4BDA for ; Tue, 5 Dec 2017 19:55:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f172.google.com (mail-ua0-f172.google.com [209.85.217.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF74B413 for ; Tue, 5 Dec 2017 19:55:34 +0000 (UTC) Received: by mail-ua0-f172.google.com with SMTP id e10so1145557uah.10 for ; Tue, 05 Dec 2017 11:55:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=VSVJOzCCCR5lSQzy1wT9uU+4GTnqpPC7dT1CtUa2BUY=; b=qKxxmB2aE+i9gaq2gER2L/Ij2vYnM3p2MAKyzoYc/dEBXNR57T/pO17iznt9AtapD5 t03lysatpn1w4SpK+3siSjeppEM03GE8M1acIzva7gxO6YXG2mU/z0BTKds7XbaSJYpE isqyQeHhr6FB7FAAj6o8aE3epNpbuRjF3f7VwYUFsfYM4cabUqXsqFE3PFxx6NkgKlll qgitopqOZ4qspcgAjEYoLonl9iLrZEBBWhDu4u9+b+s6bFw06YycMhr0vYKjZT8MJZi6 HHmzh4woIZgPDLW5Wltvvxhz6ZNem/a6PXfZRRJTFOisWH7FzkLfnfWrqwpNRsYd4Z6E agaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=VSVJOzCCCR5lSQzy1wT9uU+4GTnqpPC7dT1CtUa2BUY=; b=q6CN7KL6TgwMx1TqxOHFPP9j8TdWF+Bh4YFkypwVu4OqP4/UaaOVErTmfcSzyHhuXe /lI5zkTECCVxaRzjklNjqy4PHHp8f6xvHW0XQuwZhJLKd8QRG1LbL+ixQWXY4wL56UDX m0sPdxLoAy0P8fyxHYY4S8t1KV1XfAVKsGtQJSjdSzeU5o+ly+ZMqzwKtdOONz8r3PZ2 UiirudcbEfsUQ/ZEgUnHBjNbn4Wa355zaGvLHAiob8QObx6GS4O17+um1JNBW0z5ocAX anzVJ04cuzvEI94Fjv1QdlhjbgrM24fnRmuuBEOjIG+eEp+sFRk67jv4pxwjww447sKn LHGA== X-Gm-Message-State: AKGB3mLLF/GqZCTCyCsd9WVJ1vI+RdoLYjSmD1UAIs46F7tGD6u9jUuJ f8XuuGsLL9ZPdOosUeW4e+NMGQ== X-Google-Smtp-Source: AGs4zMYKY91U/aRrTD2NpSV+0CKUThAQA1Er//ieTNjSKbDU/0lSfNrZiM2Y0HIrF6VOQbZ8S0PXMg== X-Received: by 10.176.90.108 with SMTP id m41mr6197552uad.178.1512503733457; Tue, 05 Dec 2017 11:55:33 -0800 (PST) Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net. [69.114.110.251]) by smtp.googlemail.com with ESMTPSA id p18sm431904vkd.17.2017.12.05.11.55.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 11:55:32 -0800 (PST) To: Bitcoin Protocol Discussion References: <1bb6cccd-3f6d-d62a-2825-4e6f46a4b525@mattcorallo.com> From: Paul Sztorc Message-ID: Date: Tue, 5 Dec 2017 14:55:33 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------990D476ECC191B99853130EF" Content-Language: en-US X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 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: Tue, 05 Dec 2017 19:55:36 -0000 This is a multi-part message in MIME format. --------------990D476ECC191B99853130EF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Other Chris, Thanks for pointing this out. Here are my responses. On 12/4/2017 3:11 PM, Chris Stewart wrote: >There is another interesting analysis on BMM and drivechains from /u/almkglor on reddit. I'm going to share here for visibility. >> 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. Well, that is simply not what "centralized" means. "Centralized" means that one person has special, irreplaceable influence. In contrast, "decentralized" means that the process is not uniquely influenced by what any *one* individual does or believes. Which is the case here: each miner can independently make a decision about what to check, how to check it, and what to do as a result. They could do undertake this process, even if they ignored what everyone else was doing. >> ... >> >> 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. This is a good question. The answer is that there are mechanisms in place to address these problems. Contrary to the reviewer's interpretation, multiple withdrawal-attempts *are* allowed simultaneously. (This part of design may have changed between now and Nov 2015, and I'm not sure if it was ever documented anywhere until very recently). Second, only one withdrawal can be upvoted at a time [ie, per sidechain per main:block]. Third, upvoting one withdrawal automatically downvotes all of the other withdrawals (all in-progress withdrawals for that sidechain). Thus, we have the asymmetry we desire. An "auditor class" can ignore all of the withdrawals, until a significant amount of time has been invested in one candidate. This makes the attempt more futile. Since they are unlikely to be meaninglessly harassed, this opens the door to a "farmer class" who can take it upon themselves to make sure the good withdrawals get in, and get upvotes (especially early upvotes). Thus, the system can tolerate a large "loafer class" who just lazily upvotes everything (or nothing, or only the front-runner). > 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 I agree that miners should "always accept BMM bribes". In my recent email to Matt Corallo, I described that this is basically the same as saying that miners should "always mine on top of the heaviest chain". (Of course, in mainchain Bitcoin miners are advised to mine atop the heaviest *valid* chain, which is different from this case. It is different because blind-merged-miners have no way of knowing if the sidechain blocks they are mining are valid or not, which is kind of the point. In practice I estimate that between 70% and 100% of today's hashpower is already mining the mainchain "blind" -- through some combination of pools, spv and spy mining.) I don't agree with the conclusion (that the optimal policy is "always downvoting", see above), but even if this analysis turns out to be correct, it isn't a total disaster. The result (which is in the original Nov 2015 specification) is that miners are the ones who perform the atomic swaps. Then they walk the coins side-to-main (which, at this point, are *their* coins). As long as there are a few large mining groups, competition will drive the atomic swap fees down to negligible levels. This slightly encourages mining to consolidate into two large pools...but of course that is also true of the status quo! Paul =C2=A0 > > On Mon, Dec 4, 2017 at 1:36 PM, Chris Pacia via bitcoin-dev > > 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. =C2=A0is something else? > > > There are substantial opportunity costs as well as a collective > action problem when it comes to re-writing 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 collective 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 > > > --------------990D476ECC191B99853130EF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Other Chris,

Thanks for pointing this out. Here are my responses.

On 12/4/2017 3:11 PM, Chris Stewart wrote:
>There is another interesting analysis on BMM and drivechains from /u/almkglor on reddit. I'm going to share here for visibility.
>> 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.

Well, that is simply not what "centralized" means. "Centralized" means that one person has special, irreplaceable influence. In contrast, "decentralized" means that the process is not uniquely influenced by what any *one* individual does or believes. Which is the case here: each miner can independently make a decision about what to check, how to check it, and what to do as a result. They could do undertake this process, even if they ignored what everyone else was doing.

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

This is a good question.

The answer is that there are mechanisms in place to address these problems. Contrary to the reviewer's interpretation, multiple withdrawal-attempts *are* allowed simultaneously. (This part of design may have changed between now and Nov 2015, and I'm not sure if it was ever documented anywhere until very recently). Second, only one withdrawal can be upvoted at a time [ie, per sidechain per main:block]. Third, upvoting one withdrawal automatically downvotes all of the other withdrawals (all in-progress withdrawals for that sidechain). Thus, we have the asymmetry we desire. An "auditor class" can ignore all of the withdrawals, until a significant amount of time has been invested in one candidate. This makes the attempt more futile. Since they are unlikely to be meaninglessly harassed, this opens the door to a "farmer class" who can take it upon themselves to make sure the good withdrawals get in, and get upvotes (especially early upvotes). Thus, the system can tolerate a large "loafer class" who just lazily upvotes everything (or nothing, or only the front-runner).

> 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

I agree that miners should "always accept BMM bribes". In my recent email to Matt Corallo, I described that this is basically the same as saying that miners should "always mine on top of the heaviest chain". (Of course, in mainchain Bitcoin miners are advised to mine atop the heaviest *valid* chain, which is different from this case. It is different because blind-merged-miners have no way of knowing if the sidechain blocks they are mining are valid or not, which is kind of the point. In practice I estimate that between 70% and 100% of today's hashpower is already mining the mainchain "blind" -- through some combination of pools, spv and spy mining.)

I don't agree with the conclusion (that the optimal policy is "always downvoting", see above), but even if this analysis turns out to be correct, it isn't a total disaster. The result (which is in the original Nov 2015 specification) is that miners are the ones who perform the atomic swaps. Then they walk the coins side-to-main (which, at this point, are *their* coins). As long as there are a few large mining groups, competition will drive the atomic swap fees down to negligible levels. This slightly encourages mining to consolidate into two large pools...but of course that is also true of the status quo!

Paul
 

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



--------------990D476ECC191B99853130EF--