pyln-spec: upgrade to the last bolt version

Changelog-Fixed: pyln-spec: update the bolts implementation

Signed-off-by: Vincenzo Palazzo <[email protected]>

contrib/pyln-spec/bolt1/pyln/spec/bolt1/csv.py

@@ -13,6 +13,10 @@
     "msgdata,error,channel_id,channel_id,",
     "msgdata,error,len,u16,",
     "msgdata,error,data,byte,len",
+    "msgtype,warning,1",
+    "msgdata,warning,channel_id,channel_id,",
+    "msgdata,warning,len,u16,",
+    "msgdata,warning,data,byte,len",
     "msgtype,ping,18",
     "msgdata,ping,num_pong_bytes,u16,",
     "msgdata,ping,byteslen,u16,",

contrib/pyln-spec/bolt1/pyln/spec/bolt1/gen_csv_version.py

@@ -1 +1 @@
-__csv_version__ = "1"
+__csv_version__ = "2"

contrib/pyln-spec/bolt1/pyln/spec/bolt1/gen_version.py

@@ -1,3 +1,3 @@
 __base_version__ = "1.0"
-__post_version__ = "186"
-__gitversion__ = "38abac62065172c00722dca10e7d3fc3049afd72"
+__post_version__ = "222"
+__gitversion__ = "f1c797df2966237244527c1c6343dbe9bc765342"

contrib/pyln-spec/bolt1/pyln/spec/bolt1/text.py

