Allow to signal both bits and treat them independently

[jonasschnelli]

The current BIP couples the two NODE_NETWORK_LIMITED_* bits by setting the state as undefined when signaling both bits. Ideally we can treat them independently which means signalling NODE_NETWORK_LIMITED_HIGH will always require to signal NODE_NETWORK_LIMITED_LOW as well.
The downside for this simplification is that we loose the possible third state (both bits set).

[clarkmoody]

Would we need another BIP later to define the third state if it is left as undefined for the time being (and adopted by node software)?

Alternatively, can we come up with a more compelling meaning for both bits?

[jonasschnelli]

@clarkmoody: I guess it's reasonable to not confuse developers by connecting bit states (== treat each bit individual) which result in only two states for two bits.

Adding a third state would require another bit used. And right now, there is no need for a third state and we don't know if we ever need a third block depth level for limited historical block serving.

Changing the block values (currently 288 and 1152) is possible depending on the client protocol version.

[sipa]

One issue is that network nodes will OR service bits together, so if you at one point offer one of the bits, and at another time the other, nodes may combine them into setting both.

I think this means we can only have 4 combinations with 3 bits:

• NETWORK: full nodes with full history
• !NETWORK, LIMITED_HIGH: full nodes with a week of history
• !NETWORK, !LIMITED_HIGH, LIMITED_LOW: full nodes with a day of history
• !NETWORK, !LIMITED_HIGH, !LIMITED_LOW: SPV nodes, etc

[clarkmoody]

@sipa It sounds like there is no reason to activate both HIGH and LOW bits, since connecting nodes will go with the best-case history.

@jonasschnelli ACK to your proposed change

[luke-jr]

I dislike wasting service bits like this, but I didn't realise nodes would OR them on their own. :(