diff options
author | Paul Sztorc <truthcoin@gmail.com> | 2017-12-05 14:55:33 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-12-05 19:55:36 +0000 |
commit | d1dc45bc181f42f632ebc860870ee9f5f1d56495 (patch) | |
tree | 81517e702e9cd6adff937ffdba9a73dfef30d3fa | |
parent | 21c9faffbf064c10bf589c33f316855595a9adfa (diff) | |
download | pi-bitcoindev-d1dc45bc181f42f632ebc860870ee9f5f1d56495.tar.gz pi-bitcoindev-d1dc45bc181f42f632ebc860870ee9f5f1d56495.zip |
Re: [bitcoin-dev] Two Drivechain BIPs
-rw-r--r-- | 2b/425ca50cc4b817bf61fd0df1865714414a789e | 386 |
1 files changed, 386 insertions, 0 deletions
diff --git a/2b/425ca50cc4b817bf61fd0df1865714414a789e b/2b/425ca50cc4b817bf61fd0df1865714414a789e new file mode 100644 index 000000000..9365c0a27 --- /dev/null +++ b/2b/425ca50cc4b817bf61fd0df1865714414a789e @@ -0,0 +1,386 @@ +Return-Path: <truthcoin@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 385A4BDA + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 5 Dec 2017 19:55:34 +0000 (UTC) +Received: by mail-ua0-f172.google.com with SMTP id e10so1145557uah.10 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org> + (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 <bitcoin-dev@lists.linuxfoundation.org> +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> + <CAGL6+mF1YbjZ28MtvPxTye-HndEqmd6LkaFVr9BWvPiK-kfVTA@mail.gmail.com> +From: Paul Sztorc <truthcoin@gmail.com> +Message-ID: <b0c3f0f9-72f4-b73e-f5b1-e5590f9456aa@gmail.com> +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: <CAGL6+mF1YbjZ28MtvPxTye-HndEqmd6LkaFVr9BWvPiK-kfVTA@mail.gmail.com> +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 <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: 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 +> <bitcoin-dev@lists.linuxfoundation.org +> <mailto: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. =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 +> <mailto:bitcoin-dev@lists.linuxfoundation.org> +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> +> +> + + +--------------990D476ECC191B99853130EF +Content-Type: text/html; charset=utf-8 +Content-Transfer-Encoding: 8bit + +<html> + <head> + <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> + </head> + <body text="#000000" bgcolor="#FFFFFF"> + <div dir="ltr">Hi Other Chris,<br> + <br> + Thanks for pointing this out. Here are my responses.<br> + <br> + On 12/4/2017 3:11 PM, Chris Stewart wrote:<br> + >There is another interesting analysis on BMM and drivechains + from /u/almkglor on reddit. I'm going to share here for + visibility.<br> + >> 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.<br> + <br> + 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.<br> + <br> + >> ...<br> + >><br> + >> 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.<br> + >> <br> + >> 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.<br> + <br> + This is a good question.<br> + <br> + 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).<br> + <br> + > 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.<br> + ><br> + >-Chris<br> + <br> + 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.)<br> + <br> + 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!<br> + <br> + Paul + <div> </div> + </div> + <blockquote type="cite" +cite="mid:CAGL6+mF1YbjZ28MtvPxTye-HndEqmd6LkaFVr9BWvPiK-kfVTA@mail.gmail.com"> + <div class="gmail_extra"><br> + <div class="gmail_quote">On Mon, Dec 4, 2017 at 1:36 PM, Chris + Pacia via bitcoin-dev <span dir="ltr"><<a + href="mailto:bitcoin-dev@lists.linuxfoundation.org" + target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>></span> + wrote:<br> + <blockquote class="gmail_quote" style="margin:0 0 0 + .8ex;border-left:1px #ccc solid;padding-left:1ex"> + <div dir="auto"> + <div><br> + <div class="gmail_extra"> + <div class="gmail_quote"> + <blockquote class="m_4849272993808656596quote" + style="margin:0 0 0 .8ex;border-left:1px #ccc + solid;padding-left:1ex"><span class=""> + <div class="m_4849272993808656596quoted-text">I + think you are missing 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 "but with + sidechains 51% hashrate can steal<br> + your coins!", but as I have repeated many times, + this is also true of<br> + </span> + mainchain btc-tx. is something else?<br> + </blockquote> + </div> + </div> + </div> + <div dir="auto"><br> + </div> + <div dir="auto">There are substantial opportunity costs as + well as a collective action problem when it comes to + re-writing the mainchain. </div> + <div dir="auto"><br> + </div> + <div dir="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 + collective action barrier that needs to be overcome. </div> + <div dir="auto"><br> + </div> + <div dir="auto">Unless I'm missing something I wouldn't + liken the security of a drivechain to that of the + mainchain.</div> + </div> + <br> + ______________________________<wbr>_________________<br> + bitcoin-dev mailing list<br> + <a href="mailto:bitcoin-dev@lists.linuxfoundation.org" + moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br> + <a + href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" + rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br> + <br> + </blockquote> + </div> + <br> + </div> + </blockquote> + <p><br> + </p> + </body> +</html> + +--------------990D476ECC191B99853130EF-- + |