Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits

[Luke Dashjr <luke@dashjr.org>]

> A peer signaling NODE_NETWORK_LIMITED_LOW & NODE_NETWORK_LIMITED_HIGH MUST
> be capable of serving at least the last 7'056 blocks (~49 days)
> (NODE_NETWORK_LIMITED_HIGH's value ^2).

Is 49 days particularly useful? Would it be a problem to instead leave both-
bits undefined? I'm thinking this might be better as a way to indicate "7 
days, plus a deterministically chosen set of historical blocks"...

> Current Bitcoin-Core pruned full nodes guarantees a minimum of 288 blocks,
> thus allowing to signal NODE_NETWORK_LIMITED_LOW with the current minimum
> configuration.

This is technically true right now, but as soon as segwit activates, it will 
no longer be... Therefore, I suggest striking it from the BIP, expounding on 
it in greater detail, or making it true for the longer term.

> Peers following this BIP SHOULD connect a limited amount of their available
> outbound connections to peers signaling one or both of the
> NODE_NETWORK_LIMITED_* service bits if they expect to request less blocks
> than the signaled number.

This isn't entirely clear whether it refers to peers downloading blocks, or 
peers serving them. (I assume the former, but it should be clarified.)

> Light clients (and such) who are not checking the nServiceFlags (service
> bits) from a relayed addr-message may unwillingly connect to a pruned peer
> and ask for (filtered) blocks at a depth below their pruned depth.

Wouldn't this already be a problem, without the BIP?

Luke