From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BD6A194B for ; Mon, 10 Apr 2017 14:34:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 40F3A14F for ; Mon, 10 Apr 2017 14:34:51 +0000 (UTC) Received: by mail-io0-f174.google.com with SMTP id l7so97226300ioe.3 for ; Mon, 10 Apr 2017 07:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bittorrent-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZZDn48k2buJA+gaGU377/jJ8l0rjP5cedDHWawqH9xw=; b=yCyzmeQk/o1br5HqXh/3qR4wKi4UFIA5AEojXRsX5XGFZaO0qGi+Zlr6gqN1EJ6ihc WFE6vhCtnauhDNP/ScHCPdlgvCo27/KsuTXmUrlwirna+HPkshHZagta+Gj8i/8iyKR3 PpV7B3g85RK2QcKsvd6q+VJeG79WCHHnckq2PhW6H1H6+ByO+qayd32NkLMNXVDwNSu8 496cpuhWJdP8Jj2xRxyU/xo5aAF7N2c4hkjuIr9znqmE2XjTA0yTvDFTaecwMkyuI35K Nsl2qqHSOHybLWxINb3uJb0deR/zsMbbLXKeRx3A0tRCKjmtBxZBj8dK6JRFlQNybZeT SWoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZZDn48k2buJA+gaGU377/jJ8l0rjP5cedDHWawqH9xw=; b=WBxchaYQdwS4n/hG+M2Tf6Usp0nHpNCpkOnkLa5ZznayD5b/cNJYTz2lFlmmUjyyiC /226llhUa/h0gXmfhViZeu7VM7Zy1jXkOSh3AUvGULsErvRVgxLd7q2y6OCVTH3bjCxu zFPVvuR2TLFrTNF2ADpIQadNrWUDIspfXrKKx+ZxGlDRCZH4lcZLGV9a662m4CwKxV1w Qcrk/wmnMxk12Ndv6+VMAS26Z84UFngCokuxVoC7G9hK8L+OB5jmOGAUxhHXoM2qtb0o MyhQToKpIyDKRJEa67ZtMUolXGaIoNsLoN23vaTpO+NaJTRKqnGjTUwL8bJINXfnMEG1 z42w== X-Gm-Message-State: AN3rC/6yUZY1UH/O4oxhjEj8RqJL0pvL1r0DhnLyeyaCqTs162e52kOa mJupR7qCp/xjogwEDuJzPYKFFNEZehzE X-Received: by 10.36.0.145 with SMTP id 139mr9114249ita.98.1491834888396; Mon, 10 Apr 2017 07:34:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.202.193 with HTTP; Mon, 10 Apr 2017 07:34:47 -0700 (PDT) In-Reply-To: References: From: Bram Cohen Date: Mon, 10 Apr 2017 07:34:47 -0700 Message-ID: To: Erik Aronesty Content-Type: multipart/alternative; boundary=001a11c142109d92d3054cd0e031 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] A Small Modification to Segwit 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: Mon, 10 Apr 2017 14:34:51 -0000 --001a11c142109d92d3054cd0e031 Content-Type: text/plain; charset=UTF-8 On Sun, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Clearly a level-playing field is critical to keeping centralization from > being a "defining feature" of Bitcoin over the long term. I've heard the > term "level playing field" bandied about quite a bit. And it seems to me > that the risk of state actor control and botnet attacks is less than > state-actor manipulation of specialized manufacturing of "SHA-256 forever" > hardware. Indeed, the reliance on a fairly simple hash seems less and > less likely a "feature" and more of a baggage. > > Whatever your hashing function the bottleneck for mining will be power. Equihash and Cuckoo are serious attempts at making custom hardware have no benefit over commodity hardware, but that's more about getting rid of custom hardware manufacturers than it is about mining decentralization, although arguably if successful it might let botnets back in, which would improve decentralization. While those have been surprisingly successful at resisting hardware so far, they might eventually fall as well, and if they do they'll have even worse properties of centralizing around a mining hardware manufacturer than sha256 does. It would be much safer to go the other way, to a PoW function whose best hardware implementation is particularly straightforward and well understood. In that case it would be best to go with sha3. Sha3 also has the benefit of using the sponge construction, which makes it particularly resistant to asciboost-type attacks. It was picked out specifically because its design from a security standpoint was particularly confidence-inspiring, and in this case it actually makes a difference. Arguably you could also go with blake2b, whose 1024 bit block size completely obviates the asicboost concern entirely by cramming everything into a single block. That also might have an even simpler design in hardware than sha3, but a real expert would need to opine on that one. --001a11c142109d92d3054cd0e031 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Clearly a level-playing field= is critical to keeping centralization from being a "defining feature&= quot; of Bitcoin over the long term. =C2=A0 I've heard the term "l= evel playing field" bandied about quite a bit. =C2=A0 And it seems to = me that the risk of state actor control and botnet attacks is less than sta= te-actor manipulation of specialized manufacturing of "SHA-256 forever= " hardware. =C2=A0 Indeed, the reliance on a fairly simple hash seems = less and less likely a "feature" and more of a baggage.

<= /div>

Whatever your hashing function = the bottleneck for mining will be power. Equihash and Cuckoo are serious at= tempts at making custom hardware have no benefit over commodity hardware, b= ut that's more about getting rid of custom hardware manufacturers than = it is about mining decentralization, although arguably if successful it mig= ht let botnets back in, which would improve decentralization. While those h= ave been surprisingly successful at resisting hardware so far, they might e= ventually fall as well, and if they do they'll have even worse properti= es of centralizing around a mining hardware manufacturer than sha256 does.<= /div>

It would be much safer to go the other way, to a P= oW function whose best hardware implementation is particularly straightforw= ard and well understood. In that case it would be best to go with sha3. Sha= 3 also has the benefit of using the sponge construction, which makes it par= ticularly resistant to asciboost-type attacks. It was picked out specifical= ly because its design from a security standpoint was particularly confidenc= e-inspiring, and in this case it actually makes a difference. Arguably you = could also go with blake2b, whose 1024 bit block size completely obviates t= he asicboost concern entirely by cramming everything into a single block. T= hat also might have an even simpler design in hardware than sha3, but a rea= l expert would need to opine on that one.
--001a11c142109d92d3054cd0e031--