BIP 324, 434: Specify p2p v2 one-byte identifier for FEATURE message #2092

pull ajtowns wants to merge 3 commits into bitcoin:master from ajtowns:202601-feature-shortid changing 3 files +31 −3

ajtowns commented at 6:03 am on January 30, 2026: contributor

The feature message is intended to be used repeatedly prior to verack, so it should have a short id to save a little bandwidth, and the identifier has to be hardcoded, because it’s used before negotiation is completed.
ajtowns commented at 6:06 am on January 30, 2026: contributor

This assignment conflicts with utreexo’s usage of short ids 29-36 in #1923 (the uproof message in particular). I think those are in active use, so it may make more sense to add those assignments to bip 324 first?

cc @real-or-random @sipa @kcalvinalvin
real-or-random commented at 7:32 am on January 30, 2026: contributor

No opinions on the content.

One editorial or organizational question is whether the table should continue being maintained in BIP324. In principle, it suffices that every new BIP that introduces a message type specifies the corresponding one-byte identifier. But for coordination and accessibility, it’s certainly nice to have the full table materialized in a location where it can be found easily. I’m just not entirely sure that BIP324 is the best location for this. It also makes it a bit fuzzy on what document is authoritative, BIP324 or the other BIP?

What would be the alternative? I think, ideally, we’d have a separate (non-authoritative) document in the BIPs repo (similar to how the README lists all BIPs and their numbers) that has the full table of assignments from message type to short identifier. For each assignment, it would also refer to the BIP that defines this particular assignment. I’d be open to that idea if someone wants to implement it. But otherwise, I guess maintaining it as part of BIP324 is also good enough for now?

ajtowns commented at 7:55 am on January 30, 2026: contributor

I think it’s good to have a single “source of knowledge” to go to to help avoid conflicts. That doesn’t need to be treated as “authoritative” though, and maybe it’s confusing to combine all the authoritative parts of bip 324 (here’s how you encrypt/decrypt, etc), with a non-authoritative list?

An easy option might be to move new assignments to outside of the bip 324 text itself, and into say bip-0324/message_types.md or similar. Could have the table there allow for duplicate entries (so it’s just for helping people coordinate and avoid conflicts, rather than trying to be authoritative about who wins when there are conflicts), something like:

id	message	allocating bip
29	feature	BIP 434 / PR#2092
29	uproof	BIP 183 / PR#1923

Could have separate tables for: (1) BIPs in Complete/Deployed state; (2) BIPs in draft state, BIPs that are just PRs, non BIPs; (3) BIPs that are Closed, perhaps.

Happy to change this PR to an approach along those lines if it’s appealing.

real-or-random commented at 8:24 am on January 30, 2026: contributor

This all sounds reasonable to me. This gives us most of the advantages of a separate document right now, while keeping this under the umbrella of BIP324 for now avoids this being blocked on a debate on who should be in control or in charge of this new document. Namely, as long as the new document lives in the aux files of BIP324, then the BIP324 authors “own” it. I am not convinced that’s the perfect solution, but it’s the status quo anyway, so I’m okay with it.
sipa commented at 1:16 pm on January 30, 2026: member

I would also be ok with a list inside the BIP itself that says “Here is a list of message_ids whose mapping is proposed by other BIPs. This is informational and for reference only. Implementing these is not required for compliance with BIP324, but may be required for compliance with the listed BIPs (if desired).”.
ajtowns force-pushed on Jan 31, 2026
BIP 324: Add auxiliary file tracking assignments of one-byte message type IDs a3370b5c9d
BIP324, BIP183: Add utreexo's p2pv2 message type ids df1f098a8b
ajtowns force-pushed on Jan 31, 2026
BIP324, BIP434: Assign message type id for "feature" message a50c0ea32b
ajtowns force-pushed on Jan 31, 2026
ajtowns commented at 8:01 am on January 31, 2026: contributor
Updated with a separate file containing the table:
- BIP 324
- Message Type IDs table
Also added all the proposed utreexo assignments, and moved feature to not conflict.
sipa commented at 2:14 pm on January 31, 2026: member

ACK as far as 324 is concerned.
murchandamus commented at 0:20 am on February 3, 2026: contributor

This looks great to me. I can’t imagine the Utreexo authors being upset that someone carefully read their proposal and transcribed the mentioned message to the table, but I’ll post there after merging this.
murchandamus added the label Proposed BIP modification on Feb 3, 2026
murchandamus added the label BIP update by author on Feb 3, 2026
murchandamus merged this on Feb 3, 2026
murchandamus closed this on Feb 3, 2026

Contributors
ajtowns real-or-random sipa murchandamus

Labels
Proposed BIP modification BIP update by author