Manage witness_node service bit for non-witness. #988
Description
The current implementation provides for minimum and maximum service flag configuration. Minimum is what we require and maximum is what we provide. This is similar to protocol version negotiation and occurs both within address selection and p2p handshake.
- A witness maximum (8) implies the node has witness data, as this is what is advertised.
- A witness minimum (8) implies the node requires witness peers.
Currently if max is set and min is not then peers may connect and request witness block/tx data [bug - provide keys off of min].
Currently if min is set then peers may provide witness block/tx data (of any) and the node stores it. Validation is independently controlled by fork flags. If max is not set then peers may not request it [bug - provide keys off of min].
When max is set it implies the node must obtain and store witness block/tx data, but the handshake and address filtering keys off of min. This aspect should be conditional in protocol attachment, so that if both are set then peer (8) is required, but if min is not set then peer (8) is not required, but with max set then block/tx in protocols are not attached to such peers. Out protocols should work in either case (as long as the witness data is stored).
This complexity arises from the requirement that we support both witness and non-witness nodes in an environment where callers can also be either. Most nodes are simply all witness (or old and all non-witness).