From mboxrd@z Thu Jan 1 00:00:00 1970 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 A33FC360 for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; Mon, 10 Apr 2017 00:20:50 +0000 (UTC) Received: by mail-qk0-f181.google.com with SMTP id p22so96789486qka.3 for <bitcoin-dev@lists.linuxfoundation.org>; 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: <CAFVRnyoqfzJevK5m68bhBuAvUui+eAQsD9ngwDKuGWxVjRBJwQ@mail.gmail.com> References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com> <Cwhn7YzwaDUZtOygDAgrU1UXjRPG-EiH3Fyz2c95gqOpNnNbiYL1NvhS28yK5wLJCnIqDaBrM6c574dY-O6_-bRjLIFmDe2NCxIuyV1w2dw=@protonmail.com> <CAJowKg+tYK9j5LTwokMGutD+-SjBQ70U=X7rqHMGSeaG2NEo9A@mail.gmail.com> <CAD1TkXvjtd-LBt6sC=DrkPwk-owRCMEUCEdB9WAVL4LsnTOOSg@mail.gmail.com> <CAFVRnyoqfzJevK5m68bhBuAvUui+eAQsD9ngwDKuGWxVjRBJwQ@mail.gmail.com> From: Erik Aronesty <erik@q32.com> Date: Sun, 9 Apr 2017 20:20:49 -0400 X-Google-Sender-Auth: m_GJ05akky_aBNYvWm56o5PkltI Message-ID: <CAJowKgKi7hJ8DFbGtgUpJ180=vXqWrLX0PVM9NhxpE2eyn0EZg@mail.gmail.com> To: David Vorick <david.vorick@gmail.com> 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 <bitcoin-dev@lists.linuxfoundation.org> 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 <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: 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" <david.vorick@gmail.com> 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 <div dir=3D"auto">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.<div d= ir=3D"auto"><br></div><div dir=3D"auto">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...</div></div>= <div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Apr 9, 2017 7:= 51 PM, "David Vorick" <<a href=3D"mailto:david.vorick@gmail.co= m">david.vorick@gmail.com</a>> wrote:<br type=3D"attribution"><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"><div dir=3D"auto"><div><br><div class=3D"gmail_extra">= <br><div class=3D"gmail_quote">On Apr 9, 2017 7:00 PM, "Jared Lee Rich= ardson via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxf= oundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org= </a>> wrote:<br type=3D"attribution"><blockquote class=3D"m_-82217816245= 32531501quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddin= g-left:1ex"><div dir=3D"auto">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.</div><div class=3D"m_-8221781624532531501elided-text"><div cl= ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Apr 9, 2017 1:16 PM, = "Erik Aronesty via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev= @lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda= <wbr>tion.org</a>> wrote:<br type=3D"attribution"><blockquote class=3D"g= mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= eft:1ex"><div dir=3D"ltr">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.<br>= <br>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 <br><br>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.<div><br></div>= <div>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 <br><br>Something like that? =C2=A0 <br><br>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.</div><div><br></= div><div>Lots of people seem to panic over POW changes as "irresponsib= le", but it's only irresponsible if done irresponsibly.</div><div>= <br></div></div>______________________________<wbr>_________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br> <br></blockquote></div></div> </div><br>______________________________<wbr>_________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br> <br></blockquote></div><br></div></div><div class=3D"gmail_extra" dir=3D"au= to">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.</div></div> </blockquote></div></div> --94eb2c0654d28b2be0054cc4f26c--