Advertize known compression algorithms

Add a tlv field in `init` to list supported compression algorithms. This compression will be used in several places, currently in extended gossip queries. Fixes #811
lightning · Jan 5, 2021 · c4322b7 · c4322b7
1 parent a00418f
commit c4322b7
Show file tree

Hide file tree

Showing 3 changed files with 51 additions and 25 deletions.
diff --git a/01-messaging.md b/01-messaging.md
@@ -258,10 +258,19 @@ 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             | [zlib_deflate](https://www.ietf.org/rfc/rfc1950.txt) |
+
 #### Requirements
 
 The sending node:
@@ -271,6 +280,11 @@ 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:
+    - if it does not support any compression algorithm:
+      - SHOULD omit the `compression_algorithms` field
+    - otherwise:
+      - MUST set the `compression_algorithms` field
 
 The receiving node:
   - MUST wait to receive `init` before sending any other messages.
@@ -453,6 +467,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
@@ -471,6 +486,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 
@@ -493,6 +509,7 @@ func testReadBigSize(t *testing.T, test bigSizeTest) {
 ```
 
 A correct implementation should pass against these test vectors:
+
 ```json
 [
     {
@@ -601,6 +618,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 (
@@ -621,6 +639,7 @@ func testWriteBigSize(t *testing.T, test bigSizeTest) {
 ```
 
 A correct implementation should pass against the following test vectors:
+
 ```json
 [
     {

diff --git a/07-routing-gossip.md b/07-routing-gossip.md
@@ -568,9 +568,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>
 
@@ -636,6 +639,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.
   - 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`.

diff --git a/09-features.md b/09-features.md
@@ -19,40 +19,43 @@ 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.
 * `C-`: presented in the `channel_announcement` message, but always odd (optional).
 * `C+`: presented in the `channel_announcement` message, but always even (required).
 * `9`: presented in [BOLT 11](11-payment-encoding.md) invoices.
 
-| Bits  | Name                             | Description                                               | Context  | Dependencies      | Link                                  |
-|-------|----------------------------------|-----------------------------------------------------------|----------|-------------------|---------------------------------------|
-| 0/1   | `option_data_loss_protect`       | Requires or supports extra `channel_reestablish` fields   | IN       |                   | [BOLT #2][bolt02-retransmit]          |
-| 3     | `initial_routing_sync`           | Sending node needs a complete routing information dump    | I        |                   | [BOLT #7][bolt07-sync]                |
-| 4/5   | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel   | IN       |                   | [BOLT #2][bolt02-open]                |
-| 6/7   | `gossip_queries`                 | More sophisticated gossip control                         | IN       |                   | [BOLT #7][bolt07-query]               |
-| 8/9   | `var_onion_optin`                | Requires/supports variable-length routing onion payloads  | IN9      |                   | [Routing Onion Specification][bolt04] |
-| 10/11 | `gossip_queries_ex`              | Gossip queries can include additional information         | IN       | `gossip_queries`  | [BOLT #7][bolt07-query]               |
-| 12/13 | `option_static_remotekey`        | Static key for remote output                              | IN       |                   | [BOLT #3](03-transactions.md)         |
-| 14/15 | `payment_secret`                 | Node supports `payment_secret` field                      | IN9      | `var_onion_optin` | [Routing Onion Specification][bolt04] |
-| 16/17 | `basic_mpp`                      | Node can receive basic multi-part payments                | IN9      | `payment_secret`  | [BOLT #4][bolt04-mpp]                 |
-| 18/19 | `option_support_large_channel`   | Can create large channels                                 | IN       |                   | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
-| 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]|
+| Bits  | Name                              | Description                                              | Context  | Dependencies              | Link                                                                 |
+|-------|-----------------------------------|----------------------------------------------------------|----------|---------------------------|----------------------------------------------------------------------|
+| 0/1   | `option_data_loss_protect`        | Requires or supports extra `channel_reestablish` fields  | IN       |                           | [BOLT #2][bolt02-retransmit]                                         |
+| 3     | `initial_routing_sync`            | Sending node needs a complete routing information dump   | I        |                           | [BOLT #7][bolt07-sync]                                               |
+| 4/5   | `option_upfront_shutdown_script`  | Commits to a shutdown scriptpubkey when opening channel  | IN       |                           | [BOLT #2][bolt02-open]                                               |
+| 6/7   | `gossip_queries`                  | More sophisticated gossip control                        | IN       |                           | [BOLT #7][bolt07-query]                                              |
+| 8/9   | `var_onion_optin`                 | Requires/supports variable-length routing onion payloads | IN9      |                           | [Routing Onion Specification][bolt04]                                |
+| 10/11 | `gossip_queries_ex`               | Gossip queries can include additional information        | IN       | `gossip_queries`          | [BOLT #7][bolt07-query]                                              |
+| 12/13 | `option_static_remotekey`         | Static key for remote output                             | IN       |                           | [BOLT #3](03-transactions.md)                                        |
+| 14/15 | `payment_secret`                  | Node supports `payment_secret` field                     | IN9      | `var_onion_optin`         | [Routing Onion Specification][bolt04]                                |
+| 16/17 | `basic_mpp`                       | Node can receive basic multi-part payments               | IN9      | `payment_secret`          | [BOLT #4][bolt04-mpp]                                                |
+| 18/19 | `option_support_large_channel`    | Can create large channels                                | IN       |                           | [BOLT #2](02-peer-protocol.md#the-open_channel-message)              |
+| 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]|
+| 24/25 | `option_compression`              | Compression algorithms advertised in `init`              | IN       |                           | [BOLT #1](01-messaging.md#the-init-message)                          |
 
 ## 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