1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A44E360
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Apr 2017 18:44:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com
[209.85.216.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E716D213
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Apr 2017 18:44:48 +0000 (UTC)
Received: by mail-qt0-f171.google.com with SMTP id i34so90976829qtc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 09 Apr 2017 11:44:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=CKFhWmyp2foZuwQp8hu+gD5gIN30EKHcFYYQKAz6hBw=;
b=Gx//EwQXvCOVlpTjJAGFuJO3hfkHECx1/iF+kPAHOIAenCA2E3e9QxmisNZZjMW8jF
3ayoY2tZ8kcBVrDWIMlCTXT3sPV0EELE5zZjvZIMFLSIG0m/lFX9JcgQcdLuNKKOO/k+
SMl2CKcrv+cLRRqpjUFE9kI+8dgu0EwEvd5Zuk3ucVUH83jdSv7kn0Atjscq1mfyeVrm
9bNi9mGuuLPlfZ7KeW0O88I5yG/ZStMuGrrEDTaLTG/2iYEr6CH6SNJ76hRKDT/q2ybV
iceqrZLNMf6MrlMzU4cUTFymh33+mG+Dkr4DBBJ5Vlq58npA3zKMnMq7XO1TEcnqiJOP
I4GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=CKFhWmyp2foZuwQp8hu+gD5gIN30EKHcFYYQKAz6hBw=;
b=fId5QOjy66Y3Y43xTPSE3Ef/C4dD7uW+K6vpRwraZIf+GpdKKSqT78A0eZey48Tt0e
iUSgeV1Q3jYDcJoWs3rFiKhsM4WRJDmKWYe4hoSRSgv3Vgmi1jK0kjyE4IUtbJpVsGsu
ZuMXs2/PsUqijhVTcB6vOdiRCY5Tgodune0QFRvr+GacI/fPiVVuPtbi392kevq06jXd
G+IHK1sQAV8b7DP13oYaqlIl0PAQLn21U9NcTCKu6sRxCKD0KrxgVEpmbRarlMhtAt6n
hILDQUycekJe/SqQh0AIxbQllsL7D0SauvoeD+eIcBWPmNrSGQYtY0qhfpH7fzi4lDe0
w9Zg==
X-Gm-Message-State: AFeK/H2mOAe/yz1de7xrRkNzDtEOk0DR/Mhrayy9u2938iSTijLKeLm1zD6ycBV/0JJUnNwWbv6yKPQPYzOPNQ==
X-Received: by 10.237.34.212 with SMTP id q20mr49803245qtc.5.1491763487991;
Sun, 09 Apr 2017 11:44:47 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.200.0.146 with HTTP; Sun, 9 Apr 2017 11:44:47 -0700 (PDT)
In-Reply-To: <Cwhn7YzwaDUZtOygDAgrU1UXjRPG-EiH3Fyz2c95gqOpNnNbiYL1NvhS28yK5wLJCnIqDaBrM6c574dY-O6_-bRjLIFmDe2NCxIuyV1w2dw=@protonmail.com>
References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
<Cwhn7YzwaDUZtOygDAgrU1UXjRPG-EiH3Fyz2c95gqOpNnNbiYL1NvhS28yK5wLJCnIqDaBrM6c574dY-O6_-bRjLIFmDe2NCxIuyV1w2dw=@protonmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Sun, 9 Apr 2017 14:44:47 -0400
X-Google-Sender-Auth: 7voKW4hx2Dj216hTG_B3eEg3L1M
Message-ID: <CAJowKg+tYK9j5LTwokMGutD+-SjBQ70U=X7rqHMGSeaG2NEo9A@mail.gmail.com>
To: praxeology_guy <praxeology_guy@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11375e08ca706b054cc040b4
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, 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: Sun, 09 Apr 2017 20:15:36 +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: Sun, 09 Apr 2017 18:44:49 -0000
--001a11375e08ca706b054cc040b4
Content-Type: text/plain; charset=UTF-8
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
>
>
--001a11375e08ca706b054cc040b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">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.<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 "defining feature" of Bitco=
in over the long term. =C2=A0 I've heard the term "level playing f=
ield" 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 "SHA-256 forever" hardwar=
e. =C2=A0 Indeed, the reliance on a fairly simple hash seems less and less =
likely a "feature" 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 "next one" 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'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 "irresponsible",=
but it'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"><=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote =
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 would =
the actual end users of Bitcoin (the long term and short term owners of bit=
coins) 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 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>_____=
_________________________<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><br></div>
--001a11375e08ca706b054cc040b4--
|
