Skip to content

BOLT 1: Define custom message type range #705

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
cdecker merged 1 commit into from
Jan 21, 2020
Merged

BOLT 1: Define custom message type range #705

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions 01-messaging.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -51,12 +51,13 @@ A receiving node:
- upon receiving a message of _even_, unknown type:
- MUST fail the channels.

The messages are grouped logically into four groups, ordered by the most significant bit that is set:
The messages are grouped logically into five groups, ordered by the most significant bit that is set:

- Setup & Control (types `0`-`31`): messages related to connection setup, control, supported features, and error reporting (described below)
- Channel (types `32`-`127`): messages used to setup and tear down micropayment channels (described in [BOLT #2](02-peer-protocol.md))
- Commitment (types `128`-`255`): messages related to updating the current commitment transaction, which includes adding, revoking, and settling HTLCs as well as updating fees and exchanging signatures (described in [BOLT #2](02-peer-protocol.md))
- Routing (types `256`-`511`): messages containing node and channel announcements, as well as any active route exploration (described in [BOLT #7](07-routing-gossip.md))
- Custom (types `32768`-`65535`): experimental and application-specific messages

The size of the message is required by the transport layer to fit into a 2-byte unsigned int; therefore, the maximum possible size is 65535 bytes.

Expand All @@ -66,6 +67,13 @@ A node:
- MUST fail the channels.
- that negotiates an option in this specification:
- MUST include all the fields annotated with that option.
- When defining custom messages:
- SHOULD pick a random `type` to avoid collision with other custom types.
- SHOULD pick a `type` that doesn't conflict with other experiments listed in [this issue](https://github.com/lightningnetwork/lightning-rfc/issues/716).
- SHOULD pick an odd `type` identifiers when regular nodes should ignore the
additional data.
- SHOULD pick an even `type` identifiers when regular nodes should reject
the message and close the connection.

### Rationale

Expand Down Expand Up @@ -100,7 +108,7 @@ A `tlv_record` represents a single field, encoded in the form:
A `varint` is a variable-length, unsigned integer encoding using the
[BigSize](#appendix-a-bigsize-test-vectors) format, which resembles the bitcoin
CompactSize encoding but uses big-endian for multi-byte values rather than
little-endian.
little-endian.

A `tlv_stream` is a series of (possibly zero) `tlv_record`s, represented as the
concatenation of the encoded `tlv_record`s. When used to extend existing
Expand Down