From 2ae5c63a2cf628de398cf05dcc221e8a9ff7a29e Mon Sep 17 00:00:00 2001
From: lightning-developer
 <95319454+lightning-developer@users.noreply.github.com>
Date: Sun, 5 Dec 2021 00:54:12 +0100
Subject: [PATCH 1/8] Clarification how messages are referred to

I added a clarification to BOLT 1 that explains that messages are usually referred to with their `message_name` and not as `message_name` message.
---
 01-messaging.md | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/01-messaging.md b/01-messaging.md
index ea3bb41df..eb2fdf186 100644
--- a/01-messaging.md
+++ b/01-messaging.md
@@ -9,6 +9,14 @@ The default TCP port is 9735. This corresponds to hexadecimal `0x2607`: the Unic
 
 All data fields are unsigned big-endian unless otherwise specified.
 
+Within this document messages are referred to with their `message_name` instead of their type. In particular they are usually not referred to with as `message_name` message but just as `message_name`. Thus within the document we write 
+
+> If a node receives / sends a `message_name`...
+
+instead of:
+
+> If a node receives / sends a `message_name` message...
+
 ## Table of Contents
 
   * [Connection Handling and Multiplexing](#connection-handling-and-multiplexing)

From af7fbb005908856cb2730f429d13e6e818c07726 Mon Sep 17 00:00:00 2001
From: lightning-developer
 <95319454+lightning-developer@users.noreply.github.com>
Date: Mon, 6 Dec 2021 18:55:00 +0100
Subject: [PATCH 2/8] Shorter formulation as suggested by @rustyrussell

Changed the formulation to the suggestion by @rustyrussel. for more context see: https://github.com/lightning/bolts/pull/941#issuecomment-986339661
---
 01-messaging.md | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/01-messaging.md b/01-messaging.md
index eb2fdf186..8320857e6 100644
--- a/01-messaging.md
+++ b/01-messaging.md
@@ -9,13 +9,7 @@ The default TCP port is 9735. This corresponds to hexadecimal `0x2607`: the Unic
 
 All data fields are unsigned big-endian unless otherwise specified.
 
-Within this document messages are referred to with their `message_name` instead of their type. In particular they are usually not referred to with as `message_name` message but just as `message_name`. Thus within the document we write 
-
-> If a node receives / sends a `message_name`...
-
-instead of:
-
-> If a node receives / sends a `message_name` message...
+We refer to messages by their `message_name`, instead of their type (e.g. "The receiving node sends `error`" instead of "... sends `error` message" or "... sends message 17").
 
 ## Table of Contents
 

From 5d078f31e9cd31b3d6ad01daf70950d37720c721 Mon Sep 17 00:00:00 2001
From: lightning-developer
 <95319454+lightning-developer@users.noreply.github.com>
Date: Mon, 6 Dec 2021 19:07:15 +0100
Subject: [PATCH 3/8] removed `message_name` message usage from BOLT1

---
 01-messaging.md | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/01-messaging.md b/01-messaging.md
index 8320857e6..219c7163b 100644
--- a/01-messaging.md
+++ b/01-messaging.md
@@ -325,11 +325,11 @@ The 2-byte `len` field indicates the number of bytes in the immediately followin
 The channel is referred to by `channel_id`, unless `channel_id` is 0 (i.e. all bytes are 0), in which case it refers to all channels.
 
 The funding node:
-  - for all error messages sent before (and including) the `funding_created` message:
+  - for all error messages sent before (and including) `funding_created`:
     - MUST use `temporary_channel_id` in lieu of `channel_id`.
 
 The fundee node:
-  - for all error messages sent before (and not including) the `funding_signed` message:
+  - for all error messages sent before (and not including) `funding_signed`:
     - MUST use `temporary_channel_id` in lieu of `channel_id`.
 
 A sending node:
@@ -339,7 +339,7 @@ A sending node:
   - SHOULD send `error` with the unknown `channel_id` in reply to messages of type `32`-`255` related to unknown channels.
   - 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.
+    - SHOULD include the raw, hex-encoded transaction in reply to a `funding_created`, `funding_signed`, `closing_signed`, or `commitment_signed`.
   - when `channel_id` is 0:
     - MUST fail all channels with the receiving node.
     - MUST close the connection.
@@ -378,11 +378,11 @@ application level. Such messages also allow obfuscation of traffic patterns.
     * [`u16`:`byteslen`]
     * [`byteslen*byte`:`ignored`]
 
-The `pong` message is to be sent whenever a `ping` message is received. It
+`pong` is to be sent whenever a `ping` is received. It
 serves as a reply and also serves to keep the connection alive, while
 explicitly notifying the other end that the receiver is still active. Within
-the received `ping` message, the sender will specify the number of bytes to be
-included within the data payload of the `pong` message.
+the received `ping`, the sender will specify the number of bytes to be
+included within the data payload of the `pong`.
 
 1. type: 19 (`pong`)
 2. data:
@@ -391,28 +391,28 @@ included within the data payload of the `pong` message.
 
 #### Requirements
 
-A node sending a `ping` message:
+A node sending `ping`:
   - SHOULD set `ignored` to 0s.
   - 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,
       - and MUST NOT fail the channels in this case.
-  - SHOULD NOT send `ping` messages more often than once every 30 seconds.
+  - SHOULD NOT send `ping` more often than once every 30 seconds.
 
-A node sending a `pong` message:
+A node sending `pong`:
   - 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:
+A node receiving `ping`:
   - 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`.
+    - MUST respond by sending `pong`, 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:
+A node receiving `pong`:
   - if `byteslen` does not correspond to any `ping`'s `num_pong_bytes` value it has sent:
     - MAY fail the channels.
 
@@ -428,7 +428,7 @@ no new data will be
 exchanged for a
 significant portion of a connection's lifetime. Also, on several platforms it's possible that Lightning
 clients will be put to sleep without prior warning. Hence, a
-distinct `ping` message is used, in order to probe for the liveness of the connection on
+distinct `ping` is used, in order to probe for the liveness of the connection on
 the other side, as well as to keep the established connection active.
 
 Additionally, the ability for a sender to request that the receiver send a
@@ -448,7 +448,7 @@ latitude is given because of network delays. Note that there are other methods
 of incoming traffic flooding (e.g. sending _odd_ unknown message types, or padding
 every message maximally).
 
-Finally, the usage of periodic `ping` messages serves to promote frequent key
+Finally, the periodic usage of `ping` serves to promote frequent key
 rotations as specified within [BOLT #8](08-transport.md).
 
 ## Appendix A: BigSize Test Vectors
@@ -914,15 +914,15 @@ failure:
 ## Appendix C: Message Extension
 
 This section contains examples of valid and invalid extensions on the `init`
-message. The base `init` message (without extensions) for these examples is
+message. The base `init` (without extensions) for these examples is
 `0x001000000000` (all features turned off).
 
-The following `init` messages are valid:
+The following examples of `init` are valid:
 
 - `0x001000000000`: no extension provided
 - `0x001000000000c9012acb0104`: the extension contains two unknown _odd_ TLV records (with types `0xc9` and `0xcb`)
 
-The following `init` messages are invalid:
+The following examples of `init` are invalid:
 
 - `0x00100000000001`: the extension is present but truncated
 - `0x001000000000ca012a`: the extension contains unknown _even_ TLV records (assuming that TLV type `0xca` is unknown)

From cd6e38ea2db63be510608fb6113e71f97973b979 Mon Sep 17 00:00:00 2001
From: lightning-developer
 <95319454+lightning-developer@users.noreply.github.com>
Date: Mon, 6 Dec 2021 19:21:24 +0100
Subject: [PATCH 4/8] Removed `message_name` message usage from BOLT 2

Kept one instance where it it was written ...`init` message exchange and the situation where it was talked about `update_` messages
---
 02-peer-protocol.md | 86 ++++++++++++++++++++++-----------------------
 1 file changed, 42 insertions(+), 44 deletions(-)

diff --git a/02-peer-protocol.md b/02-peer-protocol.md
index 28a32ff45..64f70abdc 100644
--- a/02-peer-protocol.md
+++ b/02-peer-protocol.md
@@ -54,7 +54,7 @@ ids.
 
 After authenticating and initializing a connection ([BOLT #8](08-transport.md)
 and [BOLT #1](01-messaging.md#the-init-message), respectively), channel establishment may begin.
-This consists of the funding node (funder) sending an `open_channel` message,
+This consists of the funding node (funder) sending `open_channel`,
 followed by the responding node (fundee) sending `accept_channel`. With the
 channel parameters locked in, the funder is able to create the funding
 transaction and both versions of the commitment transaction, as described in
@@ -63,15 +63,15 @@ The funder then sends the outpoint of the funding output with the `funding_creat
 message, along with the signature for the fundee's version of the commitment
 transaction. Once the fundee learns the funding outpoint, it's able to
 generate the signature for the funder's version of the commitment transaction and send it
-over using the `funding_signed` message.
+over using `funding_signed`.
 
-Once the channel funder receives the `funding_signed` message, it
+Once the channel funder receives `funding_signed`, it
 must broadcast the funding transaction to the Bitcoin network. After
-the `funding_signed` message is sent/received, both sides should wait
+the `funding_signed` is sent/received, both sides should wait
 for the funding transaction to enter the blockchain and reach the
-specified depth (number of confirmations). After both sides have sent
-the `funding_locked` message, the channel is established and can begin
-normal operation. The `funding_locked` message includes information
+specified depth (number of confirmations). After both sides have sent 
+`funding_locked`, the channel is established and can begin
+normal operation. The `funding_locked` includes information
 that will be used to construct channel authentication proofs.
 
 
@@ -165,7 +165,7 @@ node can offer.
 (i.e. 1/4 the more normally-used 'satoshi per 1000 vbytes') that this
 side will pay for commitment and HTLC transactions, as described in
 [BOLT #3](03-transactions.md#fee-calculation) (this can be adjusted
-later with an `update_fee` message).
+later by sending an `update_fee` ).
 
 `to_self_delay` is the number of blocks that the other node's to-self
 outputs must be delayed, using `OP_CHECKSEQUENCEVERIFY` delays; this