@@ -18,7 +18,7 @@
   * [Fundamental Types](#fundamental-types)
   * [Setup Messages](#setup-messages)
     * [The `init` Message](#the-init-message)
-    * [The `error` Message](#the-error-message)
+    * [The `error` and `warning` Messages](#the-error-and-warning-messages)
   * [Control Messages](#control-messages)
     * [The `ping` and `pong` Messages](#the-ping-and-pong-messages)
   * [Appendix A: BigSize Test Vectors](#appendix-a-bigsize-test-vectors)
@@ -226,6 +226,12 @@
 * `tu32`: a 0 to 4 byte unsigned integer
 * `tu64`: a 0 to 8 byte unsigned integer
 
+When used to encode amounts, the previous fields MUST comply with the upper
+bound of 21 million BTC:
+
+* satoshi amounts MUST be at most `0x000775f05a074000`
+* milli-satoshi amounts MUST be at most `0x1d24b2dfac520000`
+
 The following convenience types are also defined:
 
 * `chain_hash`: a 32-byte chain identifier (see [BOLT #0](00-introduction.md#glossary-and-terminology-guide))
@@ -259,9 +265,12 @@
     1. type: 1 (`networks`)
     2. data:
         * [`...*chain_hash`:`chains`]
-
+    1. type: 3 (`remote_addr`)
+    2. data:
+        * [`...*byte`:`data`]
 
 The optional `networks` indicates the chains the node is interested in.
+The optional `remote_addr` can be used to circumvent NAT issues.
 
 #### Requirements
 
@@ -272,6 +281,12 @@
   - 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.
+  - SHOULD set `remote_addr` to reflect the remote IP address (and port) of an
+    incoming connection, if the node is the receiver and the connection was done
+    via IP.
+  - if it sets `remote_addr`:
+    - MUST set it to a valid `address descriptor` (1 byte type and data) as described in [BOLT 7](07-routing-gossip.md#the-node_announcement-message).
+    - SHOULD NOT set private addresses as `remote_addr`.
 
 The receiving node:
   - MUST wait to receive `init` before sending any other messages.
@@ -280,11 +295,12 @@
   - upon receiving unknown _odd_ feature bits that are non-zero:
     - MUST ignore the bit.
   - upon receiving unknown _even_ feature bits that are non-zero:
-    - MUST fail the connection.
+    - MUST close the connection.
   - upon receiving `networks` containing no common chains
-    - MAY fail the connection.
+    - MAY close the connection.
   - if the feature vector does not set all known, transitive dependencies:
-    - MUST fail the connection.
+    - MUST close the connection.
+  - MAY use the `remote_addr` to update its `node_announcement`
 
 #### Rationale
 
@@ -301,7 +317,7 @@
 erroneously believing they will receive updates about their preferred
 network, or that they can open channels.
 
-### The `error` Message
+### The `error` and `warning` Messages
 
 For simplicity of diagnosis, it's often useful to tell a peer that something is incorrect.
 
@@ -311,7 +327,11 @@
    * [`u16`:`len`]
    * [`len*byte`:`data`]
 
-The 2-byte `len` field indicates the number of bytes in the immediately following field.
+1. type: 1 (`warning`)
+2. data:
+   * [`channel_id`:`channel_id`]
+   * [`u16`:`len`]
+   * [`len*byte`:`data`]
 
 #### Requirements
 
@@ -326,24 +346,31 @@
     - MUST use `temporary_channel_id` in lieu of `channel_id`.
 
 A sending node:
-  - when sending `error`:
-    - MUST fail the channel referred to by the error message.
   - SHOULD send `error` for protocol violations or internal errors that make channels unusable or that make further communication unusable.
   - SHOULD send `error` with the unknown `channel_id` in reply to messages of type `32`-`255` related to unknown channels.
+  - when sending `error`:
+    - MUST fail the channel(s) referred to by the error message.
+    - MAY set `channel_id` to all zero to indicate all channels.
+  - when sending `warning`:
+    - MAY set `channel_id` to all zero if the warning is not related to a specific channel.
+  - MAY close the connection after sending.
   - MAY send an empty `data` field.
   - when failure was caused by an invalid signature check:
     - SHOULD include the raw, hex-encoded transaction in reply to a `funding_created`, `funding_signed`, `closing_signed`, or `commitment_signed` message.
-  - when `channel_id` is 0:
-    - MUST fail all channels with the receiving node.
-    - MUST close the connection.
-  - MUST set `len` equal to the length of `data`.
 
 The receiving node:
   - upon receiving `error`:
-    - MUST fail the channel referred to by the error message, if that channel is with the sending node.
-  - if no existing channel is referred to by the message:
+    - if `channel_id` is all zero:
+      - MUST fail all channels with the sending node.
+    - otherwise:
+      - MUST fail the channel referred to by `channel_id`, if that channel is with the sending node.
+  - upon receiving `warning`:
+    - SHOULD log the message for later diagnosis.
+    - MAY disconnect.
+    - MAY reconnect after some delay to retry.
+    - MAY attempt `shutdown` if permitted at this point.
+  - if no existing channel is referred to by `channel_id`:
     - MUST ignore the message.
-  - MUST truncate `len` to the remainder of the packet (if it's larger).
   - if `data` is not composed solely of printable ASCII characters (For reference: the printable character set includes byte values 32 through 126, inclusive):
     - SHOULD NOT print out `data` verbatim.
 
@@ -354,6 +381,11 @@
 connection. It's also useful to describe protocol violations for
 diagnosis, as this indicates that one peer has a bug.
 
+On the other hand, overuse of error messages has lead to
+implementations ignoring them (to avoid an otherwise expensive channel
+break), so the "warning" message was added to allow some degree of
+retry or recovery for spurious errors.
+
 It may be wise not to distinguish errors in production settings, lest
 it leak information — hence, the optional `data` field.
 
@@ -389,25 +421,23 @@
   - MUST NOT set `ignored` to sensitive data such as secrets or portions of initialized
 memory.
   - if it doesn't receive a corresponding `pong`:
-    - MAY terminate the network connection,
+    - MAY close the network connection,
       - and MUST NOT fail the channels in this case.
-  - SHOULD NOT send `ping` messages more often than once every 30 seconds.
 
 A node sending a `pong` message:
   - SHOULD set `ignored` to 0s.
   - MUST NOT set `ignored` to sensitive data such as secrets or portions of initialized
  memory.
 
 A node receiving a `ping` message:
-  - SHOULD fail the channels if it has received significantly in excess of one `ping` per 30 seconds.
   - if `num_pong_bytes` is less than 65532:
     - MUST respond by sending a `pong` message, with `byteslen` equal to `num_pong_bytes`.
   - otherwise (`num_pong_bytes` is **not** less than 65532):
     - MUST ignore the `ping`.
 
 A node receiving a `pong` message:
   - if `byteslen` does not correspond to any `ping`'s `num_pong_bytes` value it has sent:
-    - MAY fail the channels.
+    - MAY close the connection.
 
 ### Rationale
 
@@ -913,13 +943,13 @@
 The following `init` messages are valid:
 
 - `0x001000000000`: no extension provided
-- `0x00100000000001012a030104`: the extension contains two _odd_ TLV records (with types `0x01` and `0x03`)
+- `0x001000000000c9012acb0104`: the extension contains two unknown _odd_ TLV records (with types `0xc9` and `0xcb`)
 
 The following `init` messages are invalid:
 
 - `0x00100000000001`: the extension is present but truncated
-- `0x00100000000002012a`: the extension contains unknown _even_ TLV records (assuming that TLV type `0x02` is unknown)
-- `0x001000000000010101010102`: the extension TLV stream is invalid (duplicate TLV record type `0x01`)
+- `0x001000000000ca012a`: the extension contains unknown _even_ TLV records (assuming that TLV type `0xca` is unknown)
+- `0x001000000000c90101c90102`: the extension TLV stream is invalid (duplicate TLV record type `0xc9`)
 
 Note that when messages are signed, the _extension_ is part of the signed bytes.
 Nodes should store the _extension_ bytes even if they don't understand them to

contrib/pyln-spec/bolt2/pyln/spec/bolt2/gen_version.py

@@ -1,3 +1,3 @@
 __base_version__ = "1.0"
-__post_version__ = "186"
-__gitversion__ = "38abac62065172c00722dca10e7d3fc3049afd72"
+__post_version__ = "222"
+__gitversion__ = "f1c797df2966237244527c1c6343dbe9bc765342"