summaryrefslogtreecommitdiff
path: root/7c/135b0b090e5119963d5a9d8badc02fc4a19957
blob: b31d00374ede7fad7e0032c8bab6ee0b658df755 (plain)
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
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EF6DFBA3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 20:28:36 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 96A92FF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 20:28:35 +0000 (UTC)
Received: from [192.168.50.29] ([24.86.172.170]) by mail.gmx.com (mrgmx003
	[212.227.17.184]) with ESMTPSA (Nemesis) id 0MaIsi-1cZaOV3kAy-00Jw2e;
	Wed, 29 Mar 2017 22:28:32 +0200
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_041E4DBB-3309-4DBE-967F-6D2C85BD0511"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <CAEgR2PEG1UMqY0hzUH4YE_an=qOvQUgfXreSRsoMWfFWxG3Vqg@mail.gmail.com>
Date: Wed, 29 Mar 2017 13:28:29 -0700
Message-Id: <E54123C8-F124-449A-9C65-F40FA6917813@gmx.com>
References: <CAEgR2PEG1UMqY0hzUH4YE_an=qOvQUgfXreSRsoMWfFWxG3Vqg@mail.gmail.com>
To: Daniele Pinna <daniele.pinna@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.2104)
X-Provags-ID: V03:K0:OiyGvustTO7ixBAyuabNyLmiAkEFTo8Ug5twNjSzTniKewv0o9p
	zr10gpyLd1g3GosHxhsjfHhLUsfVleUQBJxE20US2gc+rqLjpH7ocmX542OL4RLYPEE/mL4
	k1rAtraIQr1GCDbywz9+d42szKcTXIzypdCqEtNzPLTvZkbton15tYEuTQVLPn6U5RE3zk5
	9WrMJLQGcuN9ke5e1jA/Q==
X-UI-Out-Filterresults: notjunk:1;V01:K0:OaRDYIeyilU=:1Qau8Bow8kihIJjetOIUlB
	oxfqFN1w7AspZE2aSUGG/gB0sQMgLk/+UgKSKHGZo2RsW+PX02OAAwT1ZcCKi4QVpWmSqwsmp
	9aeFJk1J3BDR7b13tchnx9DMhUpla4EKkf7texg/elQbn8o09W0WkzIpJIKf1mfvjviGheueA
	7JN0hEaBgyTcM6z9Nf5VrJKBBYI0XiEiUULxJ5u5oqeEz3djlHNByd0npuZrh9nHRVUQEL1HP
	L2AaYHJiTaJ6NlY9bE32NK7LCubvL3SDqYjeuHstqWB+sV7J5AAXMUbfIbP/CDrYnV0+7LLZr
	8Pv54ksy16JPBDkICZi2Lcc6YDVqFFibM7TyEbym/8Z796KL2+XR1z0PwhdSVcl4cgwDvOf94
	z0l+5X7zXd3zaEOpAMU8Ms3sQfK/mssWQwDFgnrak023XsnJa74CSbModXRxoU9F/a8Y+JUBN
	Mq6x5iPnK3GOvVS8STMlmIC5LVLO3MurapB8n/efXXPJEo8SlupvGtt+pQID4hFuc3Sifjdqx
	nn3dfDLv2EeKG3CwallRcqmAWTW2fmLYgm5uABNz21OZFpBNfiK84yGRDxVRx9QV2KE9uR8M7
	rMc8IFMIyN7kY843UB5am/gHvs3IVvMYP3ceR60Q+o2vQbBZBJ7+e+AxWJPfa2nRPd1PkLdHJ
	ZR28gtXeZEowRaHFMkwSMWAcWuD9GvOOzNGUqSN0eC/+/7WybjL8r2K3sSAIkNhiimqx7Se3a
	Vj/owkRZslxElC37ma0ow9W5sypUzozHjv15UzAEeud+nBv+t8qB88Jevu4+AvAeL23Ojk1PJ
	TdVb0Y1
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 29 Mar 2017 20:30:24 +0000
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 20:28:37 -0000


--Apple-Mail=_041E4DBB-3309-4DBE-967F-6D2C85BD0511
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I believe nearly everyone at Bitcoin Unlimited would be supportive of a =
UTXO check-pointing scheme.  I=E2=80=99d love to see this happen, as it =
would greatly reduce the time needed to get a new node up-and-running, =
for node operators who are comfortable trusting these commitments. =20

I=E2=80=99m confident that we could work with the miners who we have =
good relationships with to start including the root hash of the =
(lagging) UTXO set in their coinbase transactions, in order to begin =
transforming this idea into reality.  We could also issue regular =
transactions from =E2=80=9Csemi-trusted=E2=80=9D addresses controlled by =
known people that include the same root hash in an OP_RETURN output, =
which would allow cross-checking against the miners=E2=80=99 UTXO =
commitments, as part of this initial =E2=80=9Cprototype=E2=80=9D system.

