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
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
|
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 A33FC360
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Apr 2017 00:20:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com
[209.85.220.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DCFD37C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Apr 2017 00:20:50 +0000 (UTC)
Received: by mail-qk0-f181.google.com with SMTP id p22so96789486qka.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 09 Apr 2017 17:20:50 -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=4pGhRAD9O+Lw7nslvaL17iRtAg9HSg22Fds8RcDltco=;
b=Lz7HYgrmr7py8Pcu7gKcWYsP3BKd1/shlUDjU2leFPOK3FdW6NYH8AU7xN6xU53xXT
jFNGMzjlgUa8S5CF6io8hM0Eag+01xc2eg4Ml7X3UPhpNs2oQfTk6bmvD05TbbgNLExt
3hWCpsh1cq1NnWsyEOCxqJwlMaI3DVAQbi0g22SGUP0WRB4w7onRmz4OzyrDczO7tLUZ
S2UFYqD/CCwRFoo7K3TK9ffZZQjLms4EetdVHAOYAwPav+jDf/7aM/q6WrYTYF3uutqr
54UNuy4iZ/cTwbwSbupf5f00UM3QR/BxbyiLKgvQUmndxb+DyEHKt7b+EWTAvc554m+e
F2jA==
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=4pGhRAD9O+Lw7nslvaL17iRtAg9HSg22Fds8RcDltco=;
b=QcTZm5dVSlVkJ1H1wFlLmQaScyoisVx7DA+fohBvUQ9UoAhPl4aZnSAViLG7VxmlQj
Uuxl3I3sz72n6OyJJ4Wl7RwVZTu6B8ghY4DHDkFsO8KAMKOnj7gVJcVKDuSo9buSeTOy
SkGcHP7D6ZkSqgFXkVj9kgGoekoxEWFTI042aXnSpchsVnEx9isZQY+AM9iq4FuSVKlX
Yin5VvBoeF1xgkmoBlJSPq+RqRNc8M0xw12KrtTvYXJpYL2UVnbExNsGzh/sUuQ8qzvb
oTNABknsvu6JIrmYiEjL/hs3t9U2pn/sQXhmYUUOtZhk+de1kfe6ehKjMp7YjTmL6tah
n2iA==
X-Gm-Message-State: AFeK/H2KLvVVdnrqmgceZK/Pu+ET8OjdnQmVkdFD5wqkivzSmcc8fQo4ZI+k3GwnGDTv55dtwW94h2bhnAim6Q==
X-Received: by 10.55.170.215 with SMTP id t206mr37430718qke.303.1491783650059;
Sun, 09 Apr 2017 17:20:50 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.200.0.146 with HTTP; Sun, 9 Apr 2017 17:20:49 -0700 (PDT)
Received: by 10.200.0.146 with HTTP; Sun, 9 Apr 2017 17:20:49 -0700 (PDT)
In-Reply-To: <CAFVRnyoqfzJevK5m68bhBuAvUui+eAQsD9ngwDKuGWxVjRBJwQ@mail.gmail.com>
References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
<Cwhn7YzwaDUZtOygDAgrU1UXjRPG-EiH3Fyz2c95gqOpNnNbiYL1NvhS28yK5wLJCnIqDaBrM6c574dY-O6_-bRjLIFmDe2NCxIuyV1w2dw=@protonmail.com>
<CAJowKg+tYK9j5LTwokMGutD+-SjBQ70U=X7rqHMGSeaG2NEo9A@mail.gmail.com>
<CAD1TkXvjtd-LBt6sC=DrkPwk-owRCMEUCEdB9WAVL4LsnTOOSg@mail.gmail.com>
<CAFVRnyoqfzJevK5m68bhBuAvUui+eAQsD9ngwDKuGWxVjRBJwQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Sun, 9 Apr 2017 20:20:49 -0400
X-Google-Sender-Auth: m_GJ05akky_aBNYvWm56o5PkltI
Message-ID: <CAJowKgKi7hJ8DFbGtgUpJ180=vXqWrLX0PVM9NhxpE2eyn0EZg@mail.gmail.com>
To: David Vorick <david.vorick@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c0654d28b2be0054cc4f26c
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: Mon, 10 Apr 2017 00:50:59 +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: Mon, 10 Apr 2017 00:20:51 -0000
--94eb2c0654d28b2be0054cc4f26c
Content-Type: text/plain; charset=UTF-8
Have you read the cuckoo cycle paper? Finding cycles in massive graphs is
just about the worst thing to use an ASIC for.
It might be a hitherto before unknown emergent property of cryptocurrencies
in general that POW *must* change every 7-9 years. Could bake that into
the protocol too...
On Apr 9, 2017 7:51 PM, "David Vorick" <david.vorick@gmail.com> wrote:
>
>
> On Apr 9, 2017 7:00 PM, "Jared Lee Richardson via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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.
>>
>> _______________________________________________
>> 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
>
>
> The real bottleneck today is the amount of capex required to achieve
> optimal mining. I am strongly in favor of PoW research that investigates
> better PoW, but I do not think that any obvious strategies are known yet to
> improve substantially on computation heavy hashcash.
>
--94eb2c0654d28b2be0054cc4f26c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Have you read the cuckoo cycle paper?=C2=A0 Finding cycle=
s in massive graphs is just about the worst thing to use an ASIC for.<div d=
ir=3D"auto"><br></div><div dir=3D"auto">It might be a hitherto before unkno=
wn emergent property of cryptocurrencies in general that POW *must* change =
every 7-9 years.=C2=A0 Could bake that into the protocol too...</div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Apr 9, 2017 7:=
51 PM, "David Vorick" <<a href=3D"mailto:david.vorick@gmail.co=
m">david.vorick@gmail.com</a>> wrote:<br type=3D"attribution"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"auto"><div><br><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Apr 9, 2017 7:00 PM, "Jared Lee Rich=
ardson via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org=
</a>> wrote:<br type=3D"attribution"><blockquote class=3D"m_-82217816245=
32531501quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"auto">I can speak from personal experience regardin=
g another very prominent altcoin that attempted to utilize an asic-resistan=
t proof of work algorithm, it is only a matter of time before the "asi=
c resistant" algorithm gets its own Asics.=C2=A0 The more complicated =
the algorithm, the more secretive the asic technology is developed.=C2=A0 E=
ven without it, multi-megawatt gpu farms have already formed in the areas o=
f the world with low energy costs.=C2=A0 I'd support the goal if I thou=
ght it possible, but I really don't think centralization of mining can =
be prevented.</div><div class=3D"m_-8221781624532531501elided-text"><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Apr 9, 2017 1:16 PM, =
"Erik Aronesty via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
<wbr>tion.org</a>> wrote:<br type=3D"attribution"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">Curious: I'm not sure why a serious discussio=
n 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 proven, np-complete graph-theoretic or polygon manipulation POW would =
keep Bitcoin in commodity hardware and out of the hands of centralized manu=
facturing for many years. =C2=A0 <br><br>Clearly a level-playing field is c=
ritical to keeping centralization from being a "defining feature"=
of Bitcoin over the long term. =C2=A0 I've heard the term "level =
playing field" bandied about quite a bit. =C2=A0 And it seems to me th=
at the risk of state actor control and botnet attacks is less than state-ac=
tor manipulation of specialized manufacturing of "SHA-256 forever"=
; hardware. =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>Perhaps regular, high-consensus POW changes might even be *necessary* =
as a part of good maintenance of cryptocurrency in general. =C2=A0 Killing =
the existing POW, and using an as-yet undefined, but deployment-bit ready P=
OW field to flip-flop between the current and the "next one" ever=
y 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 sele=
cted within 7 years. =C2=A0 <br><br>Something like that? =C2=A0 <br><br>Hav=
en't thought about it *that* much, but I think the network would respon=
d well to a well known cutover date. =C2=A0 This would enable rapid-respons=
e to quantum tech, or some other needed POW switch as well... because the m=
echanisms 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 "irresponsib=
le", but it's only irresponsible if done irresponsibly.</div><div>=
<br></div></div>______________________________<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></div>
</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></div><div class=3D"gmail_extra" dir=3D"au=
to">The real bottleneck today is the amount of capex required to achieve op=
timal mining. I am strongly in favor of PoW research that investigates bett=
er PoW, but I do not think that any obvious strategies are known yet to imp=
rove substantially on computation heavy hashcash.</div></div>
</blockquote></div></div>
--94eb2c0654d28b2be0054cc4f26c--
|
