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>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="58eba52c_74b0dc51_2dd"
Subject: Re: [bitcoin-dev] A Small Modification to Segwit
Precedence: list

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