Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7B33FB30 for ; Mon, 10 Apr 2017 18:17:06 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f174.google.com (mail-qt0-f174.google.com [209.85.216.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6AF0B22B for ; Mon, 10 Apr 2017 18:17:05 +0000 (UTC) Received: by mail-qt0-f174.google.com with SMTP id n46so38399873qta.2 for ; Mon, 10 Apr 2017 11:17:05 -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=i8v5k0M8tFiKMWY3HBc1dO2lBow083OC0etA1+fPNQ8=; b=IaIOATJ8Jj/xVTBxViFzSuobrbdeThALLVruiaJTmqNe4gkhfM/dSai7oGL7FHqp9J 2S4m1gZBcvVyZL61vf1SQ51Lnq3o1Ju+NVlJciGOhfAGen2+LoDEDxBNG6ik+h4arqL8 Y1kh0xvCLDICqZ8oL3XR4deQMly6UYxOJvZMmcaP3CPh1yQW3nLRbcEjK6YMpNRqdT+r NF6BOgHNPitUezqYo66AfHOVQdVAFDfiRITSFux+96Loh4OhgxR4yrutNB80zx3Czxmc 9l7afrGnwrZwoNqOmN153N6cVrKPFwiUgF2JGT46DR8e/J/EmTUzHhC4Si97KCwie7+c Rjlg== 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=i8v5k0M8tFiKMWY3HBc1dO2lBow083OC0etA1+fPNQ8=; b=Od3XIU4+y7smyUBwkWFMgZRfChGMgdHJl4Pc6+Wp52qk5ejPN0Ey3wVVTn99/93dXz zdnb2Chvf87XlrzL4Z+TNs4LYTPxlE5EhlBH6M5uYgM5PK8+E/bXqxB1ef5+5GujhiVC 9iKSvARyufc61AgzSh+ld49UA5UwQNQMKYGzWanx0hKOCKkXzhGdOnYjH3wyc2dml7Q6 GphXsOF1FEuoaUCL+3IiOw3jLkrOq2d+yaYv3Gxmrx7A3qKLq65ORNXN4YDN4sc4D6so 8ElmrngHc3ITykTtFEE7avoikcbFbsowZTgBxjES/B+ySmGEk6cS84hcsmn/y2SLkphh 4ICA== X-Gm-Message-State: AFeK/H26lD1o1BOR9zgZYKTFxtGsx+cqo3V/Yv7BaZySrMP2ibrpxuEjRnPV+eEvNNdmxi0p7zyvaRYyLdZjCw== X-Received: by 10.237.59.8 with SMTP id p8mr54945213qte.270.1491848224551; Mon, 10 Apr 2017 11:17:04 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.200.0.146 with HTTP; Mon, 10 Apr 2017 11:17:03 -0700 (PDT) In-Reply-To: References: From: Erik Aronesty Date: Mon, 10 Apr 2017 14:17:03 -0400 X-Google-Sender-Auth: ---cJ2cOMoJZFeFdETtv-iZy5Lk Message-ID: To: g Content-Type: multipart/alternative; boundary=94eb2c0e5d927bbac7054cd3fb8c 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 18:22:44 +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 18:17:06 -0000 --94eb2c0e5d927bbac7054cd3fb8c Content-Type: text/plain; charset=UTF-8 I own some miners, but realistically their end of life is what, 6 months from now if I'm lucky? If we used difficulty ramps on two selected POW's, then the migration could be made smooth. I don't think changing the POW would be very challenging. Personally, I would absolutely love to be back in the business of buying GPU's instead of ASICs which are uniformly sketchy. Does anyone *not* mine their own equipment before "shipping late" these days? Maybe sample a video game's GPU operations and try to develop a secure hash whose optimal implementation uses them in a similar ratio? Ultimately, I think it would very challenging to find a POW that doesn't make a bad problem worse. I understand that's why you suggested SHA3. Hopefully, the "nanometer race" we have will work more smoothly once the asicboost issue is resolved and competition can return to normal. But "waiting things out" rarely seems to work in Bitcoin land. On Mon, Apr 10, 2017 at 11:25 AM, g wrote: > Erik, > > I completely agree that it will be in the long term interest of bitcoin to > migrate, gradually, toward a commoditized POW away from the current mass > centralization. There is a big problem here though: Hundreds of millions of > dollars have been spent on the current algorithm, and will be a huge loss > if this is not done slowly enough, and the miners who control the chain > currently would likely never allow this change to happen. > > Do you have any ideas regarding how to mitigate the damage of such a > change for the invested parties? Or even how we can make the change > agreeable for them? > > Warm regards, > Garrett > > -- > Garrett MacDonald > +1 720 515 2248 <(720)%20515-2248> > g@cognitive.ch > GPG Key > > On Apr 9, 2017, 2:16 PM -0600, 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 > > --94eb2c0e5d927bbac7054cd3fb8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I own some miners, but realistically their end of lif= e is what, 6 months from now if I'm lucky?=C2=A0=C2=A0=C2=A0 If we used difficulty ramps o= n two selected=20 POW's, then the migration could be made smooth.=C2=A0=C2=A0 I don't= think changing the POW would be very challenging.=C2=A0 Personally, I woul= d absolutely love to be back in the business of buying GPU's instead of= ASICs which are uniformly sketchy.=C2=A0=C2=A0 Does anyone *not* mine thei= r own equipment before "shipping late" these days?=C2=A0=C2=A0
Maybe sample a video game's GPU operations and t= ry to develop a secure hash whose optimal implementation uses them in a sim= ilar ratio?=C2=A0=C2=A0 Ultimately, I think it would very challenging to fi= nd a POW that doesn't make a bad problem worse.=C2=A0 I understand that= 's why you suggested SHA3.=C2=A0=C2=A0

Hopefully, the "nan= ometer race" we have will work more smoothly once the asicboost issue = is resolved and competition can return to normal.=C2=A0=C2=A0 But "wai= ting things out" rarely seems to work in Bitcoin land.



=


On Mon, Apr 10, 2017 at 11:25 AM, g <g@cognitive.ch> = wrote:
Erik,

I completely agree that it will be in the long term interest of bitcoi= n to migrate, gradually, toward a commoditized POW away from the current ma= ss centralization. There is a big problem here though: Hundreds of millions= of dollars have been spent on the current algorithm, and will be a huge lo= ss if this is not done slowly enough, and the miners who control the chain = currently would likely never allow this change to happen.

Do you have any ideas regarding how to mitigate the damage of such a c= hange for the invested parties? Or even how we can make the change agreeabl= e for them?

Warm regards,
Garrett

--
Garrett MacDonald

On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev <bitcoin-de= v@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 manufact= uring for many years. =C2=A0

Clearly a level-playing field is critical to keeping centralization from be= ing a "defining feature" of Bitcoin over the long term. =C2=A0 I&= #39;ve heard the term "level playing field" bandied about quite a= bit. =C2=A0 And it seems to me that the risk of state actor control and bo= tnet attacks is less than state-actor manipulation of specialized manufactu= ring of "SHA-256 forever" hardware. =C2=A0 Indeed, the reliance o= n 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

Haven't thought about it *that* much, but I think the network would res= pond well to a well known cutover date. =C2=A0 This would enable rapid-resp= onse to quantum tech, or some other needed POW switch as well... because th= e mechanisms would be in-place and ready to switch as needed.

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


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

Why would the actual end users of Bitcoin (the long term and short ter= m 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 p= atented 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/b= itcoin-dev

--94eb2c0e5d927bbac7054cd3fb8c--