diff options
author | Erik Aronesty <earonesty@gmail.com> | 2017-04-05 23:11:53 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-04-06 03:11:56 +0000 |
commit | c59e5c3efec0598753f65f52658aa78b528f6558 (patch) | |
tree | 79142ecb9294696448157390fc2673d99e195a80 | |
parent | 662ee6721f5990e90e6e827712afcb1aac7b7005 (diff) | |
download | pi-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/41e4aa06fadba7a7a2a51d09fa443d5346fe65 | 223 |
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" 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, "Peter To= +dd via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfound= +ation.org">bitcoin-dev@lists.linuxfoundation.org</a>> 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> +> On Wed, Apr 5, 2017 at 7:31 PM, Peter Todd via bitcoin-dev <<br> +> > While I'm in favour of blocking covert usage of ASICBOOST, th= +ere's every<br> +> > reason<br> +> > to block non-covert usage of it as well. In a low margin business= + like<br> +> > mining,<br> +> > the advatange it gives is enormous - quite possibly 10x your prof= +it margin<br> +> > -<br> +> > and given that barrier free access to being able to purchase ASIC= +s is<br> +> > already<br> +> > an archilles heal for Bitcoin there is every reason to eliminate = +this legal<br> +> > vulnerability. Additionally, it's a technical vulnerability a= +s well: we<br> +> > want<br> +> > getting into the ASIC manufacturing and design business to have a= +s low<br> +> > barriers<br> +> > to entry as is feasible, and the ASICBOOST exploit significantly = +increases<br> +> > the<br> +> > minimum capital requirements to do so.<br> +> ><br> +><br> +> Asicboost also has the problem that it isn't treating the hashing = +as a<br> +> black box, and thus has impacts on what gets mined. In particular it<b= +r> +> creates an incentive to make blocks smaller. That's a very unwante= +d effect,<br> +> and anything like it should be engineered out on principle.<br> +<br> +Agreed! There'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'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> 'peter'[:-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-- + |