Author: Gregory Maxwell 2014-04-10 12:10:35
Published on: 2014-04-10T12:10:35+00:00
In a forum discussion, Wladimir proposed the idea of having a static node that only serves the first 100000 blocks or a range such as block 100000-200000. The topic was previously discussed, and data showed that nodes are often offline for extended periods, causing an increase in block fetching until about 2000 blocks deep. While a fixed range may be a useful contribution, it is challenging to identify why a node would not follow the consensus. Verifying is reasonably cheap with fast ecdsa code, and bandwidth is necessary for serving historic blocks. A lot of read-only storage could be a constraint that would prevent a node from following the consensus. It should be possible to use and express such a thing in the protocol, although it's unclear why one wouldn't keep the most recent 144 blocks around for reorgs and add the 100000-200000 range. In terms of peer selection, if the blocks needed aren't covered by the connected nodes, nodes with the least rareness in the ranges offered should be preferred. For example, if looking for block 50 from the tip, it is best not to fetch it from someone with blocks 100000-150000 if they are one of only 100 nodes with that range.
Updated on: 2023-05-19T18:38:55.960375+00:00