path: root/ca/7acd40a6e321d480171eff047642e7c37dd579

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 C6CCB957
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <g@cognitive.ch>
To: Erik Aronesty <erik@q32.com>
Message-ID: <a0ee44da-62ad-47dd-97b2-6eb85cbe5cde@Spark>
In-Reply-To: <CAJowKgKmYuBJskZwzC_kjDJHCW8s1+9kCXOO4NbYdt2rPJ4=Ow@mail.gmail.com>
References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
	<Cwhn7YzwaDUZtOygDAgrU1UXjRPG-EiH3Fyz2c95gqOpNnNbiYL1NvhS28yK5wLJCnIqDaBrM6c574dY-O6_-bRjLIFmDe2NCxIuyV1w2dw=@protonmail.com>
	<CAJowKg+tYK9j5LTwokMGutD+-SjBQ70U=X7rqHMGSeaG2NEo9A@mail.gmail.com>
	<f71d2435-7f5a-42a6-8244-ff13bf9a0599@Spark>
	<CAJowKgKmYuBJskZwzC_kjDJHCW8s1+9kCXOO4NbYdt2rPJ4=Ow@mail.gmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 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 <erik=40q32.com>, 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 <g=40cognitive.ch> 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 <bitco=
in-dev=40lists.linuxfoundation.org>, 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 <bitcoin-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 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

<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>Makes sense. I w=
ould love if GPUs were back as the main hashing tool.
<div><br /></div>
<div>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</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 10, 2017, 12:17 PM -0600, Erik Aronesty &lt;erik=40q32.com&gt;, wr=
ote:<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>
<div>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;<br />
<br /></div>
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;<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br /></div>
<div class=3D=22gmail=5Fextra=22><br />
<div class=3D=22gmail=5Fquote=22>On Mon, Apr 10, 2017 at 11:25 AM, g <spa=
n dir=3D=22ltr=22>&lt;<a href=3D=22mailto:g=40cognitive.ch=22 target=3D=22=
=5Fblank=22>g=40cognitive.ch</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>
<div name=3D=22messageBodySection=22 style=3D=22font-size:14px;font-famil=
y:-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;font-=
family:-apple-system,BlinkMacSystem=46ont,sans-serif=22><br />
--
<div>Garrett MacDonald</div>
<div><a href=3D=22tel:(720)%20515-2248=22 value=3D=22+17205152248=22 targ=
et=3D=22=5Fblank=22>+1 720 515 2248</a><br /></div>
<div><a href=3D=22mailto:g=40cognitive.ch=22 target=3D=22=5Fblank=22>g=40=
cognitive.ch</a></div>
<div><a href=3D=22https://pgp.mit.edu/pks/lookup=3Fop=3Dget&amp;search=3D=
0x0A06E7=469E51DE2D6=22 target=3D=22=5Fblank=22>GPG Key</a><br /></div>
</div>
<div>
<div class=3D=22h5=22>
<div name=3D=22messageReplySection=22 style=3D=22font-size:14px;font-fami=
ly:-apple-system,BlinkMacSystem=46ont,sans-serif=22><br />
On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev &lt;<a href=3D=
=22mailto:bitcoin-dev=40lists.linuxfoundation.org=22 target=3D=22=5Fblank=
=22>bitcoin-dev=40lists.<wbr />linuxfoundation.org</a>&gt;, wrote:<br />
<blockquote type=3D=22cite=22 style=3D=22margin: 5px 5px; padding-left: 1=
0px; border-left: thin solid =233498db;=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.<wbr />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 =23d35400;=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 target=3D=22=
=5Fblank=22>bitcoin-dev=40lists.linuxfoundat<wbr />ion.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-d<wbr />ev</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<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 target=3D=22=
=5Fblank=22>bitcoin-dev=40lists.<wbr />linuxfoundation.org</a><br />
<a href=3D=22https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev=22 target=3D=22=5Fblank=22>https://lists.linuxfoundation.<wbr />org/ma=
ilman/listinfo/bitcoin-<wbr />dev</a><br /></blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br /></div>
</blockquote>
</div>
</body>
</html>

--58ec6c4c_41b71efb_2dd--