This would "get the ball rolling" on UTXO commitments in a =
permissionless way (no one can stop us from doing this). If the results =
from this prototype commitment scheme were positive, then perhaps there =
would be support from the community and miners to enforce a new rule =
which requires the (lagging) root hashes be included in new blocks.  At =
that point, the UTXO commitment scheme is no longer a prototype but a =
trusted feature of the Bitcoin network.   =20

On that topic, are there any existing proposals detailing a canonical =
ordering of the UTXO set and a scheme to calculate the root hash?

Best regards,
Peter


> On Mar 29, 2017, at 12:33 PM, Daniele Pinna via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> What about periodically committing the entire UTXO set to a special =
checkpoint block which becomes the new de facto Genesis block?=20
>=20
> Daniele=20
>=20
> ------------------------------
>=20
> Message: 5
> Date: Wed, 29 Mar 2017 16:41:29 +0000
> From: Andrew Johnson <andrew.johnson83@gmail.com =
<mailto:andrew.johnson83@gmail.com>>
> To: David Vorick <david.vorick@gmail.com =
<mailto:david.vorick@gmail.com>>
> Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>>
> Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
> Message-ID:
>         =
<CAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg@mail.gmail.com =
<mailto:CAAy62_%2BJtoAuM-RsrAAp5eiGiO%2BOHLDjzqgbnF2De7TUU7TyYg@mail.gmail=
.com>>
> Content-Type: text/plain; charset=3D"utf-8"
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> We can take this to bitcoin-discuss, if we're getting too far off =
topic.
>=20
>=20
> On Wed, Mar 29, 2017 at 11:25 AM David Vorick <david.vorick@gmail.com =
<mailto:david.vorick@gmail.com>>
> wrote:
>=20
> >
> > 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: =
<http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/201703=
29/9b48ebe3/attachment.html =
<http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/201703=
29/9b48ebe3/attachment.html>>
>=20
> ------------------------------
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_041E4DBB-3309-4DBE-967F-6D2C85BD0511
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">I believe nearly everyone at Bitcoin Unlimited would be =
supportive of a UTXO check-pointing scheme. &nbsp;I=E2=80=99d love to =
see this happen, as it would greatly reduce the time needed to get a new =
node up-and-running, for node operators who are comfortable trusting =
these commitments. &nbsp;<div class=3D""><br class=3D""></div><div =
class=3D"">I=E2=80=99m confident that we could work with the miners who =
we have good relationships with to start including the root hash of the =
(lagging) UTXO set in their coinbase transactions, in order to begin =
transforming this idea into reality. &nbsp;We could also issue regular =
transactions from =E2=80=9Csemi-trusted=E2=80=9D addresses controlled by =
known people that include the same root hash in an OP_RETURN output, =
which would allow cross-checking against the miners=E2=80=99 UTXO =
commitments, as part of this initial =E2=80=9Cprototype=E2=80=9D =
system.</div><div class=3D""><br class=3D""></div><div class=3D"">This =
would "get the ball rolling" on UTXO commitments in a permissionless way =
(no one can stop us from doing this). If the results from this prototype =
commitment scheme were positive, then perhaps there would be support =
from the community and miners to enforce a new rule which requires the =
(lagging) root hashes be included in new blocks. &nbsp;At that point, =
the UTXO commitment scheme is no longer a prototype but a trusted =
feature of the Bitcoin network. &nbsp; &nbsp;<div class=3D""><br =
class=3D""></div><div class=3D"">On that topic, are there any existing =
proposals detailing a canonical ordering of the UTXO set and a scheme to =
calculate the root hash?</div><div class=3D""><br class=3D""></div><div =
class=3D"">Best regards,</div><div class=3D"">Peter<br class=3D""><div =
class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
Mar 29, 2017, at 12:33 PM, Daniele Pinna via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"auto" =
class=3D""><div dir=3D"auto" class=3D"">What about periodically =
committing the entire UTXO set to a special checkpoint block which =
becomes the new de facto Genesis block?&nbsp;</div><div dir=3D"auto" =
class=3D""><br class=3D""></div><div dir=3D"auto" =
class=3D"">Daniele&nbsp;</div><div dir=3D"auto" class=3D""><br =
class=3D""></div><div dir=3D"auto" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">------------------------------</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">Message: =
5</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">Date: Wed, 29 Mar 2017 16:41:29 +0000</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">From: =
Andrew Johnson &lt;</span><a href=3D"mailto:andrew.johnson83@gmail.com" =
style=3D"text-decoration:none;color:rgb(66,133,244);font-family:sans-serif=
;font-size:13.696px" class=3D"">andrew.johnson83@gmail.com</a><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">To: David =
Vorick &lt;</span><a href=3D"mailto:david.vorick@gmail.com" =
style=3D"text-decoration:none;color:rgb(66,133,244);font-family:sans-serif=
;font-size:13.696px" class=3D"">david.vorick@gmail.com</a><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">Cc: =
Bitcoin Dev &lt;</span><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
style=3D"text-decoration:none;color:rgb(66,133,244);font-family:sans-serif=
;font-size:13.696px" class=3D"">bitcoin-dev@lists.<wbr =
class=3D"">linuxfoundation.org</a><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">Subject: =
Re: [bitcoin-dev] Hard fork proposal from last week's meeting</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">Message-ID:</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">&nbsp; =
&nbsp; &nbsp; &nbsp; &lt;</span><a =
href=3D"mailto:CAAy62_%2BJtoAuM-RsrAAp5eiGiO%2BOHLDjzqgbnF2De7TUU7TyYg@mai=
l.gmail.com" =
style=3D"text-decoration:none;color:rgb(66,133,244);font-family:sans-serif=
;font-size:13.696px" class=3D"">CAAy62_+JtoAuM-RsrAAp5eiGiO+<wbr =
class=3D"">OHLDjzqgbnF2De7TUU7TyYg@mail.<wbr class=3D"">gmail.com</a><span=
 style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">Content-Type: text/plain; charset=3D"utf-8"</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">I believe =
