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
|
Return-Path: <daniele.pinna@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5762EB7C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Mar 2017 19:34:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot0-f169.google.com (mail-ot0-f169.google.com
[74.125.82.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 85CA6292
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Mar 2017 19:34:00 +0000 (UTC)
Received: by mail-ot0-f169.google.com with SMTP id 102so17475291otv.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Mar 2017 12:34:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=74f0pqaiEH8hwK2+EAVFKnqYTbLXO0HUp5/1n8HcVTw=;
b=szo8j3Vp43MRm8hT7VZvHnEDhlTQz+vncdBOXLGjnkk/ZPYP9kgJN7nPLcXIEhBT/s
H9DZAgj90wm0qG3wBB90AIy10bE0Zilk1P+RUKeGVm5PeZkrLcpTUUGCx9hg3ljSEeae
6xAbLUC2nc6iaCwZ3sgKoCSFuyfcHbnXubpym7z4orQVHAgkm7CzuNZOputI0ZjoYhaA
4R1b/W1VW98qGBqOf/JANw19n49kuy7Im+MC2s9oOPDwuZbILFdsvu1FGzgURqDD132W
MAW/UseSLVhHQndeuufTbU4i2TYxcnQ9beVTr9ojv+fMLSSPxDbZNrpmhK4Smr0GGmqf
ur+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=74f0pqaiEH8hwK2+EAVFKnqYTbLXO0HUp5/1n8HcVTw=;
b=uc/gtDpYACSUja3iIFHZ2tCjTeYHQYVM81ykXLcJJsqy6GoIuNtCeZlR15omX4P3s9
bg08feNE/ZtfGcUmVovKf9uRamtilTJBJimEIufNhlnankzcWZ/7MOO2Xhoca6ma1vZR
YzNJy6Z/nqm1NQU0niSL9z1c6jyacAnSTb/gTcbgzMaSpTxejBwTAvEypw3LgRN0LELB
b9DxdCgHqTWWYOK0lYN+yxCaQmbi53cHkM1LlvZH7DqGi6p53gvy8ZjCW0LIzXk6rRmb
0dHWUZFSRUbyGRv34Bn/oAW4ib19/SPRDiJxQzrDoprKWyEo76KYhDZMGhG7Tu/kiTAd
mqgw==
X-Gm-Message-State: AFeK/H1i4hNX+SbxLAdcIYL8Z7Okx12VHxC2v9XuZo1QkT900JAxD3JjL+CS2nKVRF74abU1nYLFxEU22DnGUA==
X-Received: by 10.157.57.228 with SMTP id y91mr1322108otb.33.1490816039329;
Wed, 29 Mar 2017 12:33:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.43.18 with HTTP; Wed, 29 Mar 2017 12:33:58 -0700 (PDT)
Received: by 10.157.43.18 with HTTP; Wed, 29 Mar 2017 12:33:58 -0700 (PDT)
From: Daniele Pinna <daniele.pinna@gmail.com>
Date: Wed, 29 Mar 2017 21:33:58 +0200
Message-ID: <CAEgR2PEG1UMqY0hzUH4YE_an=qOvQUgfXreSRsoMWfFWxG3Vqg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11406d5a73234b054be3a8ba
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
X-Mailman-Approved-At: Wed, 29 Mar 2017 19:59:09 +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 19:34:01 -0000
--001a11406d5a73234b054be3a8ba
Content-Type: text/plain; charset=UTF-8
What about periodically committing the entire UTXO set to a special
checkpoint block which becomes the new de facto Genesis block?
Daniele
------------------------------
Message: 5
Date: Wed, 29 Mar 2017 16:41:29 +0000
From: Andrew Johnson <andrew.johnson83@gmail.com>
To: David Vorick <david.vorick@gmail.com>
Cc: Bitcoin Dev <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>
Content-Type: text/plain; charset="utf-8"
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>
wrote:
>
> On Mar 29, 2017 12:20 PM, "Andrew Johnson" <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/20170329/9b48ebe3/attachment.html>
------------------------------
--001a11406d5a73234b054be3a8ba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div dir=3D"auto">What about periodically committing the =
entire UTXO set to a special checkpoint block which becomes the new de fact=
o Genesis block?=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">D=
aniele=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><span style=
=3D"font-family:sans-serif;font-size:13.696px">----------------------------=
--</span><br style=3D"font-family:sans-serif;font-size:13.696px"><br style=
=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-family:s=
ans-serif;font-size:13.696px">Message: 5</span><br style=3D"font-family:san=
s-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-size=
:13.696px">Date: Wed, 29 Mar 2017 16:41:29 +0000</span><br style=3D"font-fa=
mily:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;f=
ont-size:13.696px">From: Andrew Johnson <</span><a href=3D"mailto:andrew=
.johnson83@gmail.com" style=3D"text-decoration:none;color:rgb(66,133,244);f=
ont-family:sans-serif;font-size:13.696px">andrew.johnson83@gmail.com</a><sp=
an style=3D"font-family:sans-serif;font-size:13.696px">></span><br style=
=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-family:s=
ans-serif;font-size:13.696px">To: David Vorick <</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">david.vorick@gmail.com</a><spa=
n style=3D"font-family:sans-serif;font-size:13.696px">></span><br style=
=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-family:s=
ans-serif;font-size:13.696px">Cc: Bitcoin Dev <</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">bitcoin-dev@list=
s.<wbr>linuxfoundation.org</a><span style=3D"font-family:sans-serif;font-si=
ze:13.696px">></span><br style=3D"font-family:sans-serif;font-size:13.69=
6px"><span style=3D"font-family:sans-serif;font-size:13.696px">Subject: Re:=
[bitcoin-dev] Hard fork proposal from last week's meeting</span><br st=
yle=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-famil=
y:sans-serif;font-size:13.696px">Message-ID:</span><br style=3D"font-family=
:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-=
size:13.696px">=C2=A0 =C2=A0 =C2=A0 =C2=A0 <</span><a href=3D"mailto:CAA=
y62_%2BJtoAuM-RsrAAp5eiGiO%2BOHLDjzqgbnF2De7TUU7TyYg@mail.gmail.com" style=
=3D"text-decoration:none;color:rgb(66,133,244);font-family:sans-serif;font-=
size:13.696px">CAAy62_+JtoAuM-RsrAAp5eiGiO+<wbr>OHLDjzqgbnF2De7TUU7TyYg@mai=
l.<wbr>gmail.com</a><span style=3D"font-family:sans-serif;font-size:13.696p=
x">></span><br style=3D"font-family:sans-serif;font-size:13.696px"><span=
style=3D"font-family:sans-serif;font-size:13.696px">Content-Type: text/pla=
in; charset=3D"utf-8"</span><br style=3D"font-family:sans-serif;f=
ont-size:13.696px"><br style=3D"font-family:sans-serif;font-size:13.696px">=
<span style=3D"font-family:sans-serif;font-size:13.696px">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"><span style=3D"font-family:sans-serif=
;font-size:13.696px">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-si=
ze:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">as t=
o how to empirically prove it.</span><br style=3D"font-family:sans-serif;fo=
nt-size:13.696px"><br style=3D"font-family:sans-serif;font-size:13.696px"><=
span style=3D"font-family:sans-serif;font-size:13.696px">I do see your poin=
t on increasing load on archival nodes, but the majority</span><br style=3D=
"font-family:sans-serif;font-size:13.696px"><span style=3D"font-family:sans=
-serif;font-size:13.696px">of that load is going to come from new nodes com=
ing online, they're the</span><br style=3D"font-family:sans-serif;font-=
size:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">on=
ly ones going after very old blocks.=C2=A0 =C2=A0I could see that as a pote=
ntial</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span s=
tyle=3D"font-family:sans-serif;font-size:13.696px">attack vector, overwhelm=
the archival nodes by spinning up new nodes</span><br style=3D"font-family=
:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-=
size:13.696px">constantly, therefore making it difficult for a "real&q=
uot; new node to get up</span><br style=3D"font-family:sans-serif;font-size=
:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">to spe=
ed in a reasonable amount of time.</span><br style=3D"font-family:sans-seri=
f;font-size:13.696px"><br style=3D"font-family:sans-serif;font-size:13.696p=
x"><span style=3D"font-family:sans-serif;font-size:13.696px">Perhaps the an=
swer there would be a way to pay an archival node a small</span><br style=
=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-family:s=
ans-serif;font-size:13.696px">amount of bitcoin in order to retrieve blocks=
older than a certain cutoff?</span><br style=3D"font-family:sans-serif;fon=
t-size:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">=
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"><span style=3D=
"font-family:sans-serif;font-size:13.696px">transaction...=C2=A0 Archival n=
odes could set and publish their own policy, let</span><br style=3D"font-fa=
mily:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;f=
ont-size:13.696px">the market decide what those older blocks are worth.=C2=
=A0 Would also help to</span><br style=3D"font-family:sans-serif;font-size:=
13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">incenti=
vize running archival node, which we do need.=C2=A0 Of course, this isn'=
;t</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span styl=
e=3D"font-family:sans-serif;font-size:13.696px">very user friendly.</span><=
br style=3D"font-family:sans-serif;font-size:13.696px"><br style=3D"font-fa=
mily:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;f=
ont-size:13.696px">We can take this to bitcoin-discuss, if we're gettin=
g too far off topic.</span><br style=3D"font-family:sans-serif;font-size:13=
.696px"><br style=3D"font-family:sans-serif;font-size:13.696px"><br style=
=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-family:s=
ans-serif;font-size:13.696px">On Wed, Mar 29, 2017 at 11:25 AM David Vorick=
<</span><a href=3D"mailto:david.vorick@gmail.com" style=3D"text-decorat=
ion:none;color:rgb(66,133,244);font-family:sans-serif;font-size:13.696px">d=
avid.vorick@gmail.com</a><span style=3D"font-family:sans-serif;font-size:13=
.696px">></span><br style=3D"font-family:sans-serif;font-size:13.696px">=
<span style=3D"font-family:sans-serif;font-size:13.696px">wrote:</span><br =
style=3D"font-family:sans-serif;font-size:13.696px"><br style=3D"font-famil=
y:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font=
-size:13.696px">></span><br style=3D"font-family:sans-serif;font-size:13=
.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">> On M=
ar 29, 2017 12:20 PM, "Andrew Johnson" <</span><a href=3D"mail=
to:andrew.johnson83@gmail.com" style=3D"text-decoration:none;color:rgb(66,1=
33,244);font-family:sans-serif;font-size:13.696px">andrew.johnson83@gmail.c=
om</a><span style=3D"font-family:sans-serif;font-size:13.696px">></span>=
<br style=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font=
-family:sans-serif;font-size:13.696px">> wrote:</span><br style=3D"font-=
family:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif=
;font-size:13.696px">></span><br style=3D"font-family:sans-serif;font-si=
ze:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">>=
What's stopping these users from running a pruned node?=C2=A0 Not ever=
y node</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span =
style=3D"font-family:sans-serif;font-size:13.696px">> needs to store a c=
omplete copy of the blockchain.</span><br style=3D"font-family:sans-serif;f=
ont-size:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px=
">></span><br style=3D"font-family:sans-serif;font-size:13.696px"><span =
style=3D"font-family:sans-serif;font-size:13.696px">></span><br style=3D=
"font-family:sans-serif;font-size:13.696px"><span style=3D"font-family:sans=
-serif;font-size:13.696px">> Pruned nodes are not the default configurat=
ion, if it was the default</span><br style=3D"font-family:sans-serif;font-s=
ize:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">>=
; 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"><span style=
=3D"font-family:sans-serif;font-size:13.696px">> node.</span><br style=
=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-family:s=
ans-serif;font-size:13.696px">></span><br style=3D"font-family:sans-seri=
f;font-size:13.696px"><span style=3D"font-family:sans-serif;font-size:13.69=
6px">> But that would also substantially increase the burden on archive =
nodes.</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span =
style=3D"font-family:sans-serif;font-size:13.696px">></span><br style=3D=
"font-family:sans-serif;font-size:13.696px"><span style=3D"font-family:sans=
-serif;font-size:13.696px">></span><br style=3D"font-family:sans-serif;f=
ont-size:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px=
">> Further discussion about disk space requirements should be taken to<=
/span><br style=3D"font-family:sans-serif;font-size:13.696px"><span style=
=3D"font-family:sans-serif;font-size:13.696px">> another thread.</span><=
br style=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-=
family:sans-serif;font-size:13.696px">></span><br style=3D"font-family:s=
ans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-si=
ze:13.696px">></span><br style=3D"font-family:sans-serif;font-size:13.69=
6px"><span style=3D"font-family:sans-serif;font-size:13.696px">> --</spa=
n><br style=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"fo=
nt-family:sans-serif;font-size:13.696px">Andrew Johnson</span><br style=3D"=
font-family:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-=
serif;font-size:13.696px">-------------- next part --------------</span><br=
style=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-fa=
mily:sans-serif;font-size:13.696px">An HTML attachment was scrubbed...</spa=
n><br style=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"fo=
nt-family:sans-serif;font-size:13.696px">URL: <</span><a href=3D"http://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/9b48eb=
e3/attachment.html" style=3D"text-decoration:none;color:rgb(66,133,244);fon=
t-family:sans-serif;font-size:13.696px">http://lists.linuxfoundation.<wbr>o=
rg/pipermail/bitcoin-dev/<wbr>attachments/20170329/9b48ebe3/<wbr>attachment=
.html</a><span style=3D"font-family:sans-serif;font-size:13.696px">></sp=
an><br style=3D"font-family:sans-serif;font-size:13.696px"><br style=3D"fon=
t-family:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-ser=
if;font-size:13.696px">------------------------------</span><br style=3D"fo=
nt-family:sans-serif;font-size:13.696px"></div></div>
--001a11406d5a73234b054be3a8ba--
|