@@ -197,8 +197,8 @@ even if a node is compromised later.
 
 The `option_support_large_channel` is a feature used to let everyone 
 know this node will accept `funding_satoshis` greater than or equal to 2^24.
-Since it's broadcast in the `node_announcement` message other nodes can use it to identify peers 
-willing to accept large channel even before exchanging the `init` message with them. 
+Since it is broadcast in the `node_announcement` other nodes can use it to identify peers 
+willing to accept large channel even before exchanging `init` with them. 
 
 #### Defined Channel Types
 
@@ -247,9 +247,9 @@ The sending node SHOULD:
 The receiving node MUST:
   - ignore undefined bits in `channel_flags`.
   - if the connection has been re-established after receiving a previous
- `open_channel`, BUT before receiving a `funding_created` message:
-    - accept a new `open_channel` message.
-    - discard the previous `open_channel` message.
+ `open_channel`, BUT before receiving a `funding_created`:
+    - accept a new `open_channel`.
+    - discard the previous `open_channel`.
 
 The receiving node MAY fail the channel if:
   - `announce_channel` is `false` (`0`), yet it wishes to publicly announce the channel.
@@ -337,23 +337,22 @@ funding transaction and both versions of the commitment transaction.
 
 #### Requirements
 
-The `temporary_channel_id` MUST be the same as the `temporary_channel_id` in
-the `open_channel` message.
+The `temporary_channel_id` MUST be the same as the `temporary_channel_id` in `open_channel`.
 
 The sender:
   - SHOULD set `minimum_depth` to a number of blocks it considers reasonable to
 avoid double-spending of the funding transaction.
