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 A33FC360 for ; Mon, 10 Apr 2017 00:20:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DCFD37C for ; Mon, 10 Apr 2017 00:20:50 +0000 (UTC) Received: by mail-qk0-f181.google.com with SMTP id p22so96789486qka.3 for ; Sun, 09 Apr 2017 17:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4pGhRAD9O+Lw7nslvaL17iRtAg9HSg22Fds8RcDltco=; b=Lz7HYgrmr7py8Pcu7gKcWYsP3BKd1/shlUDjU2leFPOK3FdW6NYH8AU7xN6xU53xXT jFNGMzjlgUa8S5CF6io8hM0Eag+01xc2eg4Ml7X3UPhpNs2oQfTk6bmvD05TbbgNLExt 3hWCpsh1cq1NnWsyEOCxqJwlMaI3DVAQbi0g22SGUP0WRB4w7onRmz4OzyrDczO7tLUZ S2UFYqD/CCwRFoo7K3TK9ffZZQjLms4EetdVHAOYAwPav+jDf/7aM/q6WrYTYF3uutqr 54UNuy4iZ/cTwbwSbupf5f00UM3QR/BxbyiLKgvQUmndxb+DyEHKt7b+EWTAvc554m+e F2jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4pGhRAD9O+Lw7nslvaL17iRtAg9HSg22Fds8RcDltco=; b=QcTZm5dVSlVkJ1H1wFlLmQaScyoisVx7DA+fohBvUQ9UoAhPl4aZnSAViLG7VxmlQj Uuxl3I3sz72n6OyJJ4Wl7RwVZTu6B8ghY4DHDkFsO8KAMKOnj7gVJcVKDuSo9buSeTOy SkGcHP7D6ZkSqgFXkVj9kgGoekoxEWFTI042aXnSpchsVnEx9isZQY+AM9iq4FuSVKlX Yin5VvBoeF1xgkmoBlJSPq+RqRNc8M0xw12KrtTvYXJpYL2UVnbExNsGzh/sUuQ8qzvb oTNABknsvu6JIrmYiEjL/hs3t9U2pn/sQXhmYUUOtZhk+de1kfe6ehKjMp7YjTmL6tah n2iA== X-Gm-Message-State: AFeK/H2KLvVVdnrqmgceZK/Pu+ET8OjdnQmVkdFD5wqkivzSmcc8fQo4ZI+k3GwnGDTv55dtwW94h2bhnAim6Q== X-Received: by 10.55.170.215 with SMTP id t206mr37430718qke.303.1491783650059; Sun, 09 Apr 2017 17:20:50 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.200.0.146 with HTTP; Sun, 9 Apr 2017 17:20:49 -0700 (PDT) Received: by 10.200.0.146 with HTTP; Sun, 9 Apr 2017 17:20:49 -0700 (PDT) In-Reply-To: References: From: Erik Aronesty Date: Sun, 9 Apr 2017 20:20:49 -0400 X-Google-Sender-Auth: m_GJ05akky_aBNYvWm56o5PkltI Message-ID: To: David Vorick Content-Type: multipart/alternative; boundary=94eb2c0654d28b2be0054cc4f26c X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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: Mon, 10 Apr 2017 00:50:59 +0000 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 00:20:51 -0000 --94eb2c0654d28b2be0054cc4f26c Content-Type: text/plain; charset=UTF-8 Have you read the cuckoo cycle paper? Finding cycles in massive graphs is just about the worst thing to use an ASIC for. It might be a hitherto before unknown emergent property of cryptocurrencies in general that POW *must* change every 7-9 years. Could bake that into the protocol too... On Apr 9, 2017 7:51 PM, "David Vorick" wrote: > > > 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" < > bitcoin-dev@lists.linuxfoundation.org> 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. > --94eb2c0654d28b2be0054cc4f26c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Have you read the cuckoo cycle paper?=C2=A0 Finding cycle= s in massive graphs is just about the worst thing to use an ASIC for.

It might be a hitherto before unkno= wn emergent property of cryptocurrencies in general that POW *must* change = every 7-9 years.=C2=A0 Could bake that into the protocol too...
=

On Apr 9, 2017 7:= 51 PM, "David Vorick" <david.vorick@gmail.com> wrote:

=
On Apr 9, 2017 7:00 PM, "Jared Lee Rich= ardson via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org= > wrote:
I can speak from personal experience regardin= g another very prominent altcoin that attempted to utilize an asic-resistan= t proof of work algorithm, it is only a matter of time before the "asi= c resistant" algorithm gets its own Asics.=C2=A0 The more complicated = the algorithm, the more secretive the asic technology is developed.=C2=A0 E= ven without it, multi-megawatt gpu farms have already formed in the areas o= f the world with low energy costs.=C2=A0 I'd support the goal if I thou= ght 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" <bitcoin-dev@lists.linuxfounda= tion.org> wrote:
Curious: I'm not sure why a serious discussio= n 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 manu= facturing for many years. =C2=A0

Clearly a level-playing field is c= ritical to keeping centralization from being a "defining feature"= of Bitcoin over 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 th= at the risk of state actor control and botnet attacks is less than state-ac= tor 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.

=
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 P= OW field to flip-flop between the current and the "next one" ever= y 8 years or or so, with a ramp down beginning in the 7th year....=C2=A0 A = stub function that is guaranteed to fail unless a new consensus POW is sele= cted within 7 years. =C2=A0

Something like that? =C2=A0

Hav= en't thought about it *that* much, but I think the network would respon= d well to a well known cutover date. =C2=A0 This would enable rapid-respons= e to quantum tech, or some other needed POW switch as well... because the m= echanisms would be in-place and ready to switch as needed.

Lots of people seem to panic over POW changes as "irresponsib= le", 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 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.
--94eb2c0654d28b2be0054cc4f26c--