There were earlier discussions. The two ideas were either using one or a few service bits to indicate availability of blocks, or to extend addr messages with some flags to indicate this information.
I wonder whether we can't have a hybrid: bits to indicate general degree of availability of blocks (none, only recent, everything), but indicate actual availability only upon actually connecting (through a "version" extension, or - preferably - a separate message). Reason is that the actual blocks available are likely to change frequently (if you keep the last week of blocks, a 3-day old addr entry will have quite outdated information), and not that important to actual peer selection - only to drive the decision which blocks to ask after connection. On Thu, Apr 10, 2014 at 1:09 PM, Wladimir <laa...@gmail.com> wrote: > On Thu, Apr 10, 2014 at 8:04 AM, Tamas Blummer <ta...@bitsofproof.com> > wrote: >> >> Serving headers should be default but storing and serving full blocks >> configurable to ranges, so people can tailor to their bandwith and space >> available. > > > I do agree that it is important. > > This does require changes to the P2P protocol, as currently there is no way > for a node to signal that they store only part of the block chain. Also, > clients will have to be modified to take this into account. Right now they > are under the assumption that every full node can send them every (previous) > block. > > What would this involve? > > Do you know of any previous work towards this? > > Wladimir > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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