[Bitcoin-development] Service bits for pruned nodes

Gregory Maxwell gmaxwell at gmail.com
Sun Apr 28 19:50:22 UTC 2013


On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn <mike at plan99.net> 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

X most recent is special for two reasons:  It meshes well with actual demand,
and the data is required for reorganization.

So whatever we do for historic data, N most recent should be treated
specially.

But I also agree that its important that <everything> be splittable into ranges
because otherwise when having to choose between serving historic data
and— say— 40 GB storage, a great many are going to choose not to serve
historic data... and so nodes may be willing to contribute 4-39 GB storage
to the network there will be no good way for them to do so and we may end
up with too few copies of the historic data available.

As can be seen in the graph, once you get past the most recent 4000
blocks the probability is fairly uniform... so "N most recent" is not a
good way to divide load for the older blocks. But simple ranges— perhaps
quantized to groups of 100 or 1000 blocks or something— would work fine.

This doesn't have to come in the first cut, however— and it needs new
addr messages in any case.




More information about the bitcoin-dev mailing list