BIP Draft: BIP324 One-Byte Message Type ID Alias Assignment #2301

   0 | @@ -0,0 +1,129 @@
   1 | +```
   2 | +  BIP: TBD
   3 | +  Layer: Peer Services
   4 | +  Title: BIP324 One-Byte Message Type ID Alias Assignment
   5 | +  Authors: Anthony Towns <aj@erisian.com.au>
   6 | +  Status: Draft
   7 | +  Type: Standards Track

jonatack commented at 7:33 PM on September 24, 2026:

BIP 2 -> BIP 3

  Type: Specification

   0 | @@ -0,0 +1,129 @@
   1 | +```
   2 | +  BIP: TBD

jonatack commented at 7:34 PM on September 24, 2026:

BIP 3 nit

  BIP: ?

   6 | +  Status: Draft
   7 | +  Type: Standards Track
   8 | +  Assigned: TBD
   9 | +  License: BSD-2-Clause
  10 | +  Requires: 324, 434
  11 | +  Discussion: https://gnusha.org/pi/bitcoindev/aq9ADn7GscMHWc19@erisian.com.au/T/#u

jonatack commented at 7:35 PM on September 24, 2026:

Should be yyyy-mm-dd: URL format per BIP 3

  40 | +Support for this feature SHOULD NOT be advertised on connections that
  41 | +do not support one-byte message type IDs.
  42 | +
  43 | +### `set324alias` message
  44 | +
  45 | +The `set324alias` allows extending or modifying the set of aliases

jonatack commented at 7:37 PM on September 24, 2026:

The `set324alias` message allows extending or modifying the set of aliases

  77 | +any message that will only be sent at most once over the connection. Nodes
  78 | +SHOULD NOT define aliases for messages that already have an alias defined
  79 | +in [BIP-324][BIP324].
  80 | +
  81 | +Nodes SHOULD send `set324alias` only once per connection, and SHOULD send it
  82 | +as soon as possible (eg, immediately after receiving the `feature` message

jonatack commented at 7:42 PM on September 24, 2026:

Can the feature message be sent more than once (what happens then)?

ajtowns commented at 8:49 AM on October 1, 2026:

Nothing different to if it had been sent once?

  73 | +`aliases` vector.
  74 | +
  75 | +Nodes SHOULD define an alias for all messages that they expect to send
  76 | +multiple times over a connection. Nodes SHOULD NOT define an alias for
  77 | +any message that will only be sent at most once over the connection. Nodes
  78 | +SHOULD NOT define aliases for messages that already have an alias defined

jonatack commented at 7:45 PM on September 24, 2026:

What if a peer does it anyway? What takes precedence.

  89 | +to message mapping, so that future messages using the one-byte alias are
  90 | +correctly interpreted as if the 1-12 byte `msg_type` had been used instead.
  91 | +
  92 | +A node receiving a `set324alias` message MUST apply the new aliases
  93 | +immediately, as the very next message may make use of aliases declared
  94 | +in that message.

jonatack commented at 7:49 PM on September 24, 2026:

Should it be explicit that aliases apply only to messages from the peer that sent set324alias (the mapping is not symmetric).

  93 | +immediately, as the very next message may make use of aliases declared
  94 | +in that message.
  95 | +
  96 | +Nodes receiving a `set324alias` message MUST update the aliases in order
  97 | +(eg if `[1:foo, 2:bar, 1:baz]` is received, the one-byte message type
  98 | +`1` will be interpreted as `baz` thereafter).

jonatack commented at 7:53 PM on September 24, 2026:

"Nodes SHOULD send set324alias only once per connection" but this update in order example could maybe be interpreted to imply update messages are valid instead of order within the same payload vector. Maybe clarify to either allow multiple messages or MUST send at most one.

  64 | +
  65 | +Nodes MUST NOT send `set324alias` before sending `verack`. Nodes MUST
  66 | +NOT send `set324alias` to a peer that has not advertised support for
  67 | +the feature. Nodes MUST NOT send more than 255 elements in `aliases`,
  68 | +MUST NOT define an alias with `id=0`, and MUST NOT send a `msg_type`
  69 | +longer than 12 bytes.

jonatack commented at 7:58 PM on September 24, 2026:

longer than 12 bytes, nor of length 0.

 104 | +messages as an error. Nodes MAY treat a later message using that alias
 105 | +as an error if they would also have treated a message using `msg_type`
 106 | +it aliases as an error.
 107 | +
 108 | +A node receiving a `set324alias` message MUST continue to accept messages
 109 | +that use the 1-12 byte `msg_type` rather than the alias.

jonatack commented at 8:00 PM on September 24, 2026:

Can the sender mix alias and long-form after advertising aliases?

   0 | @@ -0,0 +1,129 @@
   1 | +```
   2 | +  BIP: TBD
   3 | +  Layer: Peer Services
   4 | +  Title: BIP324 One-Byte Message Type ID Alias Assignment
   5 | +  Authors: Anthony Towns <aj@erisian.com.au>
   6 | +  Status: Draft
   7 | +  Type: Standards Track
   8 | +  Assigned: TBD

jonatack commented at 8:02 PM on September 24, 2026:

  Assigned: ?