Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.174 as permitted sender)
	client-ip=209.85.223.174; envelope-from=gmaxwell@gmail.com;
	helo=mail-ie0-f174.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAJHLa0O3fgmg4AFAM9+4RRkhSo8ekATs2Ks+Ry7ooQafjQ-4qw@mail.gmail.com>
References: <CANJO25J1WRHtfQLVXUB2s_sjj39pTPWmixAcXNJ3t-5os8RPmQ@mail.gmail.com>
	<CANJO25JTtfmfsOQYOzJeksJn3CoKE3W8iLGsRko-_xd4XhB3ZA@mail.gmail.com>
	<CAJHLa0O5OxaX5g3u=dnCY6Lz_gK3QZgQEPNcWNVRD4JziwAmvg@mail.gmail.com>
	<20150512171640.GA32606@savin.petertodd.org>
	<CAE-z3OV3VdSoiTSfASwYHr1CjZSqio303sqGq_1Y9yaYgov2sw@mail.gmail.com>
	<CAAS2fgRzGkcJbWbJmFN2-NSJGUcLdPKp0q7FjM0x7WDvHoRq=g@mail.gmail.com>
	<CANJO25+qURmDzsMgnm7+tsw7icFO--gWhmKmQPuNQCoh_R2big@mail.gmail.com>
	<CAJHLa0PDbxuqRHuGNhsyvLpAaDq=ZHSg_u-Sb7FqNVnYrhFkFg@mail.gmail.com>
	<CAAS2fgTCMeNdcmMxURxaoAJn8=XZnTP8Gp6PbRk5w7KXAZ8t3g@mail.gmail.com>
	<CAJHLa0O3fgmg4AFAM9+4RRkhSo8ekATs2Ks+Ry7ooQafjQ-4qw@mail.gmail.com>
Date: Tue, 12 May 2015 20:47:41 +0000
Message-ID: <CAAS2fgQZ9xNJ-Bz=k9ztHwqeOjjFbPsGAzReHmnUPYe0RYu+FA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed additional options for pruned
	nodes
Precedence: list

On Tue, May 12, 2015 at 8:10 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> True.  Part of the issue rests on the block sync horizon/cliff.  There is a
> value X which is the average number of blocks the 90th percentile of nodes
> need in order to sync.  It is sufficient for the [semi-]pruned nodes to keep
> X blocks, after which nodes must fall back to archive nodes for older data.


Prior discussion had things like "the definition of pruned means you
have and will serve at least the last 288 from your tip" (which is
what I put in the pruned service bip text); and another flag for "I
have at least the last 2016".  (2016 should be reevaluated-- it was
just a round number near where sipa's old data showed the fetch
probability flatlined.

But that data was old,  but what it showed that the probability of a
block being fetched vs depth looked like a exponential drop-off (I
think with a 50% at 3-ish days); plus a constant low probability.
Which is probably what we should have expected.

> There was even a more radical suggestion years ago - refuse to sync if too
> old (>2 weeks?), and force the user to download ancient data via torrent.

I'm not fond of this; it makes the system dependent on centralized
services (e.g. trackers and sources of torrents). A torrent also
cannot very efficiently handle fractional copies; cannot efficiently
grow over time. Bitcoin should be complete-- plus, many nodes already
have the data.