Generalizing feature negotiation when new p2p connections are setup



Summary:

Bitcoin is no longer a homogeneous network of one client - it is many, with different features implemented in each. The Bitcoin protocol hasn't (fully) evolved to capture that reality. Initially, the Bitcoin protocol had a simple numerical version field, but that is wholly impractical for any diverse network. Bitcoin protocol changes have, many times in recent history, been made via new dummy "negotiation" messages, which take advantage of the fact that the Bitcoin protocol has always expected clients to ignore unknown messages. Suhas Daftuar proposed feature negotiation to take place prior to the VERACK message being received by each side. In his email to the bitcoin-dev list, he asked for feedback as to whether that proposal was problematic, and he did not receive any responses. Since then, the implementation of BIP 339 has been merged into Bitcoin Core, though it has not yet been released. In thinking about the mechanism used there, Suhas thought it would be helpful to codify in a BIP the idea that Bitcoin network clients should ignore unknown messages received before a VERACK. He proposes a draft of his proposal available here.Suhas believes that if software upgrading past protocol version 70016 was already planning to either implement BIP 339 or ignore the wtxidrelay message proposed in BIP 339, it would not create network split concerns in the future. When they propose future protocol upgrades that would benefit from feature negotiation at the time of connection, it would be nice to use the same method as proposed in BIP 339 without even needing to bump the protocol version. Suhas is looking forward to hearing whether this is problematic so that they can be careful about how they deploy future p2p changes to avoid disruption.


Updated on: 2023-05-20T23:44:08.716777+00:00