Hello AJ, I had finally a read on your BIP434 proposal, and here few thoughts on the design and the novel processing rules proposed. I'm thinking that one drawback with the multiple feature / signaling messages approach compared to the fixed-size length verack payload comes with the novel feature messages becoming a novel if not a least a vector of denial-of-service, at least some vector of annoyance. One peer can always throw a number of `feature` message only bounded by the 80^2 information space of the `featureid` string length. If if I'm understanding correctly your proposal, this would be an acceptable valid behavior and this raises the question, if incidentally peers do not have to agree on dos-limit even for feature negotiation, that is moving us away from the "permissionlessly goal" you're laying out. I don't think there is an easy or obvious answer to this issue, other than introducing a verack negotiation timeout (with all the frictions of the lack of an easy to use coordinated clock among peers...). I do see the idea with that it's indeed allowing some form of interactive feature negotiation, where one peer can always make the announcement of feature_XYZ conditional on the previous announcement of feature_ABC, which is also possible with verack payload by reconnecting / disconnecting. I don't think we should consider connect / reconnect as free, as even if you're a peer doing legit interactive feature negotiation there might be friction with the underlying socket eviction logic (i.e for bitcoin core `SelectNodeToEvict()`). This is unclear from the "Considerations" of your proposal if it's taking the position that interactive feature negotation is either a valuable or not mechanism to have at the p2p protocol-level. Personally, I'm thinking it's interesting to have as it would enable deployment of complex feature tier by tier where you're using the messages of feature_ABC as direct messages in the flow of feature_XYZ, and it does bring some flexibility in the network deployment of said features. One last high level remark, I'm wondering if the protocol versioning shouldn't be "frozen" in itself, and reserved solely for signaling changes in the "peer feature negotiation" mechanism (or the usage of the service bits ?). More low level remarks on some BIP proposed processing rules in itself: - the BIP is silent on unknown messages received before `version` reception - same if a recipient MAY disconnect a peer if unsupported messages received post-verack - imho would be better to canonically define namespace section "...be a globally unique id..." - the re-interpretation of BIP324 messages as `feature` sounds gross, already the service bit While the proposal might appear as over-engineered, I don't think otherwise, though it would won to laid out better the design trade-off compared to verack in the "Considerations" section, and potentially to define more if the service bit can be indifferently use to signal feature, without going through the explicit feature negotiation mechanism. If I have misunderstood some aspect of your BIP proposal, please let me know. Best, Antoine OTS hash: 2a9215d42ee79a30ccc31b3410f74ab486d99f99408ad705b244d0dd8822ce53