Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[Eric Voskuil <eric@voskuil.org>]

[-- Attachment #1: Type: text/plain, Size: 2929 bytes --]

A requirement to ignore unknown (invalid) messages is not only a protocol breaking change but poor protocol design. The purpose of version negotiation is to determine the set of valid messages. Changes to version negotiation itself are very problematic.

The only limitation presented by versioning is that the system is sequential. As such, clients that do not wish to implement (or operators who do not wish to enable) them are faced with a problem when wanting to support later features. This is resolvable by making such features optional at the new protocol level. This allows each client to limit its communication to the negotiated protocol, and allows ignoring of known but unsupported/disabled features.

Sorry I missed your earlier post. Been distracted for a while.

e


> On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 
> Hi,
> 
> Back in February I posted a proposal for WTXID-based transaction relay[1] (now known as BIP 339), which included a proposal for feature negotiation to take place prior to the VERACK message being received by each side.  In my email to this list, I had asked for feedback as to whether that proposal was problematic, and didn't 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, I thought it would be helpful to codify in a BIP the idea that Bitcoin network clients should ignore unknown messages received before a VERACK.  A draft of my proposal is available here[2].
> 
> I presume that software upgrading past protocol version 70016 was already planning to either implement BIP 339, or ignore the wtxidrelay message proposed in BIP 339 (if not, then this would create network split concerns in the future -- so I hope that someone would speak up if this were a problem).  When we propose future protocol upgrades that would benefit from feature negotiation at the time of connection, I think it would be nice to be able to use the same method as proposed in BIP 339, without even needing to bump the protocol version.  So having an understanding that this is the standard of how other network clients operate would be helpful.
> 
> If, on the other hand, this is problematic for some reason, I look forward to hearing that as well, so that we can be careful about how we deploy future p2p changes to avoid disruption.
> 
> Thanks,
> Suhas Daftuar
> 
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html
> 
> [2] https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 3868 bytes --]