diff options
| author | Mike Hearn <mike@plan99.net> | 2013-04-28 18:57:53 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-04-28 16:57:59 +0000 |
| commit | 9e0045bd5f473e21d776cfb76bc8c2a8e49e508f (patch) | |
| tree | 10f0cbca10f0ef5c122345c421c330c897bfa79b | |
| parent | 24b26e35ba3688d1564915bac0a653c2e7fd3121 (diff) | |
| download | pi-bitcoindev-9e0045bd5f473e21d776cfb76bc8c2a8e49e508f.tar.gz pi-bitcoindev-9e0045bd5f473e21d776cfb76bc8c2a8e49e508f.zip | |
Re: [Bitcoin-development] Service bits for pruned nodes
| -rw-r--r-- | 20/5301c8aade07a0e7ec7a1242c2b82b2039653b | 132 |
1 files changed, 132 insertions, 0 deletions
diff --git a/20/5301c8aade07a0e7ec7a1242c2b82b2039653b b/20/5301c8aade07a0e7ec7a1242c2b82b2039653b new file mode 100644 index 000000000..d703b7292 --- /dev/null +++ b/20/5301c8aade07a0e7ec7a1242c2b82b2039653b @@ -0,0 +1,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-- + + |