Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2014-04-10 📝 Original message:There were earlier ...
📅 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
>
📝 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
>