While some argued that allowing unknown messages in a protocol encourages protocol incompatibility and potential denial-of-service attacks, others believed that the exchange of otherwise-ignored messages for setting up optional features is a valid part of the version handshake and protocol negotiation.The conversation also touched on the fact that control messages apart from BIP151 are not sent until after the version is negotiated. It was noted that BIP151 negotiates encryption before any other communications, including the version handshake. The compatibility of feefilter BIP133 and sendheaders BIP130 with BIP151 was also discussed, with the consensus being that if these messages are received by a node below the version at which they are activated, they are considered unknown messages and indicate an invalid peer.There was debate regarding whether sending content that existing nodes do not expect constitutes an incompatibility. Some argued that this approach could leave the implementation vulnerable to DOS attacks, while others believed that it allows for a strict linear progression of allowed network protocol features. The importance of maintaining existing protocol behavior and soliciting community feedback before implementing changes that could break fundamental aspects of the P2P protocol handshake was emphasized.Overall, it was concluded that while the BIP151 proposal claims to be backward compatible, there are concerns regarding its compatibility and potential security implications. Further revisions and community feedback may be necessary before its implementation.