Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 03D939BA for ; 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 ; Thu, 6 Apr 2017 03:11:55 +0000 (UTC) Received: by mail-qk0-f175.google.com with SMTP id p22so27477579qka.3 for ; 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: <20170406023123.GA1071@savin.petertodd.org> <20170406024910.GA1271@savin.petertodd.org> From: Erik Aronesty Date: Wed, 5 Apr 2017 23:11:53 -0400 Message-ID: To: Bitcoin Protocol Discussion , Peter Todd 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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.)

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.

On Apr 5, 2017 10:49 PM, "Peter To= dd via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Wed, Apr 05, 2017 at 07:39:0= 8PM -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, th= ere'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 prof= it margin
> > -
> > and given that barrier free access to being able to purchase ASIC= s is
> > already
> > an archilles heal for Bitcoin there is every reason to eliminate = this legal
> > vulnerability. Additionally, it's a technical vulnerability a= s well: we
> > want
> > getting into the ASIC manufacturing and design business to have a= s 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 unwante= d 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 ot= her
miners are going to destroy ~12BTC/block worth of energy. Meanwhile it appe= ars
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= .

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--001a1144dcd6fa66d1054c76ded2--