Author: David A. Harding 2020-08-20 14:13:39
Published on: 2020-08-20T14:13:39+00:00
In a Bitcoin-dev forum, Eric Voskuil raised concerns over ignoring unknown (invalid) messages in the proposed BIP as it could lead to a protocol breaking change. However, others argue that the proposed requirement is limited to ignoring unknown messages during peer negotiation, and this will only occur if a node signals support for version >=70016. To promote backward compatibility in future upgrades, the BIP could state that nodes implementing the proposal should not send new negotiation message types to nodes whose protocol version is less than 70017. Ignoring unknown messages may be viewed as poor protocol design since the purpose of version negotiation is to determine the set of valid messages. Nonetheless, the proposed requirement is limited in scope to the brief negotiation phase between `version` and `verack`, leaving room for nodes to terminate connections or take other actions when they receive an unknown message at any other time. Changes to version negotiation itself can pose challenges, especially when wanting to support later features. However, making such features optional at the new protocol level can allow each client to limit its communication to the negotiated protocol while ignoring known but unsupported/disabled features. Despite these concerns, some people want to run long-term experiments for new protocol features using open source opt-in codebases. They believe that having a flexible and lightweight feature negotiation system like the proposed method would be advantageous. Nonetheless, there are still challenges in negotiating a set of two or more optional features using only the exchange of single numbers. Overall, the proposed BIP and the negotiation method it describes have received positive feedback.
Updated on: 2023-06-14T15:05:59.810161+00:00