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 C6CCB957 for ; Tue, 11 Apr 2017 05:40:30 +0000 (UTC) X-Greylist: delayed 14:09:32 by SQLgrey-1.7.6 Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE597AD for ; Tue, 11 Apr 2017 05:40:29 +0000 (UTC) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 7E90630002924; Mon, 10 Apr 2017 22:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cognitive.ch; h=date:from :to:cc:message-id:in-reply-to:references:subject:mime-version :content-type; s=cognitive.ch; bh=oDXpz8GUHHXMUt/AMup9gos1oyo=; b= rsduH5pfg6M8MTo07n+U9lblbkV/3wf6Le0MvIMNkcbYVGxY9VwR8ErT60pmpXE3 Q/3EbIBtoUstxGSbvkHNs1XjSqaoj6mafEYEntxVAynq/rnLNUcPUCfiF2mMWezG qqcqxU6kiqJQ7khqIiOygibS5Wteg5LNifY2TjeF5Mk= Received: from [192.168.1.107] (c-73-229-151-138.hsd1.co.comcast.net [73.229.151.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: g@cognitive.ch) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id 31B993000291E; Mon, 10 Apr 2017 22:40:29 -0700 (PDT) Date: Mon, 10 Apr 2017 20:39:32 -0600 From: g To: Erik Aronesty Message-ID: In-Reply-To: References: X-Readdle-Message-ID: a0ee44da-62ad-47dd-97b2-6eb85cbe5cde@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="58ec6c4c_41b71efb_2dd" X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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: Tue, 11 Apr 2017 12:50:19 +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: Tue, 11 Apr 2017 05:40:30 -0000 --58ec6c4c_41b71efb_2dd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Makes sense. I would love if GPUs were back as the main hashing tool. However, we need to consider the environmental impact of mining, which cu= rrently consumes a quite exorbitant amount of energy. Any ideas on this f= ront=3F -- Garrett MacDonald +1 720 515 2248 g=40cognitive.ch GPG Key On Apr 10, 2017, 12:17 PM -0600, Erik Aronesty , wrote: > I own some miners, but realistically their end of life is what, 6 month= s from now if I'm lucky=3F=C2=A0=C2=A0=C2=A0 If we used difficulty ramps = on two selected 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 Personal= ly, I would absolutely love to be back in the business of buying GPU's in= stead of ASICs which are uniformly sketchy.=C2=A0=C2=A0 Does anyone *not*= mine their own equipment before =22shipping late=22 these days=3F > > Maybe sample a video game's GPU operations and try to develop a secure = hash whose optimal implementation uses them in a similar ratio=3F=C2=A0=C2= =A0 Ultimately, I think it would very challenging to find a POW that does= n't make a bad problem worse.=C2=A0 I understand that's why you suggested= SHA3. > > Hopefully, the =22nanometer race=22 we have will work more smoothly onc= e the asicboost issue is resolved and competition can return to normal.=C2= =A0=C2=A0 But =22waiting things out=22 rarely seems to work in Bitcoin la= nd. > > > > > > > > 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 bit= coin to migrate, gradually, toward a commoditized POW away from the curre= nt mass centralization. There is a big problem here though: Hundreds of m= illions 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=3F Or even how we can make the change a= greeable for them=3F > > > > > > Warm regards, > > > Garrett > > > > > > -- > > > Garrett MacDonald > > > +1 720 515 2248 > > > g=40cognitive.ch > > > GPG Key > > > > > > On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev , wrote: > > > > Curious: I'm not sure why a serious discussion of POW change is n= ot 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 s= ome of the proven, np-complete graph-theoretic or polygon manipulation PO= W would keep Bitcoin in commodity hardware and out of the hands of centra= lized manufacturing for many years. > > > > > > > > Clearly a level-playing field is critical to keeping centralizati= on from being a =22defining feature=22 of Bitcoin over the long term. =C2= =A0 I've heard the term =22level playing field=22 bandied about quite a b= it. =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 manufac= turing of =22SHA-256 forever=22 hardware. =C2=A0 Indeed, the reliance on = a fairly simple hash seems less and less likely a =22feature=22 and more = of a baggage. > > > > > > > > Perhaps regular, high-consensus POW changes might even be *necess= ary* as a part of good maintenance of cryptocurrency in general. =C2=A0 K= illing the existing POW, and using an as-yet undefined, but deployment-bi= t ready POW field to flip-flop between the current and the =22next one=22= every 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 selected within 7 years. > > > > > > > > Something like that=3F > > > > > > > > Haven't thought about it *that* much, but I think the network wou= ld respond well to a well known cutover date. =C2=A0 This would enable ra= pid-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 =22irresponsible= =22, but it's only irresponsible if done irresponsibly. > > > > > > > > > > > > > On =46ri, Apr 7, 2017 at 9:48 PM, praxeology=5Fguy via bitcoin-= dev 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 chan= ge Bitcoin policy in order to make their money more vulnerable to 51% att= ack=3F > > > > > > > > > > > > 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 > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > > > > > bitcoin-dev mailing list > > > > > > bitcoin-dev=40lists.linuxfoundation.org > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-de= v > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > > > bitcoin-dev mailing list > > > > bitcoin-dev=40lists.linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --58ec6c4c_41b71efb_2dd Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Makes sense. I w= ould love if GPUs were back as the main hashing tool.

However, we need to consider the environmental impact of mining, whi= ch currently consumes a quite exorbitant amount of energy. Any ideas on t= his front=3F

--
Garrett MacDonald
+1 720 515 2248
g=40cognitive.ch

On Apr 10, 2017, 12:17 PM -0600, Erik Aronesty <erik=40q32.com>, wr= ote:
I own some miners, but realistically their end of life is what, 6 mo= nths from now if I'm lucky=3F&=23160;&=23160;&=23160; If we used difficul= ty ramps on two selected POW's, then the migration could be made smooth.&= =23160;&=23160; I don't think changing the POW would be very challenging.= &=23160; Personally, I would absolutely love to be back in the business o= f buying GPU's instead of ASICs which are uniformly sketchy.&=23160;&=231= 60; Does anyone *not* mine their own equipment before =22shipping late=22= these days=3F&=23160;&=23160;

Maybe sample a video game's GPU operations and try to develop a secure ha= sh whose optimal implementation uses them in a similar ratio=3F&=23160;&=23= 160; Ultimately, I think it would very challenging to find a POW that doe= sn't make a bad problem worse.&=23160; I understand that's why you sugges= ted SHA3.&=23160;&=23160;

Hopefully, the =22nanometer race=22 we have will work more smoothly once = the asicboost issue is resolved and competition can return to normal.&=23= 160;&=23160; But =22waiting things out=22 rarely seems to work in Bitcoin= land.






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

I completely agree that it will be in the long term interest of bitc= oin to migrate, gradually, toward a commoditized POW away from the curren= t mass centralization. There is a big problem here though: Hundreds of mi= llions 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=3F Or even how we can make the change ag= reeable for them=3F

Warm regards,
Garrett

On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev <bitcoin-dev=40lists.linuxfoundation.org>, wrote:
Curious: I'm not sure why a serious discussion of PO= W 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 t= he proven, np-complete graph-theoretic or polygon manipulation POW would = keep Bitcoin in commodity hardware and out of the hands of centralized ma= nufacturing for many years. &=23160;

Clearly a level-playing field is critical to keeping centralization from = being a =22defining feature=22 of Bitcoin over the long term. &=23160; I'= ve heard the term =22level playing field=22 bandied about quite a bit. &=23= 160; And it seems to me that the risk of state actor control and botnet a= ttacks is less than state-actor manipulation of specialized manufacturing= of =22SHA-256 forever=22 hardware. &=23160; Indeed, the reliance on a fa= irly simple hash seems less and less likely a =22feature=22 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. &=23160; Ki= lling the existing POW, and using an as-yet undefined, but deployment-bit= ready POW field to flip-flop between the current and the =22next one=22 = every 8 years or or so, with a ramp down beginning in the 7th year....&=23= 160; A stub function that is guaranteed to fail unless a new consensus PO= W is selected within 7 years. &=23160;

Something like that=3F &=23160;

Haven't thought about it *that* much, but I think the network would respo= nd well to a well known cutover date. &=23160; This would enable rapid-re= sponse to quantum tech, or some other needed POW switch as well... becaus= e the mechanisms would be in-place and ready to switch as needed.

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


On =46ri, Apr 7, 2017 at 9:48 PM, praxeo= logy=5Fguy via bitcoin-dev <bitcoi= n-dev=40lists.linuxfoundation.org> wrote:
Jimmy Song,

Why would the actual end users of Bitcoin (the long term and short t= erm owners of bitcoins) who run fully verifying nodes want to change Bitc= oin policy in order to make their money more vulnerable to 51% attack=3F<= br />

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

Thanks,
Praxeology Guy

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
bitcoin-dev mailing list
bitcoin-dev=40lists.linuxfoundation.org
https://lists.linuxf= oundation.org/mailman/listinfo/bitcoin-dev


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
bitcoin-dev mailing list
bitcoin-dev=40lists.linuxfoundation.org
https://lists.linuxfoundation.org/ma= ilman/listinfo/bitcoin-dev

--58ec6c4c_41b71efb_2dd--