Re: [Bitcoin-development] Why are we bleeding nodes?

[Tamas Blummer <tamas@bitsofproof.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1477 bytes --]

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
http://bitsofproof.com

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

> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <tamas@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 #1.2: Type: text/html, Size: 3515 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]