Skip to content

Commit 60d91f2

Browse files
committed
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]>
1 parent 77afd57 commit 60d91f2

File tree

1 file changed

+9
-10
lines changed

1 file changed

+9
-10
lines changed

02-peer-protocol.md

Lines changed: 9 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@ The messages described in this document are grouped logically into 4 groups by t
2727
* [Adding an HTLC](#adding-an-htlc)
2828
* [Removing an HTLC: `update_fulfill_htlc` and `update_fail_htlc`](#removing-an-htlc-update_fulfill_htlc-and-update_fail_htlc)
2929
* [Committing Updates So Far: `commitsig`](#committing-updates-so-far-commitsig)
30-
* [Completing the transition to the updated state: `revocation`](#completing-the-transition-to-the-updated-state-revocation)
30+
* [Completing the transition to the updated state: `revoke_and_ack`](#completing-the-transition-to-the-updated-state-revocation)
3131
* [Authors](#authors)
3232

3333
# Channel
@@ -450,18 +450,17 @@ Changes are sent in batches: one or more `update` messages are sent before a
450450
| | | |
451451
| |--(4)---- commit ------>| |
452452
| A | | B |
453-
| |<-(5)---- revocation -------| |
453+
| |<-(5)--- revoke_and_ack-----| |
454454
| |<-(6)---- commit -------| |
455455
| | | |
456-
| |--(7)---- revocation ------>| |
456+
| |--(7)--- revoke_and_ack---->| |
457457
+-------+ +-------+
458458

459459

460460
Counterintuitively, these updates apply to the *other node's*
461461
commitment transaction; the node only adds those updates to its own
462462
commitment transaction when the remote node acknowledges it has
463-
applied them.
464-
463+
applied them via `revoke_and_ack`.
465464

466465
Thus each update traverses through the following states:
467466
1. Pending on the receiver
@@ -661,7 +660,7 @@ A receiving node MUST fail the channel if `signature` is not valid for
661660
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.
662661

663662

664-
A receiving node MUST respond with a `revocation` message.
663+
A receiving node MUST respond with a `revoke_and_ack` message.
665664

666665

667666
#### Rationale
@@ -673,12 +672,12 @@ There's little point offering spam updates; it implies a bug.
673672
The `num-htlcs` field is redundant, but makes the packet length check fully self-contained.
674673

675674

676-
### Completing the transition to the updated state: `revocation`
675+
### Completing the transition to the updated state: `revoke_and_ack`
677676

678677

679678
Once the recipient of `commitsig` checks the signature, it knows that
680679
it has a valid new commitment transaction, replies with the commitment
681-
preimage for the previous commitment transaction in a `revocation`
680+
preimage for the previous commitment transaction in a `revoke_and_ack`
682681
message.
683682

684683

@@ -694,7 +693,7 @@ This message also supplies the signatures for the sender's HTLC-timeout transact
694693
The description of key derivation is in [BOLT #3](03-transactions.md#key-derivation).
695694

696695

697-
1. type: 133 (`MSG_REVOCATION`)
696+
1. type: 133 (`MSG_REVOKE_AND_ACK`)
698697
2. data:
699698
* [8:channel-id]
700699
* [32:per-commitment-secret]
@@ -707,7 +706,7 @@ The description of key derivation is in [BOLT #3](03-transactions.md#key-derivat
707706

708707

709708
A sending node MUST set `per-commitment-secret` to the secret used to generate keys for the
710-
previous commitment transaction, MUST set `next-per-commitment-point` to the values for its next commitment transaction, and MUST set `padding` to all zeroes.
709+
previous commitment transaction, MUST set `next-per-commitment-point` to the values for its next commitment transsaction, and MUST set `padding` to all zeroes.
711710

712711

713712
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).

0 commit comments

Comments
 (0)