Fixes from latest feedback

As per http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-09-02-20.06.html:

1. Leave my_current_per_commitment_point (but unused).
2. Assign the proper feature bit.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

02-peer-protocol.md

@@ -1132,7 +1132,7 @@ messages are), they are independent of requirements here.
    * [`u64`:`next_commitment_number`]
    * [`u64`:`next_revocation_number`]
    * [`32*byte`:`your_last_per_commitment_secret`] (option_data_loss_protect,option_static_remotekey)
-   * [`point`:`my_current_per_commitment_point`] (option_data_loss_protect)
+   * [`point`:`my_current_per_commitment_point`] (option_data_loss_protect,option_static_remotekey)
 
 `next_commitment_number`: A commitment number is a 48-bit
 incrementing counter for each commitment transaction; counters
@@ -1180,10 +1180,13 @@ The sending node:
   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.
-  - if it supports `option_data_loss_protect` or `option_static_remotekey`:
+  - if `option_static_remotekey` applies to the commitment transaction:
+    - MUST set `my_current_per_commitment_point` to a valid point.
+  - otherwise, if it supports `option_data_loss_protect`:
     - MUST set `my_current_per_commitment_point` to its commitment point for
       the last signed commitment it received from its channel peer (i.e. the commitment_point 
       corresponding to the commitment transaction the sender would use to unilaterally close).
+  - if `option_static_remotekey` applies to the commitment transaction, or the sending node supports `option_data_loss_protect`:
     - if `next_revocation_number` equals 0:
       - MUST set `your_last_per_commitment_secret` to all zeroes
     - otherwise:
@@ -1326,7 +1329,8 @@ broadcast a previous state.
 
 `option_static_remotekey` removes the changing `to_remote` key,
 so the `my_current_per_commitment_point` is unnecessary and thus
-removed, but the disclosure of previous secret still allows
+ignored (for parsing simplicity, it remains and must be a valid point,
+however), but the disclosure of previous secret still allows
 fall-behind detection.  An implementation can offer both, however, and
 fall back to the `option_data_loss_protect` behavior if
 `option_static_remotekey` is not negotiated.

09-features.md

@@ -26,7 +26,7 @@ These flags may only be used in the `init` message:
 | 3    | `initial_routing_sync`           | Indicates that the sending node needs a complete routing information dump | [BOLT #7][bolt07-sync]       |
 | 4/5  | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel                   | [BOLT #2][bolt02-open]       |
 | 6/7  | `gossip_queries`                 | More sophisticated gossip control                                         | [BOLT #7][bolt07-query]      |
-| 48/49| `option_static_remotekey`        | Static key for remote output                                              | [BOLT #3](03-transactions.md)|
+| 12/13| `option_static_remotekey`        | Static key for remote output                                              | [BOLT #3](03-transactions.md)|
 
 ## Assigned `globalfeatures` flags