summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPaul Sztorc <truthcoin@gmail.com>2017-12-05 14:55:33 -0500
committerbitcoindev <bitcoindev@gnusha.org>2017-12-05 19:55:36 +0000
commitd1dc45bc181f42f632ebc860870ee9f5f1d56495 (patch)
tree81517e702e9cd6adff937ffdba9a73dfef30d3fa
parent21c9faffbf064c10bf589c33f316855595a9adfa (diff)
downloadpi-bitcoindev-d1dc45bc181f42f632ebc860870ee9f5f1d56495.tar.gz
pi-bitcoindev-d1dc45bc181f42f632ebc860870ee9f5f1d56495.zip
Re: [bitcoin-dev] Two Drivechain BIPs
-rw-r--r--2b/425ca50cc4b817bf61fd0df1865714414a789e386
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>
+ &gt;There is another interesting analysis on BMM and drivechains
+ from /u/almkglor on reddit. I'm going to share here for
+ visibility.<br>
+ &gt;&gt; 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>
+ &gt;&gt; ...<br>
+ &gt;&gt;<br>
+ &gt;&gt; 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>
+ &gt;&gt; <br>
+ &gt;&gt; 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>
+ &gt; 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>
+ &gt;<br>
+ &gt;-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">&lt;<a
+ href="mailto:bitcoin-dev@lists.linuxfoundation.org"
+ target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</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--
+