-  - MUST set `channel_reserve_satoshis` greater than or equal to `dust_limit_satoshis` from the `open_channel` message.
-  - MUST set `dust_limit_satoshis` less than or equal to `channel_reserve_satoshis` from the `open_channel` message.
+  - MUST set `channel_reserve_satoshis` greater than or equal to `dust_limit_satoshis` from the `open_channel`.
+  - MUST set `dust_limit_satoshis` less than or equal to `channel_reserve_satoshis` from the `open_channel`.
   - if it sets `channel_type`:
     - MUST set it to the `channel_type` from `open_channel`
 
 The receiver:
   - if `minimum_depth` is unreasonably large:
     - MAY reject the channel.
-  - if `channel_reserve_satoshis` is less than `dust_limit_satoshis` within the `open_channel` message:
+  - if `channel_reserve_satoshis` is less than `dust_limit_satoshis` within the `open_channel`:
     - MUST reject the channel.
-  - if `channel_reserve_satoshis` from the `open_channel` message is less than `dust_limit_satoshis`:
+  - if `channel_reserve_satoshis` from the `open_channel` is less than `dust_limit_satoshis`:
     - MUST reject the channel.
   - if `channel_type` is set, and `channel_type` was set in `open_channel`, and they are not equal types:
     - MUST reject the channel.
@@ -376,7 +375,7 @@ signature, via `funding_signed`, it will broadcast the funding transaction.
 #### Requirements
 
 The sender MUST set:
