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
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
|
Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4102989E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Mar 2017 17:14:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f179.google.com (mail-wr0-f179.google.com
[209.85.128.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED38B1D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Mar 2017 17:14:49 +0000 (UTC)
Received: by mail-wr0-f179.google.com with SMTP id l43so25075549wre.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Mar 2017 10:14:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:cc:from:message-id:date:user-agent
:mime-version:in-reply-to;
bh=No7qS6JMatS7A4BKxPkQP7fjQobrVOxF0EIzNQ4o0eg=;
b=hIWcyEaiwOGyjFOJ1i4fH8NtveuGWlB9Esxye4Iv30TCkS5XtkV4kbNFy4oVe04JiQ
MPRLWnGLw6iwLQdlY4RW551CDpJfix4wAGw1H3Ki3OEb+1JJOLmX4wIieDAhFGbmW/9f
48t975cLIdyMD4g3AI9oDcQho03KtqqV7hr0nh0dZJAL4VhQYZ6PoSAXVPBy4sHXhHrA
dZ2TxsuOrRa0tL5OudTx6LyzeH3eF4g4B9kuiNbs53stpoGswRmpjKM0eoqsPX/6WlMy
ad4PKwdW5g0FVZxrFMAwIN1s+KQOCR7xI+BGadO2hn+JLcz4NBjwd3pfU9UgYVUOSe98
qSyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:cc:from:message-id:date
:user-agent:mime-version:in-reply-to;
bh=No7qS6JMatS7A4BKxPkQP7fjQobrVOxF0EIzNQ4o0eg=;
b=O0Uk/f03ivM2FOSOD8uQR2g7xBWWFXCcgsJpUwVsZC+A1L/VJdog9cP1OOcXYafBFA
w+40XQ0v0isP09EyIc+Byhn7MEZ8BHyAYxhElDywyqKHQFPHgYc1zCZeWBTITKXFTzIK
B+xNw9v4XSwHpERm+vDLg7pFjXBxz1NQhmPvxvr1/exws1Dm2hV8f3LzOQCgtd22Kzr3
QeU95uXSb2mckLPcnpkHWTqz4F6DgOFd8HqjcaY8O7mfu3C2Q2BpiyPqkLEuiHhSC+51
kJFkcEKNZfQkXFxAAUqrFXygD66dIoN0in1cIR9jmyHqgta0LHg459hKL04ZsyEqhzU0
92yw==
X-Gm-Message-State: AFeK/H1Pi/lBA4P9QiI+zEtpFUgX7EVorAqzANDwNSIEtUwgJgGA4A48quOHu2wlmSEKIg==
X-Received: by 10.28.211.9 with SMTP id k9mr1781214wmg.96.1490807688606;
Wed, 29 Mar 2017 10:14:48 -0700 (PDT)
Received: from [192.168.1.10] (ANice-654-1-52-124.w83-201.abo.wanadoo.fr.
[83.201.223.124]) by smtp.googlemail.com with ESMTPSA id
s17sm10234171wrc.25.2017.03.29.10.14.46
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 29 Mar 2017 10:14:47 -0700 (PDT)
To: Andrew Johnson <andrew.johnson83@gmail.com>,
David Vorick <david.vorick@gmail.com>
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
<CAB-xxiPV9oN1r2hV5a=U1pcYuiZ_qmth-AM-H+1Cjgc2uw-0xA@mail.gmail.com>
<CAFVRnyr=cYf34X80+dLHwYEPHdqA7mMtYZ_gD6j09C+aM31gQQ@mail.gmail.com>
<f61153c3-9afb-5cee-2c6b-70d67208f015@gmail.com>
<CAFVRnyo1XGNbq_F8UfqqJWHCVH14iMCUMU-R5bOh+h3mtwSUJg@mail.gmail.com>
<CAFVRnyqxQhu0c-ACfzR5=Z=C1SbR70jrfCaCeEdfSJASSnzpqw@mail.gmail.com>
<CAAy62_J+huc_d5r-gyYCMGh6AjfJH4YiEVov9eBmwbKbWTe0Sw@mail.gmail.com>
<CAFVRnyrpfRUVNWjR19+ou7PxQuLbaoY8yta+BAAK3zbMrdsOhw@mail.gmail.com>
<CAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg@mail.gmail.com>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <237b67c9-6233-906d-c754-19a5c74285b7@gmail.com>
Date: Wed, 29 Mar 2017 19:14:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------2CAD60577B871E0EAF28861B"
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,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] Hard fork proposal from last week's meeting
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: Wed, 29 Mar 2017 17:14:51 -0000
This is a multi-part message in MIME format.
--------------2CAD60577B871E0EAF28861B
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Well it's not going off-topic since the btc folks need now to find a way
to counter the attack
The disk space story is know to be a non issue, because encouraging
people to run nodes while they don't know how to dedicate the right
storage space that is trivial and not expensive to get today is just
stupid, they should not try to run full nodes, and no I tested with non
SSD drives, I was more wondering about cpu and bandwidth use, but did
not notice any impact, just stopped because a repeated sw bug or drive
issue desynched the chain and bitcoin-qt was trying to reload it from
the begining each time, which in my case was taking 10 days despite of
good bandwidth (which would allow me to torrent the entire chain + state
in less than 20 hours), so I stopped after the 3rd crash, setting up a
full node on my servers is still in the todo list (very low priority for
the reasons already explained)
Running a prune node implies first to setup a full node, so the same
problematic applies and then the advantage of pruning is not really
obvious, I don't know what's the strange story about "archival nodes", I
proposed something else
Back to the topic, the conclusion is that this is not difficult at all
for many people to run efficient full nodes, ideally the community
should promote this, seed a torrent with a recent state, implement a
patch to defeat BU plans and have everybody upgrade
But of course this will not happen
Le 29/03/2017 à 18:41, Andrew Johnson a écrit :
> I believe that as we continue to add users to the system by scaling
> capacity that we will see more new nodes appear, but I'm at a bit of a
> loss as to how to empirically prove it.
>
> I do see your point on increasing load on archival nodes, but the
> majority of that load is going to come from new nodes coming online,
> they're the only ones going after very old blocks. I could see that
> as a potential attack vector, overwhelm the archival nodes by spinning
> up new nodes constantly, therefore making it difficult for a "real"
> new node to get up to speed in a reasonable amount of time.
>
> Perhaps the answer there would be a way to pay an archival node a
> small amount of bitcoin in order to retrieve blocks older than a
> certain cutoff? Include an IP address for the node asking for the
> data as metadata in the transaction... Archival nodes could set and
> publish their own policy, let the market decide what those older
> blocks are worth. Would also help to incentivize running archival
> node, which we do need. Of course, this isn't very user friendly.
>
> We can take this to bitcoin-discuss, if we're getting too far off topic.
>
>
> On Wed, Mar 29, 2017 at 11:25 AM David Vorick <david.vorick@gmail.com
> <mailto:david.vorick@gmail.com>> wrote:
>
>
> On Mar 29, 2017 12:20 PM, "Andrew Johnson"
> <andrew.johnson83@gmail.com <mailto:andrew.johnson83@gmail.com>>
> wrote:
>
> What's stopping these users from running a pruned node? Not
> every node needs to store a complete copy of the blockchain.
>
>
> Pruned nodes are not the default configuration, if it was the
> default configuration then I think you would see far more users
> running a pruned node.
>
> But that would also substantially increase the burden on archive
> nodes.
>
>
> Further discussion about disk space requirements should be taken
> to another thread.
>
>
> --
> Andrew Johnson
>
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
--------------2CAD60577B871E0EAF28861B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Well it's not going off-topic since the btc folks need now to
find a way to counter the attack</p>
<p>The disk space story is know to be a non issue, because
encouraging people to run nodes while they don't know how to
dedicate the right storage space that is trivial and not expensive
to get today is just stupid, they should not try to run full
nodes, and no I tested with non SSD drives, I was more wondering
about cpu and bandwidth use, but did not notice any impact, just
stopped because a repeated sw bug or drive issue desynched the
chain and bitcoin-qt was trying to reload it from the begining
each time, which in my case was taking 10 days despite of good
bandwidth (which would allow me to torrent the entire chain +
state in less than 20 hours), so I stopped after the 3rd crash,
setting up a full node on my servers is still in the todo list
(very low priority for the reasons already explained)<br>
</p>
<p>Running a prune node implies first to setup a full node, so the
same problematic applies and then the advantage of pruning is not
really obvious, I don't know what's the strange story about
"archival nodes", I proposed something else</p>
<p>Back to the topic, the conclusion is that this is not difficult
at all for many people to run efficient full nodes, ideally the
community should promote this, seed a torrent with a recent state,
implement a patch to defeat BU plans and have everybody upgrade</p>
<p>But of course this will not happen<br>
</p>
<br>
<div class="moz-cite-prefix">Le 29/03/2017 à 18:41, Andrew Johnson a
écrit :<br>
</div>
<blockquote
cite="mid:CAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg@mail.gmail.com"
type="cite">
<div>I believe that as we continue to add users to the system by
scaling capacity that we will see more new nodes appear, but I'm
at a bit of a loss as to how to empirically prove it. </div>
<div><br>
</div>
<div>I do see your point on increasing load on archival nodes, but
the majority of that load is going to come from new nodes coming
online, they're the only ones going after very old blocks. I
could see that as a potential attack vector, overwhelm the
archival nodes by spinning up new nodes constantly, therefore
making it difficult for a "real" new node to get up to speed in
a reasonable amount of time. </div>
<div><br>
</div>
<div>Perhaps the answer there would be a way to pay an archival
node a small amount of bitcoin in order to retrieve blocks older
than a certain cutoff? Include an IP address for the node
asking for the data as metadata in the transaction... Archival
nodes could set and publish their own policy, let the market
decide what those older blocks are worth. Would also help to
incentivize running archival node, which we do need. Of course,
this isn't very user friendly. </div>
<div><br>
</div>
<div>We can take this to bitcoin-discuss, if we're getting too far
off topic.</div>
<div><br>
</div>
<div><br>
<div class="gmail_quote">
<div>On Wed, Mar 29, 2017 at 11:25 AM David Vorick <<a
moz-do-not-send="true"
href="mailto:david.vorick@gmail.com">david.vorick@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_msg">
<div class="gmail_msg">
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_extra gmail_msg">
<div class="gmail_quote gmail_msg">On Mar 29, 2017
12:20 PM, "Andrew Johnson" <<a
moz-do-not-send="true"
href="mailto:andrew.johnson83@gmail.com"
class="gmail_msg" target="_blank">andrew.johnson83@gmail.com</a>>
wrote:<br type="attribution" class="gmail_msg">
<blockquote class="m_-8040488637046144933quote
gmail_msg" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_msg">What's stopping these users
from running a pruned node? Not every node
needs to store a complete copy of the
blockchain. </div>
</blockquote>
</div>
</div>
</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
</div>
<div class="gmail_msg">
<div class="gmail_msg"><span
style="font-family:sans-serif" class="gmail_msg">Pruned
nodes are not the default configuration, if it was the
default configuration then I think you would see far
more users running a pruned node.</span>
<div style="font-family:sans-serif" class="gmail_msg"><br
class="gmail_msg">
</div>
<div style="font-family:sans-serif" class="gmail_msg">But
that would also substantially increase the burden on
archive nodes.</div>
<br class="gmail_msg">
</div>
<div class="gmail_msg"><br class="gmail_msg">
<span style="font-family:sans-serif" class="gmail_msg">Further
discussion about disk space requirements should be
taken to another thread.</span><br class="gmail_msg">
</div>
<div class="gmail_msg">
<div class="gmail_extra gmail_msg">
<div class="gmail_quote gmail_msg">
<blockquote class="m_-8040488637046144933quote
gmail_msg" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_msg"><br class="gmail_msg">
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<div dir="ltr">-- <br>
</div>
<div data-smartmail="gmail_signature">Andrew Johnson<br>
<div><br>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.org">http://torrent-live.org</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a></pre>
</body>
</html>
--------------2CAD60577B871E0EAF28861B--
|
