From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Sun, 28 Apr 2013 18:44:52 +0200 Message-ID: From: Pieter Wuille To: Mike Hearn 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
On Sun, Apr 28, 2013 at 6:29 PM, Mike Hearn <mike@plan99.ne= t> wrote:
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.

Sure, that's why eventually seve= ral levels may be useful. =A0

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.

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.
=A0
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.

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

W= hat 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 vali= dates (and thus is not an SPV node). It can be combined with NODE_BLOCKS_20= 16 if those blocks are also served.

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.

--=A0
Pieter

--14dae9340b73bf98b604db6e7c8b--