* [bitcoindev] Re: [BIP Proposal] Peer Feature Negotiation
2025-12-19 9:13 [bitcoindev] [BIP Proposal] Peer Feature Negotiation Anthony Towns
@ 2026-03-01 18:06 ` Antoine Riard
0 siblings, 0 replies; 2+ messages in thread
From: Antoine Riard @ 2026-03-01 18:06 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 6050 bytes --]
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
Le Friday, December 19, 2025 à 11:35:52 AM UTC, Anthony Towns a écrit :
> Hello world,
>
> I've been thinking recently about a few ideas that would benefit
> from new p2p messages, namely template sharing [0], updating the
> bip324-one-byte-message-types [1], and sharing recent stale blocks [2].
> That's made me want to make sure that we've got a good way of negotiating
> new features, and revisiting the ideas from the 2020 thread [3] has me
> still liking the "FEATURE" message idea [4].
>
> As such, and with Ava's recent exhortation that everyone should be
> writing BIPs [5] in mind, I've written a BIP:
>
>
> https://github.com/ajtowns/bips/blob/202512-p2p-feature/bip-peer-feature-negotiation.md
>
> Sample code, though that part isn't really very interesting:
>
>
> https://github.com/ajtowns/bitcoin/commit/80301f0040fe6048a85b89d0fdf0ffcca836a1d0
>
> The BIP is perhaps a bit over-engineered at this point for what it does,
> but I figure better to be over-engineered than under-. And in any event,
> there was some degree of breakage with the SENDADDRV2's deployment [6,7]
> which would be good to avoid repeating. In any event, the BIP text has
> a bunch more background, etc.
>
> Comments welcome.
>
> Cheers,
> aj
>
> [0] https://github.com/bitcoin/bitcoin/issues/33691
>
> [1] https://github.com/bitcoin/bips/pull/1378#discussion_r2585766526
>
> [2] https://github.com/bitcoin-data/stale-blocks
> The idea behind sharing stale blocks (or headers) more proactively,
> is it better insight into the orphan rate, and whether hashrate
> is extending the chain vs potentially creating a reorg; and also
> potentially makes syncing to the new tip after a reorgs more
> efficient, as you'll have already downloaded the parent of the new tip
>
> [3]
> https://gnusha.org/pi/bitcoindev/CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jq...@mail.gmail.com/
> <https://gnusha.org/pi/bitcoindev/CAFp6fsE=HPFUMFhyuZkroBO_QJ-dUWNJqCPg9=fMJ3Jqnu1hnw@mail.gmail.com/>
>
> [4] https://gnusha.org/pi/bitcoindev/20200821023647....@erisian.com.au/
> <https://gnusha.org/pi/bitcoindev/20200821023647.7eat4goqqrtaqnna@erisian.com.au/>
>
> [5] https://x.com/btcplusplus/status/2000489894515253529
>
> [6] https://github.com/btcsuite/btcd/issues/1661
>
> [7] https://github.com/bitcoin/bitcoin/pull/20564
>
>
--
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/6783db94-fbbd-4df8-b05f-639fa3ace6f1n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 9812 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread