path: root/ee/7fc0dee3332819ee8611f09bdabcffa7a460a3

Return-Path: <g@cognitive.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CDCE2B6C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <g@cognitive.ch>
To: =?utf-8?Q?praxeology=5Fguy?= <praxeology_guy@protonmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
	Erik Aronesty <erik@q32.com>
Message-ID: <f71d2435-7f5a-42a6-8244-ff13bf9a0599@Spark>
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>
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 <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: 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 <bitcoin-dev=
=40lists.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 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 <b=
itcoin-dev=40lists.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 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

<html xmlns=3D=22http://www.w3.org/1999/xhtml=22>
<head>
<title></title>
</head>
<body>
<div name=3D=22messageBodySection=22 style=3D=22font-size: 14px; font-fam=
ily: -apple-system, BlinkMacSystem=46ont, sans-serif;=22>Erik,
<div><br /></div>
<div>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.</div>=

<div><br /></div>
<div>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</div>
<div><br /></div>
<div>Warm regards,</div>
<div>Garrett</div>
</div>
<div name=3D=22messageSignatureSection=22 style=3D=22font-size: 14px; fon=
t-family: -apple-system, BlinkMacSystem=46ont, sans-serif;=22><br />
--
<div>Garrett MacDonald</div>
<div>+1 720 515 2248<br /></div>
<div>g=40cognitive.ch</div>
<div><a href=3D=22https://pgp.mit.edu/pks/lookup=3Fop=3Dget&amp;search=3D=
0x0A06E7=469E51DE2D6=22>GPG Key</a><br /></div>
</div>
<div name=3D=22messageReplySection=22 style=3D=22font-size: 14px; font-fa=
mily: -apple-system, BlinkMacSystem=46ont, sans-serif;=22><br />
On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev &lt;bitcoin-=
dev=40lists.linuxfoundation.org&gt;, wrote:<br />
<blockquote type=3D=22cite=22 style=3D=22margin: 5px 5px; padding-left: 1=
0px; border-left: thin solid =231abc9c;=22>
<div dir=3D=22ltr=22>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.<br />
<br />
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;<br />
<br />
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.
<div><br /></div>
<div>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;<br />
<br />
Something like that=3F &=23160;<br />
<br />
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.</div>
<div><br /></div>
<div>Lots of people seem to panic over POW changes as =22irresponsible=22=
, but it's only irresponsible if done irresponsibly.</div>
<div><br /></div>
</div>
<div class=3D=22gmail=5Fextra=22><br />
<div class=3D=22gmail=5Fquote=22>On =46ri, Apr 7, 2017 at 9:48 PM, praxeo=
logy=5Fguy via bitcoin-dev <span dir=3D=22ltr=22>&lt;<a href=3D=22mailto:=
bitcoin-dev=40lists.linuxfoundation.org=22 target=3D=22=5Fblank=22>bitcoi=
n-dev=40lists.linuxfoundation.org</a>&gt;</span> wrote:<br />
<blockquote class=3D=22gmail=5Fquote=22 style=3D=22margin: 5px 5px; paddi=
ng-left: 10px; border-left: thin solid =23e67e22;=22>
<div>Jimmy Song,<br /></div>
<div><br /></div>
<div>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 /></div>
<div><br /></div>
<div>If anything, we would be making policy changes to prevent the use 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 />
=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<wbr />=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
<br />
bitcoin-dev mailing list<br />
<a href=3D=22mailto:bitcoin-dev=40lists.linuxfoundation.org=22>bitcoin-de=
v=40lists.<wbr />linuxfoundation.org</a><br />
<a href=3D=22https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev=22 rel=3D=22noreferrer=22 target=3D=22=5Fblank=22>https://lists.linuxf=
oundation.<wbr />org/mailman/listinfo/bitcoin-<wbr />dev</a><br />
<br /></blockquote>
</div>
<br /></div>
=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<br />
bitcoin-dev mailing list<br />
bitcoin-dev=40lists.linuxfoundation.org<br />
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<br /></blo=
ckquote>
</div>
</body>
</html>

--58eba52c_74b0dc51_2dd--