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
|
Return-Path: <david.vorick@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BACCA516
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Apr 2017 23:51:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA820FC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Apr 2017 23:51:31 +0000 (UTC)
Received: by mail-wm0-f47.google.com with SMTP id t189so25538685wmt.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 09 Apr 2017 16:51:31 -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=7w+F+0P3Wl0/MYqF243rMnzxIdM8Hzlnehsc044SdE0=;
b=Fw6SlolSR9pUkXfwNgN7ap5b2abYo02VIgqwMkRW92jIx3thBWbtyFjFirOLpUvNjj
dwnemBWkgfct1Osu8NQyI914RDD2DbOYyeEDOQe/BIsykfigp7lZ5fJXuAguW//sli8O
vZhefiQbzg/3wyY8EhCP6G7WXqI13WIxicixRflExRVfQ6gToiaqjiTybFnkSdp7EnrN
cwqqgzyg5iYUCL93SQhmeFZQoYiAVRVbfH7BBYKFD210OBaZlgKyvIHV/yG6InzrdvyX
uVKMGBoaqmMkJghZQFfoXQDZZQdBv3LPpTYnKF2vJGJPnNnh5Kw8LNaVgXuwfV07VHjR
JW3g==
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=7w+F+0P3Wl0/MYqF243rMnzxIdM8Hzlnehsc044SdE0=;
b=pLSm6dcpMbotPSWNZTpzd+8osyiFcZEGvw8kVlFU/S5lX6YJzzQ0lbWmb1uRSAKO9h
/U+sGSpKfSxzHBOzQeaZSg8npy4UylQJ+Pv15DZX2FAR3GbUAukLaa5VklVr/b/YYOwS
188a0W03pGeywpklI4emuZODz2bn8XEFFXqIaS/8G7nJhZY6uecL62SYt4wvykNFPb3I
SNOyvUM+FI7ZUperyZSwJHG+luHp8eBXvfiG2f2FDW3m+EeIYgZlirFHLQIqrYakG6Ec
MqY3Ey+KzwrsI5h5O8VWvgjt9uuoPLxXuGPH29YpexIxXD5it6kYNB0V0rtTM89SdY41
QJ1w==
X-Gm-Message-State: AN3rC/6cERaa/RQ30J38QY8XtpGKf8W0Cn1apuuVuCBb1V9IzNSFHe1B
BgEaQ4vj6oH9YnkvJyhQ1Bl2oHdRVw==
X-Received: by 10.28.146.207 with SMTP id u198mr7534353wmd.103.1491781890183;
Sun, 09 Apr 2017 16:51:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.55.9 with HTTP; Sun, 9 Apr 2017 16:51:29 -0700 (PDT)
Received: by 10.28.55.9 with HTTP; Sun, 9 Apr 2017 16:51:29 -0700 (PDT)
In-Reply-To: <CAD1TkXvjtd-LBt6sC=DrkPwk-owRCMEUCEdB9WAVL4LsnTOOSg@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>
From: David Vorick <david.vorick@gmail.com>
Date: Sun, 9 Apr 2017 19:51:29 -0400
Message-ID: <CAFVRnyoqfzJevK5m68bhBuAvUui+eAQsD9ngwDKuGWxVjRBJwQ@mail.gmail.com>
To: Jared Lee Richardson <jaredr26@gmail.com>
Content-Type: multipart/alternative; boundary=001a11442ae0a5999f054cc4895e
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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
Cc: Bitcoin Dev <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 23:51:32 -0000
--001a11442ae0a5999f054cc4895e
Content-Type: text/plain; charset=UTF-8
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.
--001a11442ae0a5999f054cc4895e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Apr 9, 2017 7:00 PM, "Jared Lee Richardson via bitcoin-de=
v" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoi=
n-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attribution"><blo=
ckquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"auto">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.=C2=A0 The more com=
plicated the algorithm, the more secretive the asic technology is developed=
.=C2=A0 Even without it, multi-megawatt gpu farms have already formed in th=
e areas of the world with low energy costs.=C2=A0 I'd support the goal =
if I thought it possible, but I really don't think centralization of mi=
ning can be prevented.</div><div class=3D"elided-text"><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Apr 9, 2017 1:16 PM, "Erik Ar=
onesty 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"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr">Curious: I'm not sure why a serious discussion of POW chan=
ge is not on the table as a part of a longer-term roadmap.<br><br>Done righ=
t, 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. =C2=A0 <br><br>Clearly a level-playing field is critical to ke=
eping centralization from being a "defining feature" of Bitcoin o=
ver 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 that the risk o=
f state actor control and botnet attacks is less than state-actor manipulat=
ion of specialized manufacturing of "SHA-256 forever" hardware. =
=C2=A0 Indeed, the reliance on a fairly simple hash seems less and less lik=
ely 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 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 functio=
n that is guaranteed to fail unless a new consensus POW is selected within =
7 years. =C2=A0 <br><br>Something like that? =C2=A0 <br><br>Haven't tho=
ught 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 quantum=
tech, or some other needed POW switch as well... because the mechanisms wo=
uld be in-place and ready to switch as needed.</div><div><br></div><div>Lot=
s of people seem to panic over POW changes as "irresponsible", bu=
t 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">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></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>
--001a11442ae0a5999f054cc4895e--
|
