[BIP Proposal] Peer Feature Negotiation

[Anthony Towns]

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/

[4] https://gnusha.org/pi/bitcoindev/20200821023647....@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