It probably should be stated in terms of what you're promising to do-- 288 and 1152 blocks, not what we hope it will accomplish. Then advise clients to use peers with headroom because their estimates could be wrong and reorgs.
Reorgs aren't the only concerns that drive larger numbers: The peak at syncing is at ~24 hours, but sometimes there are quite a few more than 144 blocks in 24 hours. Also, new blocks show up in the chain: you think you're 144 behind but by the time you connect you find you're 146 behind from that peer's perspective. I think it's a bit ambiguous what it's saying about the headers, especially because it goes into detail about address relay. I believe nodes with any of these settings should be willing to serve headers for their entire best chain. Perhaps you could say that this is equivalent to NODE_NETWORK except that they aren't necessarily willing to server historical blocks. I'm unsure about the third depth level. Perhaps that should be left undefined for sending right now and treated as least 1152 blocks by receivers-- I don't have any reason to think 7056 is a particularly useful choice, and we'll need another (longer) level for UTXO based sync. You could probably go further and say that nodes shouldn't send it now, but if sent it means they intend to keep 2016*2 blocks. (Not sending because the requirement for sending it may be that the node is able to send you a UTXO data feed.) > consider to switch a low percentage That isn't grammatical, you want "switching". But I think it would be better to say that when a node believe it is in sync enough to use NODE_NETWORK_LIMITED_X it should just treat them identically to NODE_NETWORK in peer selection. We don't really need any more topology distortion than that. In particular, I don't want to be in a case where NODE_NETWORK peers suddenly find themselves far less well connected. In terms of making room, a node network peer could choose to disconnect the least useful peers that aren't syncing from them to make more room for ones that are. This lets them decide what connections they want, based on how full they are and what is useful to them, rather than finding themselves all lonely because nodes decided to avoid them to be "helpful", and we already use disconnections to manage fullness. On Thu, May 11, 2017 at 3:13 PM, Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi > > Currently, pruned peers have no way how to signal their (valuable) service. > A BIP proposal to improve this (draft): > https://github.com/jonasschnelli/bips/wiki/NODE_NETWORK_LIMITED-BIP-DRAFT > > Feedback is highly welcome. > > </jonas> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
