More fixups

Feedback from @araspitzu @Roasbeef @bitconner
lightning · Aug 28, 2019 · 930a9b4 · 930a9b4
1 parent d6859f8
commit 930a9b4
Show file tree

Hide file tree

Showing 2 changed files with 3 additions and 3 deletions.
diff --git a/02-peer-protocol.md b/02-peer-protocol.md
@@ -386,7 +386,7 @@ The recipient:
 #### Rationale
 
 We decide on `option_static_remotekey` at this point when we first have to generate the commitment
-transaction.  Even if a later reconnection does not negotiate this parameter, this channel will honor it.
+transaction.  Even if a later reconnection does not negotiate this parameter, this channel will continue to use `option_static_remotekey`; we don't support "downgrading".
 This simplifies channel state, particularly penalty transaction handling.
 
 ### The `funding_locked` Message
@@ -1329,7 +1329,7 @@ so the `my_current_per_commitment_point` is unnecessary and thus
 removed, 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_simplified_commitment` is not negotiated.
+`option_static_remotekey` is not negotiated.
 
 # Authors
 

diff --git a/03-transactions.md b/03-transactions.md
@@ -467,7 +467,7 @@ the remote node's `payment_basepoint`.
 
 The simplified derivation means that a node can spend a commitment
 transaction even if it has lost data and doesn't know the
-corresponding `payment_basepoint`.  A watchtower could correlate
+corresponding `per_commitment_point`.  A watchtower could correlate
 transactions given to it which only have a `to_remote` output if it
 sees one of them onchain, but such transactions do not need any
 enforcement and should not be handed to a watchtower.