On Tue, May 12, 2015 at 8:10 PM, Jeff Garzik <jgar...@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. ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
