Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 14C133EE for ; 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 ; Sun, 9 Apr 2017 21:16:28 +0000 (UTC) Received: by mail-ua0-f171.google.com with SMTP id 49so19491136uau.2 for ; 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: References: From: Jared Lee Richardson Date: Sun, 9 Apr 2017 14:16:26 -0700 Message-ID: To: Erik Aronesty 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 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 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
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= .

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 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

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.

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

Something like that? =C2=A0

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.

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


On Fri, Ap= r 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev <= = bitcoin-dev@lists.linuxfoundation.org> wrote:
Jimmy Song,

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?

=
If anything, we would be making policy changes to prevent the us= e of patented PoW algorithms instead of making changes to enable them.
<= /div>

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--