Once a single transaction in pruned in a block, the block is no longer eligible 
to be served to other nodes. 
Which transactions are pruned can be rather custom e.g. even depending on the 
wallet(s) of the node,
therefore I guess it is more handy to return some bitmap of pruned/full blocks 
than ranges.

Tamas Blummer

On 07.04.2014, at 20:49, Gregory Maxwell <gmaxw...@gmail.com> wrote:

> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <ta...@bitsofproof.com> wrote:
>> BTW, did we already agree on the service bits for an archive node?
> I'm still very concerned that a binary archive bit will cause extreme
> load hot-spotting and the kind of binary "Use lots of resources YES or
> NO" I think we're currently suffering some from, but at that point
> enshrined in the protocol.
> It would be much better to extend the addr messages so that nodes can
> indicate a range or two of blocks that they're serving, so that all
> nodes can contribute fractionally according to their means. E.g. if
> you want to offer up 8 GB of distributed storage and contribute to the
> availability of the blockchain,  without having to swollow the whole
> 20, 30, 40 ... gigabyte pill.
> Already we need that kind of distributed storage for the most recent
> blocks to prevent extreme bandwidth load on archives, so extending it
> to arbitrary ranges is only more complicated because there is
> currently no room to signal it.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
Bitcoin-development mailing list

Reply via email to