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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Service bits for pruned nodes
Precedence: list

--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&#39;s true. It can be perhaps be represented as &quot;I keep the last=
 N blocks&quot; and then most likely for any given node the policy doesn&#3=
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&#39;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&#39;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&#39;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 &quot;last N blocks&quot; 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&#39;t validate it, how does it know what the best chain is? Just wh=
atever the hardest is?</div></div></div></div>

--e89a8fb1f9c44c8bf304db6eab25--