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

[ajtowns]

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]

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]

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]

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]

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]

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]

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.