Return-Path: <jaredr26@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 14C133EE for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 9 Apr 2017 21:16:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f171.google.com (mail-ua0-f171.google.com [209.85.217.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 73E70108 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 9 Apr 2017 21:16:28 +0000 (UTC) Received: by mail-ua0-f171.google.com with SMTP id 49so19491136uau.2 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 09 Apr 2017 14:16:28 -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=7Qr8RqObw4gEWu3KVzMrlNJqDCBJJ4EEATpT3BIOCas=; b=ky/rnt2jyCW5ogZnNSU+aa9uZKESQD8sjQRuoIMQOz5qX47YmpzfUqH8A9YvgcnsIk mwE6FJN9bplxmqEbZEUbydHoPnYZAHsjhfTawldxT/myJhDgufn+UJdSsgTw186tucgD T3kzxOOkON7fKe1g4QPQA3XyJQzkI4wjIGCoD/8l+tfi+Ku8StSsX476vWBeToZFaJc0 xy1uPtbVt+ubC0pnUZAGfX51qRehII1UFrCeFElemH1wP/HBXEqbosbj5zRuxCthQ27/ FzwtayI0iPjC8NKdIQs3OyLcnYRpBTNb6WetjLwxh7B5I4MWtJRpp6hRLGF+dZa3mqDs E8fw== 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=7Qr8RqObw4gEWu3KVzMrlNJqDCBJJ4EEATpT3BIOCas=; b=gTw4sicCjjsOvi0n4zq6ZeW0PYVTCbDzfWeuuXxcOvHe140e5tVq5eXplt1dphGvUF 8yRHh/mIksvC79hRmrVaom3o6m4woeyKS2/SFwFMionTysmRzWDaOYuuy2OnBJaS5UW5 VrKwo0BJYYsSoQ6NtoblQpLbbPdjUCwLRTq9jjoVNicB1rMppptnQYgLNRyatKWd7E1F 2EKHrg+DGYzKAJXb9gh1a2QUiJnoXrzL9L0JookNZCkTp0l/VQusbEU4tSuHj4vzcCok S40Ijx3mCHamSB5/l1hujIEjT/K7E86wfUENI3Ccf5s5YapfvOaxuBacoxibL5QZ6Nzf dKlw== X-Gm-Message-State: AFeK/H0Jo8XPJFauQ8sdZOYDxr492GFKcsP9CzH0IU/TvZrgWw7Rv/ZQzLPtZTKk02mG1DTvHneQK3tfMxabiw== X-Received: by 10.31.218.195 with SMTP id r186mr19429596vkg.112.1491772587570; Sun, 09 Apr 2017 14:16:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.157.143 with HTTP; Sun, 9 Apr 2017 14:16:26 -0700 (PDT) Received: by 10.31.157.143 with HTTP; Sun, 9 Apr 2017 14:16:26 -0700 (PDT) In-Reply-To: <CAJowKg+tYK9j5LTwokMGutD+-SjBQ70U=X7rqHMGSeaG2NEo9A@mail.gmail.com> References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com> <Cwhn7YzwaDUZtOygDAgrU1UXjRPG-EiH3Fyz2c95gqOpNnNbiYL1NvhS28yK5wLJCnIqDaBrM6c574dY-O6_-bRjLIFmDe2NCxIuyV1w2dw=@protonmail.com> <CAJowKg+tYK9j5LTwokMGutD+-SjBQ70U=X7rqHMGSeaG2NEo9A@mail.gmail.com> From: Jared Lee Richardson <jaredr26@gmail.com> Date: Sun, 9 Apr 2017 14:16:26 -0700 Message-ID: <CAD1TkXvjtd-LBt6sC=DrkPwk-owRCMEUCEdB9WAVL4LsnTOOSg@mail.gmail.com> To: Erik Aronesty <erik@q32.com> Content-Type: multipart/alternative; boundary=94eb2c07adbc2afa02054cc25f37 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE 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: Sun, 09 Apr 2017 22:59:58 +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: Sun, 09 Apr 2017 21:16:29 -0000 --94eb2c07adbc2afa02054cc25f37 Content-Type: text/plain; charset=UTF-8 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. > > > On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Jimmy Song, >> >> Why would the actual end users of Bitcoin (the long term and short term >> owners of bitcoins) who run fully verifying nodes want to change Bitcoin >> policy in order to make their money more vulnerable to 51% attack? >> >> If anything, we would be making policy changes to prevent the use of >> patented PoW algorithms instead of making changes to enable them. >> >> Thanks, >> Praxeology Guy >> >> _______________________________________________ >> 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 > > --94eb2c07adbc2afa02054cc25f37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">I can speak from personal experience regarding another ve= ry prominent altcoin that attempted to utilize an asic-resistant proof of w= ork algorithm, it is only a matter of time before the "asic resistant&= quot; algorithm gets its own Asics.=C2=A0 The more complicated the algorith= m, the more secretive the asic technology is developed.=C2=A0 Even without = it, multi-megawatt gpu farms have already formed in the areas of the world = with low energy costs.=C2=A0 I'd support the goal if I thought it possi= ble, but I really don't think centralization of mining can be prevented= .</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Apr 9, = 2017 1:16 PM, "Erik Aronesty via bitcoin-dev" <<a href=3D"mail= to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation= .org</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">= <div dir=3D"ltr">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.<br><br>Done = right, a ramp down of reliance on SHA-256 and a ramp-up on some of the prov= en, np-complete graph-theoretic or polygon manipulation POW would keep Bitc= oin in commodity hardware and out of the hands of centralized manufacturing= for many years. =C2=A0 <br><br>Clearly a level-playing field is critical t= o keeping centralization from being a "defining feature" of Bitco= in over the long term. =C2=A0 I've heard the term "level playing f= ield" bandied about quite a bit. =C2=A0 And it seems to me that the ri= sk of state actor control and botnet attacks is less than state-actor manip= ulation of specialized manufacturing of "SHA-256 forever" hardwar= e. =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>Perh= aps regular, high-consensus POW changes might even be *necessary* as a part= of good maintenance of cryptocurrency in general. =C2=A0 Killing the exist= ing 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 func= tion that is guaranteed to fail unless a new consensus POW is selected with= in 7 years. =C2=A0 <br><br>Something like that? =C2=A0 <br><br>Haven't = thought 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 quan= tum tech, or some other needed POW switch as well... because the mechanisms= 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 "irresponsible",= but it's only irresponsible if done irresponsibly.</div><div><br></div= ></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Ap= r 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev <span dir=3D"ltr"><= <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></span> wrote:<br><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"><div>Jimmy Song,<br></div><div><br></div><div>Why w= ould the actual end users of Bitcoin (the long term and short term owners o= f bitcoins) who run fully verifying nodes want to change Bitcoin policy in = order to make their money more vulnerable to 51% attack?<br></div><div><br>= </div><div>If anything, we would be making policy changes to prevent the us= e of patented PoW algorithms instead of making changes to enable them.<br><= /div><div><br></div><div>Thanks,<br></div><div>Praxeology Guy<br></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> <br>______________________________<wbr>_________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= <wbr>linuxfoundation.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-<wbr>dev</a><br> <br></blockquote></div></div> --94eb2c07adbc2afa02054cc25f37--