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 BACCA516 for ; Sun, 9 Apr 2017 23:51:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA820FC for ; Sun, 9 Apr 2017 23:51:31 +0000 (UTC) Received: by mail-wm0-f47.google.com with SMTP id t189so25538685wmt.1 for ; Sun, 09 Apr 2017 16:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7w+F+0P3Wl0/MYqF243rMnzxIdM8Hzlnehsc044SdE0=; b=Fw6SlolSR9pUkXfwNgN7ap5b2abYo02VIgqwMkRW92jIx3thBWbtyFjFirOLpUvNjj dwnemBWkgfct1Osu8NQyI914RDD2DbOYyeEDOQe/BIsykfigp7lZ5fJXuAguW//sli8O vZhefiQbzg/3wyY8EhCP6G7WXqI13WIxicixRflExRVfQ6gToiaqjiTybFnkSdp7EnrN cwqqgzyg5iYUCL93SQhmeFZQoYiAVRVbfH7BBYKFD210OBaZlgKyvIHV/yG6InzrdvyX uVKMGBoaqmMkJghZQFfoXQDZZQdBv3LPpTYnKF2vJGJPnNnh5Kw8LNaVgXuwfV07VHjR JW3g== 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=7w+F+0P3Wl0/MYqF243rMnzxIdM8Hzlnehsc044SdE0=; b=pLSm6dcpMbotPSWNZTpzd+8osyiFcZEGvw8kVlFU/S5lX6YJzzQ0lbWmb1uRSAKO9h /U+sGSpKfSxzHBOzQeaZSg8npy4UylQJ+Pv15DZX2FAR3GbUAukLaa5VklVr/b/YYOwS 188a0W03pGeywpklI4emuZODz2bn8XEFFXqIaS/8G7nJhZY6uecL62SYt4wvykNFPb3I SNOyvUM+FI7ZUperyZSwJHG+luHp8eBXvfiG2f2FDW3m+EeIYgZlirFHLQIqrYakG6Ec MqY3Ey+KzwrsI5h5O8VWvgjt9uuoPLxXuGPH29YpexIxXD5it6kYNB0V0rtTM89SdY41 QJ1w== X-Gm-Message-State: AN3rC/6cERaa/RQ30J38QY8XtpGKf8W0Cn1apuuVuCBb1V9IzNSFHe1B BgEaQ4vj6oH9YnkvJyhQ1Bl2oHdRVw== X-Received: by 10.28.146.207 with SMTP id u198mr7534353wmd.103.1491781890183; Sun, 09 Apr 2017 16:51:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.55.9 with HTTP; Sun, 9 Apr 2017 16:51:29 -0700 (PDT) Received: by 10.28.55.9 with HTTP; Sun, 9 Apr 2017 16:51:29 -0700 (PDT) In-Reply-To: References: From: David Vorick Date: Sun, 9 Apr 2017 19:51:29 -0400 Message-ID: To: Jared Lee Richardson Content-Type: multipart/alternative; boundary=001a11442ae0a5999f054cc4895e 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 Cc: Bitcoin Dev 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: Sun, 09 Apr 2017 23:51:32 -0000 --001a11442ae0a5999f054cc4895e Content-Type: text/plain; charset=UTF-8 On Apr 9, 2017 7:00 PM, "Jared Lee Richardson via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: I can speak from personal experience regarding another very prominent altcoin that attempted to utilize an asic-resistant proof of work algorithm, it is only a matter of time before the "asic resistant" algorithm gets its own Asics. The more complicated the algorithm, the more secretive the asic technology is developed. Even without it, multi-megawatt gpu farms have already formed in the areas of the world with low energy costs. I'd support the goal if I thought it possible, but I really don't think centralization of mining can be prevented. On Apr 9, 2017 1:16 PM, "Erik Aronesty via bitcoin-dev" wrote: > Curious: I'm not sure why a serious discussion of POW change is not on the > table as a part of a longer-term roadmap. > > Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of > the proven, np-complete graph-theoretic or polygon manipulation POW would > keep Bitcoin in commodity hardware and out of the hands of centralized > manufacturing for many years. > > 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. > > Perhaps regular, high-consensus POW changes might even be *necessary* as a > part of good maintenance of cryptocurrency in general. Killing the > existing POW, and using an as-yet undefined, but deployment-bit ready POW > field to flip-flop between the current and the "next one" every 8 years or > or so, with a ramp down beginning in the 7th year.... A stub function that > is guaranteed to fail unless a new consensus POW is selected within 7 > years. > > Something like that? > > Haven't thought about it *that* much, but I think the network would > respond well to a well known cutover date. This would enable > rapid-response to quantum tech, or some other needed POW switch as well... > because the mechanisms would be in-place and ready to switch as needed. > > Lots of people seem to panic over POW changes as "irresponsible", but it's > only irresponsible if done irresponsibly. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev The real bottleneck today is the amount of capex required to achieve optimal mining. I am strongly in favor of PoW research that investigates better PoW, but I do not think that any obvious strategies are known yet to improve substantially on computation heavy hashcash. --001a11442ae0a5999f054cc4895e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 9, 2017 7:00 PM, "Jared Lee Richardson via bitcoin-de= v" <bitcoi= n-dev@lists.linuxfoundation.org> wrote:
I can speak from personal experience= regarding another very prominent altcoin that attempted to utilize an asic= -resistant proof of work algorithm, it is only a matter of time before the = "asic resistant" algorithm gets its own Asics.=C2=A0 The more com= plicated the algorithm, the more secretive the asic technology is developed= .=C2=A0 Even without it, multi-megawatt gpu farms have already formed in th= e areas of the world with low energy costs.=C2=A0 I'd support the goal = if I thought it possible, but I really don't think centralization of mi= ning can be prevented.

