peer selection logic too restrictive

[rebroad]

#9051 is one example of a current issue due to SegWit features apparently starting too early. Until SegWit is voted in (at 95% of the mining vote), I would expect that there should not be any rejecting of non-SegWit nodes, such as preferential peering or rejection of standard blocks - both of which seem to have already started happening with recent releases of Bitcoin Core.

What does the function IsWitnessEnabled() mean, for example? I would have thought this means that the 95% mining vote has been reached, but according to recent news articles this hasn't happened yet, so why is this function returning true?

[laanwj]

On mainnet: no. On testnet: yes.

Preferential peering already happens in preparation for the activation, though. When segwit activates it'd be too late to do so.

[rebroad]

@laanwj Thanks for the clarification. Would you be willing to elaborate on why it would be too late to do so at activation?

Perhaps I could elaborate on my reason for my question - it seems unnecessary that before activation 0.13.1 nodes are being relied upon so much - for sure, nodes need to be ready to be selective once activation occurs, but this doesn't mean that they need to be selective now. For example, why not let them continue downloading blocks from pre-0.13.1 nodes? As long as they have a connection to some 0.13.1 nodes, they are ready to be selective.

[sipa]

@rebroad https://bitcoin.stackexchange.com and I'll answer there.

[rebroad]

@sipa https://bitcoin.stackexchange.com/questions/49452