Skip to content
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

Advertize compression algorithms support in init (features 32/33) #825

Closed
wants to merge 1 commit into from
Closed

Advertize compression algorithms support in init (features 32/33) #825

Show file tree
Hide file tree
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
22 changes: 21 additions & 1 deletion 01-messaging.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -264,10 +264,20 @@ The `features` field MUST be padded to bytes with 0s.
1. type: 1 (`networks`)
2. data:
* [`...*chain_hash`:`chains`]

1. type: 3 (`compression_algorithms`)
2. data:
* [`...*byte`:`supported_algorithms`]

The optional `networks` indicates the chains the node is interested in.

The optional `compression_algorithms` is a bitfield indicating what compression
algorithms the node supports for [gossip queries](07-routing-gossip.md#query-messages).

| Bit Position | Algorithm |
| ------------- | ---------------------------------------------------- |
| 0 | Uncompressed |
| 1 | [zlib_deflate](https://www.ietf.org/rfc/rfc1950.txt) |

#### Requirements

The sending node:
Expand All @@ -277,6 +287,8 @@ The sending node:
- SHOULD NOT set features greater than 13 in `globalfeatures`.
- SHOULD use the minimum length required to represent the `features` field.
- SHOULD set `networks` to all chains it will gossip or open channels for.
- if it sets the `option_compression` feature bit:
- MUST set the `compression_algorithms` field

The receiving node:
- MUST wait to receive `init` before sending any other messages.
Expand All @@ -290,6 +302,9 @@ The receiving node:
- MAY fail the connection.
- if the feature vector does not set all known, transitive dependencies:
- MUST fail the connection.
- if it has no `compression_algorithms` in common with the sending node:
- MUST NOT exchange messages that require compression (e.g. gossip queries).
- MAY fail the connection.
t-bast marked this conversation as resolved.
Show resolved Hide resolved

#### Rationale

Expand Down Expand Up @@ -459,6 +474,7 @@ multi-byte values with big-endian.
Values encoded with BigSize will produce an encoding of either 1, 3, 5, or 9
bytes depending on the size of the integer. The encoding is a piece-wise
function that takes a `uint64` value `x` and produces:

```
uint8(x) if x < 0xfd
0xfd + be16(uint16(x)) if x < 0x10000
Expand All @@ -477,6 +493,7 @@ decoded with BigSize should be checked to ensure they are minimally encoded.
### BigSize Decoding Tests

The following is an example of how to execute the BigSize decoding tests.

```golang
func testReadBigSize(t *testing.T, test bigSizeTest) {
var buf [8]byte
Expand All @@ -499,6 +516,7 @@ func testReadBigSize(t *testing.T, test bigSizeTest) {
```

A correct implementation should pass against these test vectors:

```json
[
{
Expand Down Expand Up @@ -607,6 +625,7 @@ A correct implementation should pass against these test vectors:
### BigSize Encoding Tests

The following is an example of how to execute the BigSize encoding tests.

```golang
func testWriteBigSize(t *testing.T, test bigSizeTest) {
var (
Expand All @@ -627,6 +646,7 @@ func testWriteBigSize(t *testing.T, test bigSizeTest) {
```

A correct implementation should pass against the following test vectors:

```json
[
{
Expand Down
6 changes: 5 additions & 1 deletion 07-routing-gossip.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -565,9 +565,12 @@ request what gossip should be received.
There are several messages which contain a long array of
`short_channel_id`s (called `encoded_short_ids`) so we utilize a
simple compression scheme: the first byte indicates the encoding, the
rest contains the data.
rest contains the data. The compression algorithms supported by each
node are advertised in the `init` message's `compression_algorithms`
tlv field.

Encoding types:

* `0`: uncompressed array of `short_channel_id` types, in ascending order.
* `1`: array of `short_channel_id` types, in ascending order, compressed with zlib deflate<sup>[1](#reference-1)</sup>

Expand Down Expand Up @@ -633,6 +636,7 @@ The sender:
- MUST set `chain_hash` to the 32-byte hash that uniquely identifies the chain
that the `short_channel_id`s refer to.
- MUST set the first byte of `encoded_short_ids` to the encoding type.
- MUST NOT use an encoding not supported by the remote peer.
t-bast marked this conversation as resolved.
Show resolved Hide resolved
- MUST encode a whole number of `short_channel_id`s to `encoded_short_ids`
- MAY send this if it receives a `channel_update` for a
`short_channel_id` for which it has no `channel_announcement`.
Expand Down
21 changes: 12 additions & 9 deletions 09-features.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,7 @@ for use of the channel, so the presentation of those features depends
on the feature itself.

The Context column decodes as follows:

* `I`: presented in the `init` message.
* `N`: presented in the `node_announcement` messages
* `C`: presented in the `channel_announcement` message.
Expand All @@ -41,6 +42,7 @@ The Context column decodes as follows:
| 20/21 | `option_anchor_outputs` | Anchor outputs | IN | `option_static_remotekey` | [BOLT #3](03-transactions.md) |
| 22/23 | `option_anchors_zero_fee_htlc_tx` | Anchor commitment type with zero fee HTLC transactions | IN | | [BOLT #3][bolt03-htlc-tx], [lightning-dev][ml-sighash-single-harmful]|
| 26/27 | `option_shutdown_anysegwit` | Future segwit versions allowed in `shutdown` | IN | | [BOLT #2][bolt02-shutdown] |
| 32/33 | `option_compression` | Compression algorithms advertised in `init` | IN | | [BOLT #1](01-messaging.md#the-init-message) |
| 44/45 | `option_channel_type` | Node supports the `channel_type` field in open/accept | IN | | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |

## Definitions
Expand All @@ -50,15 +52,16 @@ We define `option_anchors` as `option_anchor_outputs || option_anchors_zero_fee_
## Requirements

The origin node:
* If it supports a feature above, SHOULD set the corresponding odd
bit in all feature fields indicated by the Context column unless
indicated that it must set the even feature bit instead.
* If it requires a feature above, MUST set the corresponding even
feature bit in all feature fields indicated by the Context column,
unless indicated that it must set the odd feature bit instead.
* MUST NOT set feature bits it does not support.
* MUST NOT set feature bits in fields not specified by the table above.
* MUST set all transitive feature dependencies.

* If it supports a feature above, SHOULD set the corresponding odd
bit in all feature fields indicated by the Context column unless
indicated that it must set the even feature bit instead.
* If it requires a feature above, MUST set the corresponding even
feature bit in all feature fields indicated by the Context column,
unless indicated that it must set the odd feature bit instead.
* MUST NOT set feature bits it does not support.
* MUST NOT set feature bits in fields not specified by the table above.
* MUST set all transitive feature dependencies.

The requirements for receiving specific bits are defined in the linked sections in the table above.
The requirements for feature bits that are not defined
Expand Down