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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1UWUvH-0007SX-Ov
for bitcoin-development@lists.sourceforge.net;
Sun, 28 Apr 2013 16:57:59 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.180 as permitted sender)
client-ip=209.85.214.180; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f180.google.com;
Received: from mail-ob0-f180.google.com ([209.85.214.180])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UWUvG-00060T-W8
for bitcoin-development@lists.sourceforge.net;
Sun, 28 Apr 2013 16:57:59 +0000
Received: by mail-ob0-f180.google.com with SMTP id uk5so4903905obc.11
for <bitcoin-development@lists.sourceforge.net>;
Sun, 28 Apr 2013 09:57:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.14.226 with SMTP id s2mr27316561oec.124.1367168273646;
Sun, 28 Apr 2013 09:57:53 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.167.169 with HTTP; Sun, 28 Apr 2013 09:57:53 -0700 (PDT)
In-Reply-To: <CAPg+sBjz8SbqU=2YXrXzwzmvz+NUbokD6KbPwZ5QAXSqCdi++g@mail.gmail.com>
References: <CAPg+sBjSe23eADMxu-1mx0Kg2LGkN+BSNByq0PtZcMxAMh0uTg@mail.gmail.com>
<CANEZrP3FA-5z3gAC1aYbG2EOKM2eDyv7zX3S9+ia2ZJ0LPkKiA@mail.gmail.com>
<CAPg+sBjz8SbqU=2YXrXzwzmvz+NUbokD6KbPwZ5QAXSqCdi++g@mail.gmail.com>
Date: Sun, 28 Apr 2013 18:57:53 +0200
X-Google-Sender-Auth: hUXvGOxcZJi5J5TVrInVu_AqrkI
Message-ID: <CANEZrP2X9A0kBvN8=+G+dn_uqbSYfNhw7dm4od_yfJqDUoxHWg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8fb1f9c44c8bf304db6eab25
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1UWUvG-00060T-W8
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:57:59 -0000
--e89a8fb1f9c44c8bf304db6eab25
Content-Type: text/plain; charset=UTF-8
That's true. It can be perhaps be represented as "I keep the last N blocks"
and then most likely for any given node the policy doesn't change all that
fast, so if you know the best chain height you can calculate which nodes
have what.
> 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.
>
Well, old nodes would ignore it and new nodes wouldn't need it?
> 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.
>
Maybe so, with a "last N blocks" in addr messages though such nodes could
just set their advertised history to zero and not have to deal with serving
blocks to nodes.
If you have a node that serves the chain but doesn't validate it, how does
it know what the best chain is? Just whatever the hardest is?
--e89a8fb1f9c44c8bf304db6eab25
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>That's true. It can be perhaps be represented as "I keep the last=
N blocks" and then most likely for any given node the policy doesn=
9;t change all that fast, so if you know the best chain height you can calc=
ulate which nodes have what.</div>
<div style>=C2=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=
class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im">
<div><span style=3D"color:rgb(34,34,34)">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.=C2=A0</span></div>
</div></div></div></div></blockquote><div><br></div><div style>Well, old no=
des would ignore it and new nodes wouldn't need it?</div><div>=C2=A0</d=
iv><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 class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
class=3D"im">
<div><span style=3D"color:rgb(34,34,34)">The reason for splitting them is t=
hat I think over time these may be handled by different implementations. Yo=
u could have stupid storage/bandwidth nodes that just keep the blockchain a=
round, and others that validate it. Even if that doesn't happen impleme=
ntation-wise, I think these are sufficiently independent functions to start=
thinking about them as such.</span></div>
</div></div></div></div></blockquote><div><br></div><div style>Maybe so, wi=
th a "last N blocks" in addr messages though such nodes could jus=
t set their advertised history to zero and not have to deal with serving bl=
ocks to nodes.</div>
<div style><br></div><div style>If you have a node that serves the chain bu=
t doesn't validate it, how does it know what the best chain is? Just wh=
atever the hardest is?</div></div></div></div>
--e89a8fb1f9c44c8bf304db6eab25--
|
