Author: Eric Voskuil 2020-08-18 18:56:13
Published on: 2020-08-18T18:56:13+00:00
In a discussion about backward compatibility, the question of what constitutes the existing Bitcoin protocol is raised. While there is confusion over this, it is noted that the protocol does not require a peer to accept arbitrary messages. The discussion then turns to the need for negotiation to allow different software to negotiate different features without a global lock-step version number increase. While some argue for a single message that lists the set of features which a node wishes to support on the connection, others propose extending the verack with a matrix of feature support. There is agreement that the current method of protocol version bumping isn't scalable and something more flexible is needed. However, there is debate over whether a single message or multiple messages are preferable for feature negotiation. It is proposed that a simpler system can be created by eliminating extra messages and using the existing numeric version to signal an extension to the verack, which can then carry a list of optional sub-protocols for final negotiation. The format of the matrix is discussed, with some suggesting using hashes instead of human-readable names to avoid collisions. However, it is noted that human-readable names have shown to be relatively non-colliding in past Bitcoin protocol changes. Overall, the goal is to reduce communication complexity and allow peers to lock in allowed message semantics by the end of the handshake.
Updated on: 2023-06-14T15:07:02.428064+00:00