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. ------------------------------------------------------------------------------ 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
