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 <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. >
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. http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
