Generalizing feature negotiation when new p2p connections are setup



Summary:

Bitcoin protocol has implemented version negotiation, which is the opposite of expecting clients to ignore unknown messages. Clients not validating the protocol does not mean it is an expectation that the protocol should not be validated. Optional features can exist within a protocol, and post-handshake negotiations have been implemented for optional messages that are valid at negotiated versions. The protocol can remain flexible while being validated, and there is no reason to force a client to accept unknown message traffic. A generalized versioning change can be implemented in or after the handshake, and there is no need to complicate negotiations with additional messages. In recent history, Bitcoin protocol changes have been made via new dummy "negotiation" messages, but now it makes sense to have an explicit negotiation phase after the version and before verack by sending the list of features that the connection supports to negotiate what the connection will be capable of. This pattern captures the essence of network upgrades, keeping consistency.


Updated on: 2023-06-14T15:07:12.959323+00:00