On Apr 9, 2017 1:16 PM, "Erik Ar= onesty via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org= > wrote:
Curious: I'm not sure why a serious discussion of POW chan= ge is not on the table as a part of a longer-term roadmap.

Done righ= t, a ramp down of reliance on SHA-256 and a ramp-up on some of the proven, = np-complete graph-theoretic or polygon manipulation POW would keep Bitcoin = in commodity hardware and out of the hands of centralized manufacturing for= many years. =C2=A0

Clearly a level-playing field is critical to ke= eping centralization from being a "defining feature" of Bitcoin o= ver the long term. =C2=A0 I've heard the term "level playing field= " bandied about quite a bit. =C2=A0 And it seems to me that the risk o= f state actor control and botnet attacks is less than state-actor manipulat= ion of specialized manufacturing of "SHA-256 forever" hardware. = =C2=A0 Indeed, the reliance on a fairly simple hash seems less and less lik= ely a "feature" and more of a baggage.

Perhaps= regular, high-consensus POW changes might even be *necessary* as a part of= good maintenance of cryptocurrency in general. =C2=A0 Killing the existing= POW, and using an as-yet undefined, but deployment-bit ready POW field to = flip-flop between the current and the "next one" every 8 years or= or so, with a ramp down beginning in the 7th year....=C2=A0 A stub functio= n that is guaranteed to fail unless a new consensus POW is selected within = 7 years. =C2=A0

Something like that? =C2=A0

Haven't tho= ught about it *that* much, but I think the network would respond well to a = well known cutover date. =C2=A0 This would enable rapid-response to quantum= tech, or some other needed POW switch as well... because the mechanisms wo= uld be in-place and ready to switch as needed.

Lot= s of people seem to panic over POW changes as "irresponsible", bu= t it's only irresponsible if done irresponsibly.

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


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


The real bottleneck today is the amount of capex required to achieve op= timal mining. I am strongly in favor of PoW research that investigates bett= er PoW, but I do not think that any obvious strategies are known yet to imp= rove substantially on computation heavy hashcash.
--001a11442ae0a5999f054cc4895e--