consistency: option-data-loss-protect->option_data_loss_protect

02-peer-protocol.md

@@ -1064,8 +1064,8 @@ messages are), they are independent of requirements here.
    * [`32`:`channel_id`]
    * [`8`:`next_local_commitment_number`]
    * [`8`:`next_remote_revocation_number`]
-   * [`32`:`your_last_per_commitment_secret`] (option-data-loss-protect)
-   * [`33`:`my_current_per_commitment_point`] (option-data-loss-protect)
+   * [`32`:`your_last_per_commitment_secret`] (option_data_loss_protect)
+   * [`33`:`my_current_per_commitment_point`] (option_data_loss_protect)
 
 ### Requirements
 
@@ -1106,7 +1106,7 @@ The sending node:
   next `commitment_signed` it expects to receive.
   - MUST set `next_remote_revocation_number` to the commitment number of the
   next `revoke_and_ack` message it expects to receive.
-  - if it supports `option-data-loss-protect`:
+  - if it supports `option_data_loss_protect`:
     - if `next_remote_revocation_number` equals 0:
       - MUST set `your_last_per_commitment_secret` to all zeroes
     - otherwise:
@@ -1142,7 +1142,7 @@ A node:
       - SHOULD fail the channel.
 
  A receiving node:
-  - if it supports `option-data-loss-protect`, AND the `option-data-loss-protect`
+  - if it supports `option_data_loss_protect`, AND the `option_data_loss_protect`
   fields are present:
     - if `next_remote_revocation_number` is greater than expected above, AND
     `your_last_per_commitment_secret` is correct for that
@@ -1222,7 +1222,7 @@ Similarly, for the fundee's `funding_signed` message: 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.
 
-`option-data-loss-protect` was added to allow a node, which has somehow fallen behind
+`option_data_loss_protect` was added to allow a node, which has somehow fallen behind
 (e.g. has been restored from old backup), to detect that it's fallen-behind. A fallen-behind
 node must know it cannot broadcast its current commitment transaction — which would lead to
 total loss of funds — as the remote node can prove it knows the

05-onchain.md

@@ -363,7 +363,7 @@ In the case of data loss, a local node may reach a state where it doesn't
 recognize all of the *remote node's* commitment transaction HTLC outputs. It can
 detect the data loss state, because it has signed the transaction, and the
 commitment number is greater than expected. If both nodes support
-`option-data-loss-protect`, the local node will possess the remote's
+`option_data_loss_protect`, the local node will possess the remote's
 `per_commitment_point`, and thus can derive its own `remotepubkey` for the
 transaction, in order to salvage its own funds. Note: in this scenario, the node
 will be unable to salvage the HTLCs.

09-features.md

@@ -16,7 +16,7 @@ These flags may only be used in the `init` message:
 
 | Bits | Name             |Description                                     | Link                                                                |
 |------|------------------|------------------------------------------------|---------------------------------------------------------------------|
-| 0/1  | `option-data-loss-protect` | Requires or supports extra `channel_reestablish` fields | [BOLT #2](02-peer-protocol.md#message-retransmission) |
+| 0/1  | `option_data_loss_protect` | Requires or supports extra `channel_reestablish` fields | [BOLT #2](02-peer-protocol.md#message-retransmission) |
 | 3  | `initial_routing_sync` | Indicates that the sending node needs a complete routing information dump | [BOLT #7](07-routing-gossip.md#initial-sync) |
 | 4/5  | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |