summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorErik Aronesty <earonesty@gmail.com>2017-04-05 23:11:53 -0400
committerbitcoindev <bitcoindev@gnusha.org>2017-04-06 03:11:56 +0000
commitc59e5c3efec0598753f65f52658aa78b528f6558 (patch)
tree79142ecb9294696448157390fc2673d99e195a80
parent662ee6721f5990e90e6e827712afcb1aac7b7005 (diff)
downloadpi-bitcoindev-c59e5c3efec0598753f65f52658aa78b528f6558.tar.gz
pi-bitcoindev-c59e5c3efec0598753f65f52658aa78b528f6558.zip
Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function
-rw-r--r--98/41e4aa06fadba7a7a2a51d09fa443d5346fe65223
1 files changed, 223 insertions, 0 deletions
diff --git a/98/41e4aa06fadba7a7a2a51d09fa443d5346fe65 b/98/41e4aa06fadba7a7a2a51d09fa443d5346fe65
new file mode 100644
index 000000000..4fcd21694
--- /dev/null
+++ b/98/41e4aa06fadba7a7a2a51d09fa443d5346fe65
@@ -0,0 +1,223 @@
+Return-Path: <earonesty@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 03D939BA
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 6 Apr 2017 03:11:56 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com
+ [209.85.220.175])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 32A00136
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 6 Apr 2017 03:11:55 +0000 (UTC)
+Received: by mail-qk0-f175.google.com with SMTP id p22so27477579qka.3
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 05 Apr 2017 20:11:55 -0700 (PDT)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
+ h=mime-version:reply-to:in-reply-to:references:from:date:message-id
+ :subject:to:cc;
+ bh=cWb9X+qSye/XYZUDxDKJ2zoaqbcUHH8YS3cfSxHc/dI=;
+ b=Dqpv6kbZNqJXCzJtIi9/LR42F2m8Tgk2wG2TfDF/97Vg9U6FQgO6MDIPPkk25v4fGE
+ imEwTrOZPd1LcQGtllDM/3fOnUvCTM7WI/Wce7I4J3t3R2++/V/2+R7KWbFLofmKgK4A
+ kZWNC9tCVXJbp/AKPxG9L6dP01SjFXjl6ychoKx/iPhFfjJJe4qAenbvnP0FGHTJKuRs
+ F8VoW//ws7qTKTdUdRAdGx2x7QzOrPYI9Pg0PeSt3nc8ofey1hEfHnPaw1szXboThuuT
+ 5LdFyUCopHRTvge5cMeGLrvNoysPuSC3FMqK4Bsbiu8uEJj/kU6oF+9tuKQ0YjQxE+hc
+ H7UA==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20161025;
+ h=x-gm-message-state:mime-version:reply-to:in-reply-to:references
+ :from:date:message-id:subject:to:cc;
+ bh=cWb9X+qSye/XYZUDxDKJ2zoaqbcUHH8YS3cfSxHc/dI=;
+ b=YEMNMv7pRI0344KrR35As01jTerr48hLmONA22jHr6Jd0BHvnrJciR2S3t7cvfImMt
+ x+KKwdT3nfQ/UDfnxMO8vS0HDzsSI4pXOXiDbto0VdExe2tesiv+FFhA26AyPdHtPKV4
+ u/34hejo0NqIqiZ/44udpe0CDTQjNMCM4Tph3sOh6h8MJclOtQEM6+PGMEje2+AM62Bs
+ KKHY06IPsjj7Su2T8P6usEbBgFXDpZtsytHwbOVSufxfai3w0xJnsJEL0+C0Myc0Dp0e
+ /nddVo5QvHL+7eORn1mPsa7iAbmjFHYWqJxeR7iW4HGUie4gdJdx+QX/1OR6i9X6vGrY
+ TIaQ==
+X-Gm-Message-State: AFeK/H07xTBGBaNn5MDPwX7FotQmLAWsZlv0YPZOc+MYz0gQHLWkKHoVThR/IPIbP/AYOUr+CC+nCM5hPr/98w==
+X-Received: by 10.55.33.207 with SMTP id f76mr24221579qki.85.1491448314353;
+ Wed, 05 Apr 2017 20:11:54 -0700 (PDT)
+MIME-Version: 1.0
+Received: by 10.200.55.113 with HTTP; Wed, 5 Apr 2017 20:11:53 -0700 (PDT)
+Received: by 10.200.55.113 with HTTP; Wed, 5 Apr 2017 20:11:53 -0700 (PDT)
+Reply-To: erik@q32.com
+In-Reply-To: <20170406024910.GA1271@savin.petertodd.org>
+References: <CAAS2fgR84898xD0nyq7ykJnB7qkdoCJYnFg6z5WZEUu0+-=mMA@mail.gmail.com>
+ <20170406023123.GA1071@savin.petertodd.org>
+ <CA+KqGkqSxeAUZFVFqM_QkEWcGFHgZXwGuOE==7HpXp1+D_Tj3Q@mail.gmail.com>
+ <20170406024910.GA1271@savin.petertodd.org>
+From: Erik Aronesty <earonesty@gmail.com>
+Date: Wed, 5 Apr 2017 23:11:53 -0400
+Message-ID: <CAJowKgL_BfJyyp=z6PB3mj+KBy0y9ParspbbnhoOTA0Cfr6C6g@mail.gmail.com>
+To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
+ Peter Todd <pete@petertodd.org>
+Content-Type: multipart/alternative; boundary=001a1144dcd6fa66d1054c76ded2
+X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
+ RCVD_IN_DNSWL_NONE,
+ RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
+ smtp1.linux-foundation.org
+X-Mailman-Approved-At: Thu, 06 Apr 2017 03:15:58 +0000
+Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the
+ Bitcoin POW function
+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: Thu, 06 Apr 2017 03:11:56 -0000
+
+--001a1144dcd6fa66d1054c76ded2
+Content-Type: text/plain; charset=UTF-8
+
+If the primary purpose of pow is to destroy value, then a masked proof of
+burn to an expanded address that assigns the private key holder the right
+to mine only in the next Nth block would be sufficient. Expanding the
+address space so that addresses can only be proven invalid only with the
+private key. Miners can then not trivially game the system by excluding
+tx...without killing the entire system. ( Like POW ... miners lose many
+burns since only one valid proof is deterministically selected. Difficult
+adjusted upward based on the number of valid proofs per block.)
+
+The other part of "real POW" is that miners take *time* to mine. Proof of
+destroyed value us not sufficient. Proof of time spent is critical....
+something even a masked burn cannot provide.
+
+On Apr 5, 2017 10:49 PM, "Peter Todd via bitcoin-dev" <
+bitcoin-dev@lists.linuxfoundation.org> wrote:
+
+> On Wed, Apr 05, 2017 at 07:39:08PM -0700, Bram Cohen wrote:
+> > On Wed, Apr 5, 2017 at 7:31 PM, Peter Todd via bitcoin-dev <
+> > > While I'm in favour of blocking covert usage of ASICBOOST, there's
+> every
+> > > reason
+> > > to block non-covert usage of it as well. In a low margin business like
+> > > mining,
+> > > the advatange it gives is enormous - quite possibly 10x your profit
+> margin
+> > > -
+> > > and given that barrier free access to being able to purchase ASICs is
+> > > already
+> > > an archilles heal for Bitcoin there is every reason to eliminate this
+> legal
+> > > vulnerability. Additionally, it's a technical vulnerability as well: we
+> > > want
+> > > getting into the ASIC manufacturing and design business to have as low
+> > > barriers
+> > > to entry as is feasible, and the ASICBOOST exploit significantly
+> increases
+> > > the
+> > > minimum capital requirements to do so.
+> > >
+> >
+> > Asicboost also has the problem that it isn't treating the hashing as a
+> > black box, and thus has impacts on what gets mined. In particular it
+> > creates an incentive to make blocks smaller. That's a very unwanted
+> effect,
+> > and anything like it should be engineered out on principle.
+>
+> Agreed! There's no benefit to Bitcoin for having it - one way or the other
+> miners are going to destroy ~12BTC/block worth of energy. Meanwhile it
+> appears
+> to have lead to something like a year of stupid political bullshit based
+> on a
+> secret advantage - there's no reason to invite a repeat of this episode.
+>
+> --
+> https://petertodd.org 'peter'[:-1]@petertodd.org
+>
+> _______________________________________________
+> bitcoin-dev mailing list
+> bitcoin-dev@lists.linuxfoundation.org
+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+>
+
+--001a1144dcd6fa66d1054c76ded2
+Content-Type: text/html; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"auto">If the primary purpose of pow is to destroy value, then a=
+ masked proof of burn to an expanded address that assigns the private key h=
+older the right to mine only in the next Nth block would be sufficient.=C2=
+=A0 Expanding the address space so that addresses can only be proven invali=
+d only with the private key.=C2=A0 Miners can then not trivially game the s=
+ystem by excluding tx...without killing the entire system. =C2=A0( Like POW=
+ ... miners lose many burns since only one valid proof is deterministically=
+ selected. Difficult adjusted upward based on the number of valid proofs pe=
+r block.)<div dir=3D"auto"><br></div><div dir=3D"auto">The other part of &q=
+uot;real POW&quot; is that miners take *time* to mine.=C2=A0 Proof of destr=
+oyed value us not sufficient.=C2=A0 Proof of time spent is critical.... som=
+ething even a masked burn cannot provide.</div></div><div class=3D"gmail_ex=
+tra"><br><div class=3D"gmail_quote">On Apr 5, 2017 10:49 PM, &quot;Peter To=
+dd via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
+ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"=
+attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
+order-left:1px #ccc solid;padding-left:1ex">On Wed, Apr 05, 2017 at 07:39:0=
+8PM -0700, Bram Cohen wrote:<br>
+&gt; On Wed, Apr 5, 2017 at 7:31 PM, Peter Todd via bitcoin-dev &lt;<br>
+&gt; &gt; While I&#39;m in favour of blocking covert usage of ASICBOOST, th=
+ere&#39;s every<br>
+&gt; &gt; reason<br>
+&gt; &gt; to block non-covert usage of it as well. In a low margin business=
+ like<br>
+&gt; &gt; mining,<br>
+&gt; &gt; the advatange it gives is enormous - quite possibly 10x your prof=
+it margin<br>
+&gt; &gt; -<br>
+&gt; &gt; and given that barrier free access to being able to purchase ASIC=
+s is<br>
+&gt; &gt; already<br>
+&gt; &gt; an archilles heal for Bitcoin there is every reason to eliminate =
+this legal<br>
+&gt; &gt; vulnerability. Additionally, it&#39;s a technical vulnerability a=
+s well: we<br>
+&gt; &gt; want<br>
+&gt; &gt; getting into the ASIC manufacturing and design business to have a=
+s low<br>
+&gt; &gt; barriers<br>
+&gt; &gt; to entry as is feasible, and the ASICBOOST exploit significantly =
+increases<br>
+&gt; &gt; the<br>
+&gt; &gt; minimum capital requirements to do so.<br>
+&gt; &gt;<br>
+&gt;<br>
+&gt; Asicboost also has the problem that it isn&#39;t treating the hashing =
+as a<br>
+&gt; black box, and thus has impacts on what gets mined. In particular it<b=
+r>
+&gt; creates an incentive to make blocks smaller. That&#39;s a very unwante=
+d effect,<br>
+&gt; and anything like it should be engineered out on principle.<br>
+<br>
+Agreed! There&#39;s no benefit to Bitcoin for having it - one way or the ot=
+her<br>
+miners are going to destroy ~12BTC/block worth of energy. Meanwhile it appe=
+ars<br>
+to have lead to something like a year of stupid political bullshit based on=
+ a<br>
+secret advantage - there&#39;s no reason to invite a repeat of this episode=
+.<br>
+<br>
+--<br>
+<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
+s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
+ rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
+<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></div>
+
+--001a1144dcd6fa66d1054c76ded2--
+