mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-01-18 21:32:31 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 1: Define custom message type range

Browse Source
This commit is contained in:
Bastien Teinturier 2019-11-21 11:00:33 +01:00 committed by Christian Decker
parent c3a8e5e1a7
commit caca4375e6
1 changed files with 10 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
01-messaging.md
View File

@ -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.
@ -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
@ -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