-  - `temporary_channel_id` the same as the `temporary_channel_id` in the `open_channel` message.
+  - `temporary_channel_id` the same as the `temporary_channel_id` in the `open_channel`.
   - `funding_txid` to the transaction ID of a non-malleable transaction,
     - and MUST NOT broadcast this transaction.
   - `funding_output_index` to the output number of that transaction that corresponds the funding transaction output, as defined in [BOLT #3](03-transactions.md#funding-transaction-output).
@@ -430,7 +429,7 @@ Both peers:
   - MUST use that `channel_type` for all commitment transactions.
 
 The sender MUST set:
-  - `channel_id` by exclusive-OR of the `funding_txid` and the `funding_output_index` from the `funding_created` message.
+  - `channel_id` by exclusive-OR of the `funding_txid` and the `funding_output_index` from the `funding_created`.
   - `signature` to the valid signature, using its `funding_pubkey` for the initial commitment transaction, as defined in [BOLT #3](03-transactions.md#commitment-transaction).
 
 The recipient:
@@ -469,7 +468,7 @@ This message indicates that the funding transaction has reached the `minimum_dep
 
 The sender MUST:
   - NOT send `funding_locked` unless outpoint of given by `funding_txid` and
-   `funding_output_index` in the `funding_created` message pays exactly `funding_satoshis` to the scriptpubkey specified in [BOLT #3](03-transactions.md#funding-transaction-output).
+   `funding_output_index` in the `funding_created` pays exactly `funding_satoshis` to the scriptpubkey specified in [BOLT #3](03-transactions.md#funding-transaction-output).
   - wait until the funding transaction has reached `minimum_depth` before
   sending this message.
   - set `next_per_commitment_point` to the per-commitment point to be used
@@ -522,7 +521,7 @@ Closing happens in two stages:
 
 ### Closing Initiation: `shutdown`
 
-Either node (or both) can send a `shutdown` message to initiate closing,
+Either node (or both) can send a `shutdown` to initiate closing,
 along with the `scriptpubkey` it wants to be paid to.
 
 1. type: 38 (`shutdown`)
@@ -541,7 +540,7 @@ A sending node:
     - MUST NOT send a `shutdown`.
   - MUST NOT send an `update_add_htlc` after a `shutdown`.
   - if no HTLCs remain in either commitment transaction:
-    - MUST NOT send any `update` message after a `shutdown`.
+    - MUST NOT send any `update_` message after a `shutdown`.
   - SHOULD fail to route any HTLC added after it has sent `shutdown`.
   - if it sent a non-zero-length `shutdown_scriptpubkey` in `open_channel` or `accept_channel`:
     - MUST send the same value in `scriptpubkey`.
@@ -559,9 +558,9 @@ A receiving node:
   - if the `scriptpubkey` is not in one of the above forms:
     - SHOULD fail the connection.
   - if it hasn't sent a `funding_locked` yet:
-    - MAY reply to a `shutdown` message with a `shutdown`
+    - MAY reply to a `shutdown` with a `shutdown`
   - once there are no outstanding updates on the peer, UNLESS it has already sent a `shutdown`:
-    - MUST reply to a `shutdown` message with a `shutdown`
+    - MUST reply to a `shutdown` with a `shutdown`
   - if both nodes advertised the `option_upfront_shutdown_script` feature, and the receiving node received a non-zero-length `shutdown_scriptpubkey` in `open_channel` or `accept_channel`, and that `shutdown_scriptpubkey` is not equal to `scriptpubkey`:
     - MUST fail the connection.
 
@@ -598,7 +597,7 @@ Once shutdown is complete and the channel is empty of HTLCs, the final
 current commitment transactions will have no HTLCs, and closing fee
 negotiation begins.  The funder chooses a fee it thinks is fair, and
 signs the closing transaction with the `scriptpubkey` fields from the
-`shutdown` messages (along with its chosen fee) and sends the signature;
+`shutdown` (along with its chosen fee) and sends the signature;
 the other node then replies similarly, using a fee it thinks is fair.  This
 exchange continues until both agree on the same fee or when one side fails
 the channel.
@@ -626,7 +625,7 @@ reply with the same value (completing after three messages).
 
 The funding node:
   - after `shutdown` has been received, AND no HTLCs remain in either commitment transaction:
-    - SHOULD send a `closing_signed` message.
+    - SHOULD send a `closing_signed`.
 
 The sending node:
   - SHOULD set the initial `fee_satoshis` according to its estimate of cost of
@@ -708,7 +707,7 @@ the closing transaction will likely never reach miners.
 Once both nodes have exchanged `funding_locked` (and optionally [`announcement_signatures`](07-routing-gossip.md#the-announcement_signatures-message)), the channel can be used to make payments via Hashed Time Locked Contracts.
 
 Changes are sent in batches: one or more `update_` messages are sent before a
-`commitment_signed` message, as in the following diagram:
+`commitment_signed`, as in the following diagram:
 
         +-------+                               +-------+
         |       |--(1)---- update_add_htlc ---->|       |
@@ -988,7 +987,7 @@ reconnection purposes; allowing them at other times simplifies the
 recipient code (though strict checking may help debugging).
 
 `max_accepted_htlcs` is limited to 483 to ensure that, even if both
-sides send the maximum number of HTLCs, the `commitment_signed` message will
+sides send the maximum number of HTLCs, the `commitment_signed` will
 still be under the maximum message size. It also ensures that
 a single penalty transaction can spend the entire commitment transaction,
 as calculated in [BOLT #5](05-onchain.md#penalty-transaction-weight-calculation).
@@ -1091,7 +1090,7 @@ such detection is left as an option.
 
 When a node has changes for the remote commitment, it can apply them,
 sign the resulting transaction (as defined in [BOLT #3](03-transactions.md)), and send a
-`commitment_signed` message.
+`commitment_signed`.
 
 1. type: 132 (`commitment_signed`)
 2. data:
@@ -1103,11 +1102,10 @@ sign the resulting transaction (as defined in [BOLT #3](03-transactions.md)), an
 #### Requirements
 
 A sending node:
-  - MUST NOT send a `commitment_signed` message that does not include any
+  - MUST NOT send a `commitment_signed` that does not include any
 updates.
-  - MAY send a `commitment_signed` message that only
-alters the fee.
-  - MAY send a `commitment_signed` message that doesn't
+  - MAY send a `commitment_signed` that only alters the fee.
+  - MAY send a `commitment_signed` that doesn't
 change the commitment transaction aside from the new revocation number
 (due to dust, identical HTLC replacement, or insignificant or multiple
 fee changes).
@@ -1125,7 +1123,7 @@ A receiving node:
       - MUST fail the channel.
   - if any `htlc_signature` is not valid for the corresponding HTLC transaction OR non-compliant with LOW-S-standard rule <sup>[LOWS](https://github.com/bitcoin/bitcoin/pull/6769)</sup>:
     - MUST fail the channel.
-  - MUST respond with a `revoke_and_ack` message.
+  - MUST respond with a `revoke_and_ack`.
 
 #### Rationale
 
@@ -1191,7 +1189,7 @@ A node:
 
 ### Updating Fees: `update_fee`
 
-An `update_fee` message is sent by the node which is paying the
+An `update_fee` is sent by the node which is paying the
 Bitcoin fee. Like any update, it's first committed to the receiver's
 commitment transaction and then (once acknowledged) committed to the
 sender's. Unlike an HTLC, `update_fee` is never closed but simply
@@ -1299,7 +1297,7 @@ A funding node:
 
 A non-funding node:
   - upon disconnection:
-    - if it has sent the `funding_signed` message:
+    - if it has sent the `funding_signed`:
       - MUST remember the channel for reconnection.
     - otherwise:
       - SHOULD NOT remember the channel for reconnection.
@@ -1326,7 +1324,7 @@ The sending node:
   - MUST set `next_commitment_number` to the commitment number of the
   next `commitment_signed` it expects to receive.
   - MUST set `next_revocation_number` to the commitment number of the
-  next `revoke_and_ack` message it expects to receive.
+  next `revoke_and_ack` it expects to receive.
   - if `option_static_remotekey` or `option_anchors` applies to the commitment
     transaction:
     - MUST set `my_current_per_commitment_point` to a valid point.
@@ -1348,11 +1346,11 @@ A node:
   - upon reconnection:
     - MUST ignore any redundant `funding_locked` it receives.
   - if `next_commitment_number` is equal to the commitment number of
-  the last `commitment_signed` message the receiving node has sent:
+  the last `commitment_signed` the receiving node has sent:
     - MUST reuse the same commitment number for its next `commitment_signed`.
   - otherwise:
     - if `next_commitment_number` is not 1 greater than the
-  commitment number of the last `commitment_signed` message the receiving
+  commitment number of the last `commitment_signed` the receiving
   node has sent:
       - SHOULD fail the channel.
     - if it has not sent `commitment_signed`, AND `next_commitment_number`
@@ -1399,7 +1397,7 @@ A node:
 
 A node:
   - MUST NOT assume that previously-transmitted messages were lost,
-    - if it has sent a previous `commitment_signed` message:
+    - if it has sent a previous `commitment_signed`:
       - MUST handle the case where the corresponding commitment transaction is
       broadcast at any time by the other side,
         - Note: this is particularly important if the node does not simply
@@ -1412,7 +1410,7 @@ A node:
 
 The requirements above ensure that the opening phase is nearly
 atomic: if it doesn't complete, it starts again. The only exception
-is if the `funding_signed` message is sent but not received. In
+is if the `funding_signed` is sent but not received. In
 this case, the funder will forget the channel, and presumably open
 a new one upon reconnection; meanwhile, the other node will eventually forget
 the original channel, due to never receiving `funding_locked` or seeing
@@ -1462,7 +1460,7 @@ fact an impossible requirement. A node must either firstly commit to
 disk and secondly broadcast the transaction or vice versa. The new
 language reflects this reality: it's surely better to remember a
 channel which hasn't been broadcast than to forget one which has!
-Similarly, for the fundee's `funding_signed` message: it's better to
+Similarly, for the fundee's `funding_signed`: it's better to
 remember a channel that never opens (and times out) than to let the
 funder open it while the fundee has forgotten it.
 

From 4a3e4cb688997896894977f28d43da39c5e3ea94 Mon Sep 17 00:00:00 2001
From: lightning-developer
 <95319454+lightning-developer@users.noreply.github.com>
Date: Mon, 6 Dec 2021 19:24:53 +0100
Subject: [PATCH 5/8] Removed `message_name` message usage from BOLT 03

---
 03-transactions.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/03-transactions.md b/03-transactions.md
index af6590fd3..f2095a4f8 100644
--- a/03-transactions.md
+++ b/03-transactions.md
@@ -78,7 +78,7 @@ A `<>` designates an empty vector as required for compliance with MINIMALIF-stan
 * version: 2
 * locktime: upper 8 bits are 0x20, lower 24 bits are the lower 24 bits of the obscured commitment number
 * txin count: 1
-   * `txin[0]` outpoint: `txid` and `output_index` from `funding_created` message
+   * `txin[0]` outpoint: `txid` and `output_index` from `funding_created`
    * `txin[0]` sequence: upper 8 bits are 0x80, lower 24 bits are upper 24 bits of the obscured commitment number
    * `txin[0]` script bytes: 0
    * `txin[0]` witness: `0 <signature_for_pubkey1> <signature_for_pubkey2>`
@@ -352,13 +352,13 @@ Note that there are two possible variants for each node.
 * version: 2
 * locktime: 0
 * txin count: 1
-   * `txin[0]` outpoint: `txid` and `output_index` from `funding_created` message
+   * `txin[0]` outpoint: `txid` and `output_index` from `funding_created`
    * `txin[0]` sequence: 0xFFFFFFFF
    * `txin[0]` script bytes: 0
    * `txin[0]` witness: `0 <signature_for_pubkey1> <signature_for_pubkey2>`
 * txout count: 0, 1 or 2
    * `txout` amount: final balance to be paid to one node (minus `fee_satoshis` from `closing_signed`, if this peer funded the channel)
-   * `txout` script: as specified in that node's `scriptpubkey` in its `shutdown` message
+   * `txout` script: as specified in that node's `scriptpubkey` in its `shutdown`
 
 ### Requirements
 

From 9534c630fb48d05cefe58bdfc0b2c7ec5df12e25 Mon Sep 17 00:00:00 2001
From: lightning-developer
 <95319454+lightning-developer@users.noreply.github.com>
Date: Mon, 6 Dec 2021 19:26:07 +0100
Subject: [PATCH 6/8] Removed `message_name` message usage from BOLT 04

---
 04-onion-routing.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/04-onion-routing.md b/04-onion-routing.md
index e44caed44..b684da962 100644
--- a/04-onion-routing.md
+++ b/04-onion-routing.md
@@ -267,7 +267,7 @@ It is formatted according to the Type-Length-Value format defined in [BOLT #1](0
 ### Requirements
 
 The writer:
-  - Unless `node_announcement`, `init` message or the [BOLT #11](11-payment-encoding.md#tagged-fields) offers feature `var_onion_optin`:
+  - Unless `node_announcement`, `init` or the [BOLT #11](11-payment-encoding.md#tagged-fields) offers feature `var_onion_optin`:
     - MUST use the legacy payload format instead.
   - For every node:
     - MUST include `amt_to_forward` and `outgoing_cltv_value`.

From 36c468117ee92490fca425dcd8245fedd18dc8b1 Mon Sep 17 00:00:00 2001
From: lightning-developer
 <95319454+lightning-developer@users.noreply.github.com>
Date: Mon, 6 Dec 2021 19:33:12 +0100
Subject: [PATCH 7/8] Removed `message_name` message from BOLT 07

there were situation where there was written `message_name` messages which I have replaced with `message_name`s.
---
 07-routing-gossip.md | 73 ++++++++++++++++++++++----------------------
 1 file changed, 36 insertions(+), 37 deletions(-)

diff --git a/07-routing-gossip.md b/07-routing-gossip.md
index c59dcf237..aa3436f07 100644
--- a/07-routing-gossip.md
+++ b/07-routing-gossip.md
@@ -11,14 +11,14 @@ To support channel and node discovery, three *gossip messages* are supported:
 
 - For node discovery, peers exchange `node_announcement`
   messages, which supply additional information about the nodes. There may be
-  multiple `node_announcement` messages, in order to update the node information.
+  multiple `node_announcement`s, in order to update the node information.
 
  - For channel discovery, peers in the network exchange
-   `channel_announcement` messages containing information regarding new
+   `channel_announcement`s containing information regarding new
    channels between the two nodes. They can also exchange `channel_update`
    messages, which update information about a channel. There can only be
    one valid `channel_announcement` for any channel, but at least two
-   `channel_update` messages are expected.
+   `channel_update`s are expected.
 
 # Table of Contents
 
@@ -66,7 +66,7 @@ making it easy to visibly group each component of the ID.
 ## The `announcement_signatures` Message
 
 This is a direct message between the two endpoints of a channel and serves as an opt-in mechanism to allow the announcement of the channel to the rest of the network.
-It contains the necessary signatures, by the sender, to construct the `channel_announcement` message.
+It contains the necessary signatures, by the sender, to construct the `channel_announcement`.
 
 1. type: 259 (`announcement_signatures`)
 2. data:
@@ -79,29 +79,28 @@ The willingness of the initiating node to announce the channel is signaled durin
 
 ### Requirements
 
-The `announcement_signatures` message is created by constructing a `channel_announcement` message, corresponding to the newly established channel, and signing it with the secrets matching an endpoint's `node_id` and `bitcoin_key`. After it's signed, the
-`announcement_signatures` message may be sent.
+The `announcement_signatures` is created by constructing a `channel_announcement`, corresponding to the newly established channel, and signing it with the secrets matching an endpoint's `node_id` and `bitcoin_key`. After it's signed, the `announcement_signatures` may be sent.
 
 A node:
-  - if the `open_channel` message has the `announce_channel` bit set AND a `shutdown` message has not been sent:
-    - MUST send the `announcement_signatures` message.
-      - MUST NOT send `announcement_signatures` messages until `funding_locked`
+  - if the `open_channel` has the `announce_channel` bit set AND a `shutdown` has not been sent:
+    - MUST send the `announcement_signatures`.
+      - MUST NOT send `announcement_signatures` until `funding_locked`
       has been sent and received AND the funding transaction has at least six confirmations.
   - otherwise:
-    - MUST NOT send the `announcement_signatures` message.
+    - MUST NOT send the `announcement_signatures`.
   - upon reconnection (once the above timing requirements have been met):
-    - MUST respond to the first `announcement_signatures` message with its own
-    `announcement_signatures` message.
-    - if it has NOT received an `announcement_signatures` message:
-      - SHOULD retransmit the `announcement_signatures` message.
+    - MUST respond to the first `announcement_signatures` with its own
+    `announcement_signatures`.
+    - if it has NOT received an `announcement_signatures`:
+      - SHOULD retransmit the `announcement_signatures`.
 
 A recipient node:
   - if the `short_channel_id` is NOT correct:
     - SHOULD fail the channel.
   - if the `node_signature` OR the `bitcoin_signature` is NOT correct:
     - MAY fail the channel.
-  - if it has sent AND received a valid `announcement_signatures` message:
-    - SHOULD queue the `channel_announcement` message for its peers.
+  - if it has sent AND received a valid `announcement_signatures`:
+    - SHOULD queue the `channel_announcement` for its peers.
   - if it has not sent funding_locked:
     - MAY defer handling the announcement_signatures until after it has sent funding_locked
     - otherwise:
@@ -334,7 +333,7 @@ any future fields appended to the end):
     - SHOULD fail the connection.
   - if `port` is equal to 0:
     - SHOULD ignore `ipv6_addr` OR `ipv4_addr`.
-  - if `node_id` is NOT previously known from a `channel_announcement` message,
+  - if `node_id` is NOT previously known from a `channel_announcement`,
   OR if `timestamp` is NOT greater than the last-received `node_announcement`
   from this `node_id`:
     - SHOULD ignore the message.
@@ -351,7 +350,7 @@ any future fields appended to the end):
 New node features are possible in the future: backwards compatible (or
 optional) ones will have _odd_ `feature` _bits_, incompatible ones will have
 _even_ `feature` _bits_. These will be propagated normally; incompatible
-feature bits here refer to the nodes, not the `node_announcement` message
+feature bits here refer to the nodes, not the `node_announcement`
 itself.
 
 New address types may be added in the future; as address descriptors have
@@ -420,7 +419,7 @@ individual bits:
 | 1             | `disable`   | Disable the channel.             |
 
 The `message_flags` bitfield is used to indicate the presence of optional
-fields in the `channel_update` message:
+fields in the `channel_update`:
 
 | Bit Position  | Name                      | Field                            |
 | ------------- | ------------------------- | -------------------------------- |
@@ -451,7 +450,7 @@ The origin node:
   remaining packet after `signature`, using its own `node_id`.
   - MUST set `chain_hash` AND `short_channel_id` to match the 32-byte hash AND
   8-byte channel ID that uniquely identifies the channel specified in the
-  `channel_announcement` message.
+  `channel_announcement`.
   - if the origin node is `node_id_1` in the message:
     - MUST set the `direction` bit of `channel_flags` to 0.
   - otherwise:
@@ -532,10 +531,10 @@ makes sense to have it be a UNIX timestamp (i.e. seconds since UTC
 1970-01-01). This cannot be a hard requirement, however, given the possible case
 of two `channel_update`s within a single second.
 
-It is assumed that more than one `channel_update` message changing the channel 
+It is assumed that more than one `channel_update` changing the channel 
 parameters in the same second may be a DoS attempt, and therefore, the node responsible 
 for signing such messages may be blacklisted. However, a node may send a same 
-`channel_update` message with a different signature (changing the nonce in signature 
+`channel_update` with a different signature (changing the nonce in signature 
 signing), and hence fields apart from signature are checked to see if the channel 
 parameters have changed for the same timestamp. It is also important to note that 
 ECDSA signatures are malleable. So, an intermediate node who received the `channel_update` 
@@ -582,8 +581,8 @@ contents could decompress to more than 3669960 bytes.
 
 Query messages can be extended with optional fields that can help reduce the number of messages needed to synchronize routing tables by enabling:
 
-- timestamp-based filtering of `channel_update` messages: only ask for `channel_update` messages that are newer than the ones you already have.
-- checksum-based filtering of `channel_update` messages: only ask for `channel_update` messages that carry different information from the ones you already have.
+- timestamp-based filtering of `channel_update`s: only ask for `channel_update`s that are newer than the ones you already have.
+- checksum-based filtering of `channel_update`s: only ask for `channel_update`s that carry different information from the ones you already have.
 
 Nodes can signal that they support extended gossip queries with the `gossip_queries_ex` feature bit.
 
@@ -621,7 +620,7 @@ Query flags must be minimally encoded, which means that one flag will be encoded
     * [`byte`:`full_information`]
 
 This is a general mechanism which lets a node query for the
-`channel_announcement` and `channel_update` messages for specific channels
+`channel_announcement` and `channel_update`s for specific channels
 (identified via `short_channel_id`s). This is usually used either because
 a node sees a `channel_update` for which it has no `channel_announcement` or
 because it has obtained previously unknown `short_channel_id`s
@@ -688,7 +687,7 @@ complete information on unknown `chain_hash` chains.  While this `full_informati
 field (previously and confusingly called `complete`) cannot be trusted, a 0 does indicate that the sender should search
 elsewhere for additional data.
 
-The explicit `reply_short_channel_ids_end` message means that the receiver can
+The explicit `reply_short_channel_ids_end` means that the receiver can
 indicate it doesn't know anything, and the sender doesn't need to rely on
 timeouts.  It also causes a natural ratelimiting of queries.
 
@@ -780,13 +779,13 @@ The receiver of `query_channel_range`:
     - MUST limit `number_of_blocks` to the maximum number of blocks whose
       results could fit in `encoded_short_ids`
     - MAY split block contents across multiple `reply_channel_range`.
-    - the first `reply_channel_range` message:
+    - the first `reply_channel_range`:
 	  - MUST set `first_blocknum` less than or equal to the `first_blocknum` in `query_channel_range`
 	  - MUST set `first_blocknum` plus `number_of_blocks` greater than `first_blocknum` in `query_channel_range`.
-	- successive `reply_channel_range` message:
+	- successive `reply_channel_range`:
 	  - MUST have `first_blocknum` equal or greater than the previous `first_blocknum`.
     - MUST set `sync_complete` to `false` if this is not the final `reply_channel_range`.
-	- the final `reply_channel_range` message:
+	- the final `reply_channel_range`:
 	  - MUST have `first_blocknum` plus `number_of_blocks` equal or greater than the `query_channel_range` `first_blocknum` plus `number_of_blocks`.
     - MUST set `sync_complete` to `true`.
 
@@ -873,7 +872,7 @@ generated directly by the node itself, so they should ignore filters.
 ## Initial Sync
 
 If a node requires an initial sync of gossip messages, it will be flagged
-in the `init` message, via a feature flag ([BOLT #9](09-features.md#assigned-localfeatures-flags)).
+in `init`, via a feature flag ([BOLT #9](09-features.md#assigned-localfeatures-flags)).
 
 Note that the `initial_routing_sync` feature is overridden (and should
 be considered equal to 0) by the `gossip_queries` feature if the
@@ -891,7 +890,7 @@ A node:
   - otherwise:
     - if it requires a full copy of the peer's routing state:
       - SHOULD set the `initial_routing_sync` flag to 1.
-    - upon receiving an `init` message with the `initial_routing_sync` flag set to
+    - upon receiving `init` with the `initial_routing_sync` flag set to
     1:
       - SHOULD send gossip messages for all known channels and nodes, as if they were just
       received.
@@ -929,8 +928,8 @@ A node:
   - MAY re-announce its channels regularly.
     - Note: this is discouraged, in order to keep the resource requirements low.
   - upon connection establishment:
-    - SHOULD send all `channel_announcement` messages, followed by the latest
-    `node_announcement` AND `channel_update` messages.
+    - SHOULD send all `channel_announcement`s, followed by the latest
+    `node_announcement` AND `channel_update`s.
 
 ### Rationale
 
@@ -967,7 +966,7 @@ A node:
   - if the funding output of a channel is being spent:
     - SHOULD be removed from the local network view AND be considered closed.
   - if the announced node no longer has any associated open channels:
-    - MAY prune nodes added through `node_announcement` messages from their
+    - MAY prune nodes added through `node_announcement`s from their
     local view.
       - Note: this is a direct result of the dependency of a `node_announcement`
       being preceded by a `channel_announcement`.
@@ -1061,7 +1060,7 @@ channels:
 3. C: 300 base + 3000 millionths
 4. D: 400 base + 4000 millionths
 
-The network will see eight `channel_update` messages:
+The network will see eight `channel_update`s:
 
 1. A->B: `cltv_expiry_delta` = 10, `fee_base_msat` = 100, `fee_proportional_millionths` = 1000
 1. A->D: `cltv_expiry_delta` = 10, `fee_base_msat` = 100, `fee_proportional_millionths` = 1000
@@ -1095,7 +1094,7 @@ per [HTLC Fees](#htlc-fees):
 
 Similarly, it would need to add B->C's `channel_update` `cltv_expiry` (20), C's
 requested `min_final_cltv_expiry` (9), and the cost for the _shadow route_ (42).
-Thus, A->B's `update_add_htlc` message would be:
+Thus, A->B's `update_add_htlc` would be:
 
    * `amount_msat`: 5010198
    * `cltv_expiry`: current-block-height + 20 + 9 + 42
@@ -1106,7 +1105,7 @@ Thus, A->B's `update_add_htlc` message would be:
 B->C's `update_add_htlc` would be the same as B->C's direct payment above.
 
 **A->D->C.** Finally, if for some reason A chose the more expensive route via D,
-A->D's `update_add_htlc` message would be:
+A->D's `update_add_htlc` would be:
 
    * `amount_msat`: 5020398
    * `cltv_expiry`: current-block-height + 40 + 9 + 42

From e67f058f08226d279de037240a6eadb883531947 Mon Sep 17 00:00:00 2001
From: lightning-developer
 <95319454+lightning-developer@users.noreply.github.com>
Date: Mon, 6 Dec 2021 19:36:07 +0100
Subject: [PATCH 8/8] Removed `message_name` message usage in BOLT 09

---
 09-features.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/09-features.md b/09-features.md
index 54cd2de6e..6bc5d2178 100644
--- a/09-features.md
+++ b/09-features.md
@@ -1,8 +1,8 @@
 # BOLT #9: Assigned Feature Flags
 
-This document tracks the assignment of `features` flags in the `init`
-message ([BOLT #1](01-messaging.md)), as well as `features` fields in
-the `channel_announcement` and `node_announcement` messages ([BOLT
+This document tracks the assignment of `features` flags in `init`
+([BOLT #1](01-messaging.md)), as well as `features` fields in
+`channel_announcement` and `node_announcement` ([BOLT
 #7](07-routing-gossip.md)).  The flags are tracked separately, since
 new flags will likely be added over time.
 
@@ -19,11 +19,11 @@ 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).
+* `I`: presented in `init`.
+* `N`: presented in `node_announcement`
+* `C`: presented in `channel_announcement`.
+* `C-`: presented in `channel_announcement`, but always odd (optional).
+* `C+`: presented in `channel_announcement`, but always even (required).
 * `9`: presented in [BOLT 11](11-payment-encoding.md) invoices.
 
 | Bits  | Name                             | Description                                               | Context  | Dependencies      | Link                                  |