Return-Path: <jaredr26@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 14C133EE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  9 Apr 2017 21:16:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f171.google.com (mail-ua0-f171.google.com
	[209.85.217.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 73E70108
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  9 Apr 2017 21:16:28 +0000 (UTC)
Received: by mail-ua0-f171.google.com with SMTP id 49so19491136uau.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 09 Apr 2017 14:16:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=7Qr8RqObw4gEWu3KVzMrlNJqDCBJJ4EEATpT3BIOCas=;
	b=ky/rnt2jyCW5ogZnNSU+aa9uZKESQD8sjQRuoIMQOz5qX47YmpzfUqH8A9YvgcnsIk
	mwE6FJN9bplxmqEbZEUbydHoPnYZAHsjhfTawldxT/myJhDgufn+UJdSsgTw186tucgD
	T3kzxOOkON7fKe1g4QPQA3XyJQzkI4wjIGCoD/8l+tfi+Ku8StSsX476vWBeToZFaJc0
	xy1uPtbVt+ubC0pnUZAGfX51qRehII1UFrCeFElemH1wP/HBXEqbosbj5zRuxCthQ27/
	FzwtayI0iPjC8NKdIQs3OyLcnYRpBTNb6WetjLwxh7B5I4MWtJRpp6hRLGF+dZa3mqDs
	E8fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=7Qr8RqObw4gEWu3KVzMrlNJqDCBJJ4EEATpT3BIOCas=;
	b=gTw4sicCjjsOvi0n4zq6ZeW0PYVTCbDzfWeuuXxcOvHe140e5tVq5eXplt1dphGvUF
	8yRHh/mIksvC79hRmrVaom3o6m4woeyKS2/SFwFMionTysmRzWDaOYuuy2OnBJaS5UW5
	VrKwo0BJYYsSoQ6NtoblQpLbbPdjUCwLRTq9jjoVNicB1rMppptnQYgLNRyatKWd7E1F
	2EKHrg+DGYzKAJXb9gh1a2QUiJnoXrzL9L0JookNZCkTp0l/VQusbEU4tSuHj4vzcCok
	S40Ijx3mCHamSB5/l1hujIEjT/K7E86wfUENI3Ccf5s5YapfvOaxuBacoxibL5QZ6Nzf
	dKlw==
X-Gm-Message-State: AFeK/H0Jo8XPJFauQ8sdZOYDxr492GFKcsP9CzH0IU/TvZrgWw7Rv/ZQzLPtZTKk02mG1DTvHneQK3tfMxabiw==
X-Received: by 10.31.218.195 with SMTP id r186mr19429596vkg.112.1491772587570; 
	Sun, 09 Apr 2017 14:16:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.143 with HTTP; Sun, 9 Apr 2017 14:16:26 -0700 (PDT)
Received: by 10.31.157.143 with HTTP; Sun, 9 Apr 2017 14:16:26 -0700 (PDT)
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>
From: Jared Lee Richardson <jaredr26@gmail.com>
Date: Sun, 9 Apr 2017 14:16:26 -0700
Message-ID: <CAD1TkXvjtd-LBt6sC=DrkPwk-owRCMEUCEdB9WAVL4LsnTOOSg@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
Content-Type: multipart/alternative; boundary=94eb2c07adbc2afa02054cc25f37
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE 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: Sun, 09 Apr 2017 22:59:58 +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: Sun, 09 Apr 2017 21:16:29 -0000

--94eb2c07adbc2afa02054cc25f37
Content-Type: text/plain; charset=UTF-8

I can speak from personal experience regarding another very prominent
altcoin that attempted to utilize an asic-resistant proof of work
algorithm, it is only a matter of time before the "asic resistant"
algorithm gets its own Asics.  The more complicated the algorithm, the more
secretive the asic technology is developed.  Even without it,
multi-megawatt gpu farms have already formed in the areas of the world with
low energy costs.  I'd support the goal if I thought it possible, but I
really don't think centralization of mining can be prevented.

On Apr 9, 2017 1:16 PM, "Erik Aronesty via bitcoin-dev" <
bitcoin-dev@lists.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 would
> 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 from
> being a "defining feature" of Bitcoin over the long term.   I've heard the
> term "level playing field" bandied about quite a bit.   And it seems to me
> that the risk of state actor control and botnet attacks is less than
> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
> hardware.   Indeed, the reliance on a fairly simple hash seems less and
> less likely a "feature" 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.   Killing the
> existing POW, and using an as-yet undefined, but deployment-bit ready POW
> field to flip-flop between the current and the "next one" every 8 years or
> or so, with a ramp down beginning in the 7th year....  A stub function that
> is guaranteed to fail unless a new consensus POW is selected within 7
> years.
>
> Something like that?
>
> Haven't thought about it *that* much, but I think the network would
> respond well to a well known cutover date.   This would enable
> rapid-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 "irresponsible", but it's
> only irresponsible if done irresponsibly.
>
>
> On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev <
> bitcoin-dev@lists.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 Bitcoin
>> policy in order to make their money more vulnerable to 51% attack?
>>
>> 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
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--94eb2c07adbc2afa02054cc25f37
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I can speak from personal experience regarding another ve=
ry prominent altcoin that attempted to utilize an asic-resistant proof of w=
ork algorithm, it is only a matter of time before the &quot;asic resistant&=
quot; algorithm gets its own Asics.=C2=A0 The more complicated the algorith=
m, the more secretive the asic technology is developed.=C2=A0 Even without =
it, multi-megawatt gpu farms have already formed in the areas of the world =
with low energy costs.=C2=A0 I&#39;d support the goal if I thought it possi=
ble, but I really don&#39;t think centralization of mining can be prevented=
.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Apr 9, =
2017 1:16 PM, &quot;Erik Aronesty via bitcoin-dev&quot; &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">Curious: I&#39;m not sure why a serious discussion of POW =
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 the prov=
en, np-complete graph-theoretic or polygon manipulation POW would keep Bitc=
oin in commodity hardware and out of the hands of centralized manufacturing=
 for many years. =C2=A0 <br><br>Clearly a level-playing field is critical t=
o keeping centralization from being a &quot;defining feature&quot; of Bitco=
in over the long term. =C2=A0 I&#39;ve heard the term &quot;level playing f=
ield&quot; bandied about quite a bit. =C2=A0 And it seems to me that the ri=
sk of state actor control and botnet attacks is less than state-actor manip=
ulation of specialized manufacturing of &quot;SHA-256 forever&quot; hardwar=
e. =C2=A0 Indeed, the reliance on a fairly simple hash seems less and less =
likely a &quot;feature&quot; and more of a baggage.<div><br></div><div>Perh=
aps regular, high-consensus POW changes might even be *necessary* as a part=
 of good maintenance of cryptocurrency in general. =C2=A0 Killing the exist=
ing POW, and using an as-yet undefined, but deployment-bit ready POW field =
to flip-flop between the current and the &quot;next one&quot; every 8 years=
 or or so, with a ramp down beginning in the 7th year....=C2=A0 A stub func=
tion that is guaranteed to fail unless a new consensus POW is selected with=
in 7 years. =C2=A0 <br><br>Something like that? =C2=A0 <br><br>Haven&#39;t =
thought about it *that* much, but I think the network would respond well to=
 a well known cutover date. =C2=A0 This would enable rapid-response to quan=
tum tech, or some other needed POW switch as well... because 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 &quot;irresponsible&quot;,=
 but it&#39;s only irresponsible if done irresponsibly.</div><div><br></div=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Ap=
r 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div>Jimmy Song,<br></div><div><br></div><div>Why w=
ould the actual end users of Bitcoin (the long term and short term owners o=
f bitcoins) who run fully verifying nodes want to change Bitcoin policy in =
order to make their money more vulnerable to 51% attack?<br></div><div><br>=
</div><div>If anything, we would be making policy changes to prevent the us=
e 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>=
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div></div>

--94eb2c07adbc2afa02054cc25f37--