On Sun, Mar 01, 2026 at 10:06:20AM -0800, Antoine Riard wrote: > 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.
There's nothing stopping a peer from sending the same FEATURE message multiple times prior to sending a VERACK, or sending the a FEATURE message with the same featureid but different featuredata. However these aren't a DoS concern, because such messages are either expected to be ignored (if the featureid isn't recognised by the peer) or can be rejected as invalid (if the featureid is recognised but isn't in compliance with the feature's specification). Sending a bunch of FEATURE messages that are immediately ignored is no different from receiving a bunch of INV messages for txs you've already seen, or sending any other payload that you expect the peer to ignore. > 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...). A VERACK timeout is a pretty normal thing to have -- eg `-peertimeout` already exists and defaults to 60 seconds. It's not clever to waste a connection slot on a peer that's delaying ever getting into the part where you relay bitcoin information to each other. > I do see the idea with that it's indeed allowing some form of > interactive feature negotiation, In my opinion, interactive feature negotiation (of the form "I'll only tell you I support X if you first tell me you do/don't support Y") is massively overcomplicating things, and essentially an anti-pattern. > One last high level remark, I'm wondering if the protocol > versioning shouldn't be "frozen" in itself, There's no way to "freeze" development -- if BIP x says "you can't do Y", then doing Y just means you aren't implementing BIP x; you're not in any way inhibited from doing Y. > - the BIP is silent on unknown messages received before `version` > reception Messages received before `version` will generally already result in a disconnect, as that's how nodes recognise they're talking to another bitcoin node. Cheers, aj -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aa1oBi2SzQPOhhNy%40erisian.com.au.