that as we continue to add users to the system by scaling</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">capacity =
that we will see more new nodes appear, but I'm at a bit of a =
loss</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">as to how to empirically prove it.</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">I do see =
your point on increasing load on archival nodes, but the =
majority</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">of that load is going to come from new nodes coming online, =
they're the</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">only ones going after very old blocks.&nbsp; &nbsp;I could =
see that as a potential</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">attack =
vector, overwhelm the archival nodes by spinning up new nodes</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">constantly,=
 therefore making it difficult for a "real" new node to get up</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">to speed =
in a reasonable amount of time.</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">Perhaps =
the answer there would be a way to pay an archival node a =
small</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">amount of bitcoin in order to retrieve blocks older than a =
certain cutoff?</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">Include =
an IP address for the node asking for the data as metadata in =
the</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">transaction...&nbsp; Archival nodes could set and publish =
their own policy, let</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">the =
market decide what those older blocks are worth.&nbsp; Would also help =
to</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">incentivize running archival node, which we do need.&nbsp; Of =
course, this isn't</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">very user =
friendly.</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">We can take this to bitcoin-discuss, if we're getting too far =
off topic.</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">On Wed, Mar 29, 2017 at 11:25 AM David Vorick &lt;</span><a =
href=3D"mailto:david.vorick@gmail.com" =
style=3D"text-decoration:none;color:rgb(66,133,244);font-family:sans-serif=
;font-size:13.696px" class=3D"">david.vorick@gmail.com</a><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">wrote:</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">&gt; On =
Mar 29, 2017 12:20 PM, "Andrew Johnson" &lt;</span><a =
href=3D"mailto:andrew.johnson83@gmail.com" =
style=3D"text-decoration:none;color:rgb(66,133,244);font-family:sans-serif=
;font-size:13.696px" class=3D"">andrew.johnson83@gmail.com</a><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">&gt; =
wrote:</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">&gt; =
What's stopping these users from running a pruned node?&nbsp; Not every =
node</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt; needs to store a complete copy of the =
blockchain.</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">&gt; =
Pruned nodes are not the default configuration, if it was the =
default</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt; configuration then I think you would see far more users =
running a pruned</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">&gt; =
node.</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">&gt; But =
that would also substantially increase the burden on archive =
nodes.</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">&gt; =
Further discussion about disk space requirements should be taken =
to</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt; another thread.</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">&gt; =
--</span><br style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""><span style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">Andrew Johnson</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">-------------- next part --------------</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">An HTML =
attachment was scrubbed...</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D"">URL: =
&lt;</span><a =
href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments=
/20170329/9b48ebe3/attachment.html" =
style=3D"text-decoration:none;color:rgb(66,133,244);font-family:sans-serif=
;font-size:13.696px" class=3D"">http://lists.linuxfoundation.<wbr =
class=3D"">org/pipermail/bitcoin-dev/<wbr =
class=3D"">attachments/20170329/9b48ebe3/<wbr =
class=3D"">attachment.html</a><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">&gt;</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><br =
style=3D"font-family:sans-serif;font-size:13.696px" class=3D""><span =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D"">------------------------------</span><br =
style=3D"font-family:sans-serif;font-size:13.696px" =
class=3D""></div></div>
_______________________________________________<br class=3D"">bitcoin-dev =
mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br =
class=3D""></div></div></div></body></html>=

--Apple-Mail=_041E4DBB-3309-4DBE-967F-6D2C85BD0511--