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
|
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 "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'd support the goal if I thought it possi=
ble, but I really don'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, "Erik Aronesty via bitcoin-dev" <<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation=
.org</a>> 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'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.<wbr>linuxfoundation.org</a>></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--
|
