From: Antoine Riard <antoine.riard@gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: [BIP Proposal] Peer Feature Negotiation
Date: Tue, 12 May 2026 01:49:31 +0100 [thread overview]
Message-ID: <CALZpt+FOrh4OEM7z3Fk5D3cNFONcUB_6ZYtiyXRMkPMUZq1VNQ@mail.gmail.com> (raw)
In-Reply-To: <aa1oBi2SzQPOhhNy@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 6517 bytes --]
Hi AJ,
Sorry for the late answer here.
> 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.
It's true that for INV messages we have already the MAX_INV_SZ limit.
Witht he current BIP text, there is limit laid out that `featuredata`'s
byte-vector must not be superior to 512 bytes. However, there is no
indication that declared `featureid` must be consistent with `featuredata`,
so I don't see why a peer couldn't iterate _multiple times_ over the
80^2 `feature_id` space to repeatedly attach 512 byte payload.
One if a peer can escalate one of your inbound slot (i.e win over
`ConsiderEviction`), and from then cloak your CPU processing with
dumb FEATURE message. Recommending some time-bounded processing
window for a fairly generous number of FEATURE would make sense.
I'm taking the caveat that it might be a bit early to add such
p2p limit, that it will add too much rigidity for a not even
experimentally deployed proposal (and "early optimization is
the rule of all evil").
> 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.
Right, may I note that your `-peertimeout` should make a distinction
between in-handshake (before VERACK) versus post-handshake. If you look
at bitcoind core, I'm not sure if `InactivityCheck` / `ReceivedMsgBytes`
make that distinction.
> 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.
Here I was thinking more about cryptographic schemes upgrade. Let's say
you have a p2p v3 encryption (or we wish to upgrade some cryptographic
primitive e.g the hash func in BIP330 for the short ids). Here, you
can see first if your peer supports the simple version, and then propose
the upgrade. This would allow to make smoother upgrade over the network.
> 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.
I believe we do have consensus fields reserved for future usage e.g not
using the taproot annex which is checked by its own policy rule. Of course,
it's policy only, there is difference between inhibition and encouragement
of good practice.
> Messages received before `version` will generally already result in a
> disconnect, as that's how nodes recognise they're talking to another
> bitcoin node.
Yeah, this proposal is still tightening the `version` message protocol
field bump with signaling support for BIP434. One way to disentangle would
be to version-feature the FEATURE message with a 1-byte field (which
for a 1-byte connection only doesn't seem a high bw cost).
Not sure if there is really a hard constraint to bump the protocol
version here and it wouldn't be more elegant to add an optional byte
in `version` message.
Best,
Antoine
OTS hash: 408e1c06080fa6b53c1ab076f9e881b5b1d9f971b984d12f9eaaf06bf5fb8d3c
Le dim. 8 mars 2026 à 12:14, Anthony Towns <aj@erisian.com.au> a écrit :
> 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALZpt%2BFOrh4OEM7z3Fk5D3cNFONcUB_6ZYtiyXRMkPMUZq1VNQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 7693 bytes --]
prev parent reply other threads:[~2026-05-12 0:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 9:13 [bitcoindev] [BIP Proposal] Peer Feature Negotiation Anthony Towns
2026-03-01 18:06 ` [bitcoindev] " Antoine Riard
2026-03-08 12:13 ` Anthony Towns
2026-05-12 0:49 ` Antoine Riard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALZpt+FOrh4OEM7z3Fk5D3cNFONcUB_6ZYtiyXRMkPMUZq1VNQ@mail.gmail.com \
--to=antoine.riard@gmail.com \
--cc=aj@erisian.com.au \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox