Published on: 2013-06-20T10:58:31+00:00
During a discussion on the Bitcoin-development mailing list, developers debated whether or not to increase the version number in the Bitcoin protocol. Pieter Wuille argued in favor of increasing the version number, stating that it would simplify things and be easy to implement. However, Turkey Breast disagreed, pointing out that this change would cause previous behavior to be lost and suggested that optional fields should have their own mechanism to remain optional between protocol version upgrades. Mike Hearn chimed in, stating that there was no immediate benefit to increasing the version number, but acknowledged that it may become necessary in the future if new optional fields are added to different messages.The debate centered around parsing the version message in the Bitcoin protocol. Some developers argued that the version should indicate which fields are present to simplify parsing, while others believed that keeping the number of fields flexible allowed for future changes without causing any issues. However, concerns were raised about relying on quirks and assumptions in the code, with suggestions that optional fields should have separate mechanisms to remain optional between protocol version upgrades. There were also discussions about truncated messages and handling them, as well as penalizing hosts that broadcast older version messages without all the required fields.Despite the disagreements, many developers agreed that changing the protocol version number from 70001 to 70002 would not be a significant problem and would not run the risk of running out of integers. It was ultimately decided to keep the number of fields in a message as a little version number, allowing for flexibility and costing nothing.In another email exchange, Mike Hearn questioned the need for a new version field unless there was an actual new feature to add. He also noted that the Bitcoin protocol did not require messages to have a fixed number of fields per version. Pieter Wuille disagreed, arguing that the version in the version message itself should indicate which fields are present to simplify parsing. They discussed raising the protocol version number to indicate that certain fields were required above a certain version number. It was mentioned that previous additions to the version message had been accompanied by a protocol/client version increase.In a separate discussion, Tamas Blummer and Mike Hearn discussed the complexity of the Bitcoin system and whether or not to address low-complexity issues. They specifically addressed an optional field in the version message and its complexity compared to other aspects of the system. While Mike argued that this issue was trivial and hardly worth thinking about, Tamas believed that eliminating complexity would strengthen the system. They discussed the backward compatibility of the issue and suggested bumping the version and parsing fields as mandatory going forward to maintain cleanliness.Another email exchange between Tamas Blummer and Mike Hearn focused on the variable number of fields in the version message in the Bitcoin protocol. Tamas suggested bumping the version and parsing certain fields as mandatory to eliminate unnecessary complexity. Mike questioned why this change should be made now instead of waiting for an actual new field to add. He also pointed out that any parser written with the assumption of a fixed number of fields per version would be buggy. The discussion also touched on the preservation of fields from the future in old versions.Overall, the discussions highlighted differing opinions on increasing the version number in the Bitcoin protocol and the benefits and drawbacks of doing so. Some developers argued for simplifying parsing by indicating which fields are present in the version message, while others believed that flexibility in the number of fields allowed for future changes without causing issues. The idea of penalizing hosts broadcasting older version messages without all the required fields was also brought up. Ultimately, it was decided to keep the number of fields flexible and maintain backward compatibility.
Updated on: 2023-08-01T05:11:18.713084+00:00