rich1.0npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rhttps://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rnjumphttps://nostr.ae📅 Original date posted:2014-04-10 📝 Original message: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 <laanwj at gmail.com> wrote: > On Thu, Apr 10, 2014 at 8:04 AM, Tamas Blummer <tamas at 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 at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >