MSG_REVOCATION -> MSG_REVOKE_AND_ACK.

The fact that a revocation response also serves to acknowledge the
pending changes (and thus indicate the sender should apply them
to itself) is documented in the desciption, but still terribly
subtle.  Joseph suggested making it clearer, I think this
does that.

Signed-off-by: Rusty Russell <[email protected]>

Author: rustyrussell

02-peer-protocol.md

@@ -27,7 +27,7 @@ The messages described in this document are grouped logically into 4 groups by t
       * [Adding an HTLC](#adding-an-htlc)
       * [Removing an HTLC: `update_fulfill_htlc` and `update_fail_htlc`](#removing-an-htlc-update_fulfill_htlc-and-update_fail_htlc)
       * [Committing Updates So Far: `commitsig`](#committing-updates-so-far-commitsig)
-      * [Completing the transition to the updated state: `revocation`](#completing-the-transition-to-the-updated-state-revocation)
+      * [Completing the transition to the updated state: `revoke_and_ack`](#completing-the-transition-to-the-updated-state-revocation)
   * [Authors](#authors)
 
 # Channel
@@ -450,18 +450,17 @@ Changes are sent in batches: one or more `update` messages are sent before a
         |       |                            |       |
         |       |--(4)----   commit   ------>|       |
         |   A   |                            |   B   |
-        |       |<-(5)---- revocation -------|       |
+        |       |<-(5)--- revoke_and_ack-----|       |
         |       |<-(6)----   commit   -------|       |
         |       |                            |       |
-        |       |--(7)---- revocation ------>|       |
+        |       |--(7)--- revoke_and_ack---->|       |
         +-------+                            +-------+
 
 
 Counterintuitively, these updates apply to the *other node's*
 commitment transaction; the node only adds those updates to its own
 commitment transaction when the remote node acknowledges it has
-applied them.
-
+applied them via `revoke_and_ack`.
 
 Thus each update traverses through the following states:
 1. Pending on the receiver
@@ -661,7 +660,7 @@ A receiving node MUST fail the channel if `signature` is not valid for
 its local commitment transaction once all pending updates are applied.  A receiving node MUST fail the channel if `num-htlcs` is not exactly the number of HTLC outputs in the local commitment transaction once all pending updates are applied.  A receiving node MUST fail the channel if any `htlc-signature` is not valid for the corresponding HTLC transaction.
 
 
-A receiving node MUST respond with a `revocation` message.
+A receiving node MUST respond with a `revoke_and_ack` message.
 
 
 #### Rationale
@@ -673,12 +672,12 @@ There's little point offering spam updates; it implies a bug.
 The `num-htlcs` field is redundant, but makes the packet length check fully self-contained.
 
 
-### Completing the transition to the updated state: `revocation`
+### Completing the transition to the updated state: `revoke_and_ack`
 
 
 Once the recipient of `commitsig` checks the signature, it knows that
 it has a valid new commitment transaction, replies with the commitment
-preimage for the previous commitment transaction in a `revocation`
+preimage for the previous commitment transaction in a `revoke_and_ack`
 message.
 
 
@@ -694,7 +693,7 @@ This message also supplies the signatures for the sender's HTLC-timeout transact
 The description of key derivation is in [BOLT #3](03-transactions.md#key-derivation).
 
 
-1. type: 133 (`MSG_REVOCATION`)
+1. type: 133 (`MSG_REVOKE_AND_ACK`)
 2. data:
    * [8:channel-id]
    * [32:per-commitment-secret]
@@ -707,7 +706,7 @@ The description of key derivation is in [BOLT #3](03-transactions.md#key-derivat
 
 
 A sending node MUST set `per-commitment-secret` to the secret used to generate keys for the
-previous commitment transaction, MUST set `next-per-commitment-point` to the values for its next commitment transaction, and MUST set `padding` to all zeroes.
+previous commitment transaction, MUST set `next-per-commitment-point` to the values for its next commitment transsaction, and MUST set `padding` to all zeroes.
 
 
 A receiving node MUST check that `per-commitment-secret` generates the previous `per-commitment-point`, and MUST fail if it does not. A receiving node MUST ignore the value of `padding`.  A receiving node MAY fail if the `per-commitment-secret` was not generated by the protocol in [BOLT #3](03-transactions.md#per-commitment-secret-requirements).