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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1UWUih-0001oj-Nh
for bitcoin-development@lists.sourceforge.net;
Sun, 28 Apr 2013 16:44:59 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.169 as permitted sender)
client-ip=209.85.223.169; envelope-from=pieter.wuille@gmail.com;
helo=mail-ie0-f169.google.com;
Received: from mail-ie0-f169.google.com ([209.85.223.169])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UWUif-0006of-Ul
for bitcoin-development@lists.sourceforge.net;
Sun, 28 Apr 2013 16:44:59 +0000
Received: by mail-ie0-f169.google.com with SMTP id ar20so6651973iec.0
for <bitcoin-development@lists.sourceforge.net>;
Sun, 28 Apr 2013 09:44:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.180.197 with SMTP id dq5mr5713991igc.22.1367167492645;
Sun, 28 Apr 2013 09:44:52 -0700 (PDT)
Received: by 10.50.25.230 with HTTP; Sun, 28 Apr 2013 09:44:52 -0700 (PDT)
In-Reply-To: <CANEZrP3FA-5z3gAC1aYbG2EOKM2eDyv7zX3S9+ia2ZJ0LPkKiA@mail.gmail.com>
References: <CAPg+sBjSe23eADMxu-1mx0Kg2LGkN+BSNByq0PtZcMxAMh0uTg@mail.gmail.com>
<CANEZrP3FA-5z3gAC1aYbG2EOKM2eDyv7zX3S9+ia2ZJ0LPkKiA@mail.gmail.com>
Date: Sun, 28 Apr 2013 18:44:52 +0200
Message-ID: <CAPg+sBjz8SbqU=2YXrXzwzmvz+NUbokD6KbPwZ5QAXSqCdi++g@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=14dae9340b73bf98b604db6e7c8b
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UWUif-0006of-Ul
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Service bits for pruned nodes
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 28 Apr 2013 16:44:59 -0000
--14dae9340b73bf98b604db6e7c8b
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Apr 28, 2013 at 6:29 PM, Mike Hearn <mike@plan99.net> wrote:
> I'd imagined that nodes would be able to pick their own ranges to keep
> rather than have fixed chosen intervals. "Everything or two weeks" is
> rather restrictive - presumably node operators are constrained by physical
> disk space, which means the quantity of blocks they would want to keep can
> vary with sizes of blocks, cost of storage, etc.
>
Sure, that's why eventually several levels may be useful.
Adding new fields to the addr message and relaying those fields to newer
> nodes means every node could advertise the height at which it pruned. I
> know it means a longer time before the data is available everywhere vs
> service bits, but it seems like most nodes won't be pruning right away
> anyway. There's plenty of time for upgrades.
>
That's a more flexible model, indeed. I'm not sure how important speed of
propagation will be though - it may be very slow, given that there are
100000s of IPs circulating, and only a few are relayed in one go between
nodes. Even then, I'd like to see the "relay/validation" responsibility
split off from the "serve historic data" one, and have separate service
bits for those.
> If an old node connected to a new node and getdata-d blocks that had been
> pruned, immediate disconnection should make the old node go find a
> different one. It means the combination of old node+not run for a long time
> might take a while before it can find a node that has what it wants, but
> that doesn't seem like a big deal.
>
Disconnecting in case something is requested that isn't served seems like
an acceptable behaviour, yes. A specific message indicating data is pruned
may be more flexible, but more complex to handle too.
What is the use case for NODE_VALIDATE? Nodes that throw away blocks almost
> immediately? Why would a node do that?
>
NODE_VALIDATE doesn't say anything about which blocks are available, it
just means it relays and validates (and thus is not an SPV node). It can be
combined with NODE_BLOCKS_2016 if those blocks are also served.
The reason for splitting them is that I think over time these may be
handled by different implementations. You could have stupid
storage/bandwidth nodes that just keep the blockchain around, and others
that validate it. Even if that doesn't happen implementation-wise, I think
these are sufficiently independent functions to start thinking about them
as such.
--
Pieter
--14dae9340b73bf98b604db6e7c8b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sun, Apr 28, 2013 at 6:29 PM, Mike Hearn <span dir=3D"l=
tr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.ne=
t</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">I'd imagined that nodes would be able to pick their ow=
n ranges to keep rather than have fixed chosen intervals. "Everything =
or two weeks" is rather restrictive - presumably node operators are co=
nstrained by physical disk space, which means the quantity of blocks they w=
ould want to keep can vary with sizes of blocks, cost of storage, etc.</div=
>
</blockquote><div><br></div><div style>Sure, that's why eventually seve=
ral levels may be useful. =A0</div><div style><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr"><div>Adding new fields to the addr message and relaying th=
ose fields to newer nodes means every node could advertise the height at wh=
ich it pruned. I know it means a longer time before the data is available e=
verywhere vs service bits, but it seems like most nodes won't be prunin=
g right away anyway. There's plenty of time for upgrades.</div>
</div></blockquote><div><br></div><div style>That's a more flexible mod=
el, indeed. I'm not sure how important speed of propagation will be tho=
ugh - it may be very slow, given that there are 100000s of IPs circulating,=
and only a few are relayed in one go between nodes. Even then, I'd lik=
e to see the "relay/validation" responsibility split off from the=
"serve historic data" one, and have separate service bits for th=
ose.</div>
<div style>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>If=
an old node connected to a new node and getdata-d blocks that had been pru=
ned, immediate disconnection should make the old node go find a different o=
ne. It means the combination of old node+not run for a long time might take=
a while before it can find a node that has what it wants, but that doesn&#=
39;t seem like a big deal.</div>
</div></blockquote><div><br></div><div style>Disconnecting in case somethin=
g is requested that isn't served seems like an acceptable behaviour, ye=
s. A specific message indicating data is pruned may be more flexible, but m=
ore complex to handle too.=A0</div>
<div style><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>W=
hat is the use case for NODE_VALIDATE? Nodes that throw away blocks almost =
immediately? Why would a node do that?</div>
</div></blockquote><div><br></div><div style>NODE_VALIDATE doesn't say =
anything about which blocks are available, it just means it relays and vali=
dates (and thus is not an SPV node). It can be combined with NODE_BLOCKS_20=
16 if those blocks are also served.</div>
<div style><br></div><div style>The reason for splitting them is that I thi=
nk over time these may be handled by different implementations. You could h=
ave stupid storage/bandwidth nodes that just keep the blockchain around, an=
d others that validate it. Even if that doesn't happen implementation-w=
ise, I think these are sufficiently independent functions to start thinking=
about them as such.</div>
<div style><br></div><div style>--=A0</div><div style>Pieter</div><div styl=
e><br></div></div></div></div>
--14dae9340b73bf98b604db6e7c8b--
|
