Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WYDob-0008OW-Km for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 12:10:45 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.176 as permitted sender) client-ip=209.85.217.176; envelope-from=gmaxwell@gmail.com; helo=mail-lb0-f176.google.com; Received: from mail-lb0-f176.google.com ([209.85.217.176]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WYDoY-0008Sf-8a for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 12:10:45 +0000 Received: by mail-lb0-f176.google.com with SMTP id 10so2237715lbg.35 for ; Thu, 10 Apr 2014 05:10:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.7.8 with SMTP id f8mr1518412laa.39.1397131835580; Thu, 10 Apr 2014 05:10:35 -0700 (PDT) Received: by 10.112.89.68 with HTTP; Thu, 10 Apr 2014 05:10:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Apr 2014 05:10:35 -0700 Message-ID: From: Gregory Maxwell To: Wladimir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1WYDoY-0008Sf-8a Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Chain pruning 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: Thu, 10 Apr 2014 12:10:45 -0000 On Thu, Apr 10, 2014 at 4:57 AM, Wladimir wrote: > Just wondering: Would there be a use for a [static] node that, say, alway= s > serves only the first 100000 blocks? Or, even, a static range like block > 100000 - 200000? The last time we discussed this sipa collected data based on how often blocks were feteched as a function of their depth and there was a huge increase for recent blocks that didn't really level out until 2000 blocks or so=E2=80=94 presumably its not uncommon for nodes to be offline f= or a week or two at a time. But sure I could see a fixed range as also being a useful contribution though I'm struggling to figure out what set of constraints would leave a node without following the consensus? Obviously it has bandwidth if you're expecting to contribute much in serving those historic blocks... and verifying is reasonably cpu cheap with fast ecdsa code. Maybe it has a lot of read only storage? I think it should be possible to express and use such a thing in the protocol even if I'm currently unsure as to why you wouldn't do 100000 - 200000 _plus_ the most recent 144 that you were already keeping around for reorgs. In terms of peer selection, if the blocks you need aren't covered by the nodes you're currently connected to I think you'd prefer to seek node nodes which have the least rare-ness in the ranges they offer. E.g. if you're looking for a block 50 from the tip, you're should probably not prefer to fetch it from someone with blocks 100000-150000 if its one of only 100 nodes that has that range.