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 CDCE2B6C for ; Tue, 11 Apr 2017 03:35:35 +0000 (UTC) X-Greylist: delayed 12:04:36 by SQLgrey-1.7.6 Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 13CC819C for ; Tue, 11 Apr 2017 03:35:34 +0000 (UTC) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by hapkido.dreamhost.com (Postfix) with ESMTP id 6047280368 for ; Mon, 10 Apr 2017 08:30:57 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id BBF12600050C; Mon, 10 Apr 2017 08:30:56 -0700 (PDT) Received: from [10.247.112.80] (unknown [205.209.60.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: g@cognitive.ch) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 6413E6000504; Mon, 10 Apr 2017 08:30:56 -0700 (PDT) Date: Mon, 10 Apr 2017 09:25:05 -0600 From: g To: =?utf-8?Q?praxeology=5Fguy?= , Bitcoin Protocol Discussion , Erik Aronesty Message-ID: In-Reply-To: References: X-Readdle-Message-ID: f71d2435-7f5a-42a6-8244-ff13bf9a0599@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="58eba52c_74b0dc51_2dd" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,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 03:51:09 +0000 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 03:35:36 -0000 --58eba52c_74b0dc51_2dd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Erik, I completely agree that it will be in the long term interest of bitcoin t= o migrate, gradually, toward a commoditized POW away from the current mas= s centralization. There is a big problem here though: Hundreds of million= s 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 c= hain currently would likely never allow this change to happen. Do you have any ideas regarding how to mitigate the damage of such a chan= ge for the invested parties=3F Or even how we can make the change agreeab= le 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 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 woul= d 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 fro= m 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 bit. =C2= =A0 And it seems to me that the risk of state actor control and botnet at= tacks is less than state-actor manipulation of specialized manufacturing = of =22SHA-256 forever=22 hardware. =C2=A0 Indeed, the reliance on a fairl= y simple hash seems less and less likely a =22feature=22 and more of a ba= ggage. > > Perhaps regular, high-consensus POW changes might even be *necessary* a= s a part of good maintenance of cryptocurrency in general. =C2=A0 Killing= the existing POW, and using an as-yet undefined, but deployment-bit read= y 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 s= elected within 7 years. > > Something like that=3F > > 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-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, b= ut 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 change Bit= coin policy in order to make their money more vulnerable to 51% attack=3F= > > > > > > If anything, we would be making policy changes to prevent the use o= f 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-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/mailman/listinfo/bitcoin-dev --58eba52c_74b0dc51_2dd Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
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

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

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-de= v=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/mailman/listinfo/bitcoin-dev
--58eba52c_74b0dc51_2dd--