You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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]>
Copy file name to clipboardExpand all lines: 02-peer-protocol.md
+9-10Lines changed: 9 additions & 10 deletions
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,7 @@ The messages described in this document are grouped logically into 4 groups by t
27
27
*[Adding an HTLC](#adding-an-htlc)
28
28
*[Removing an HTLC: `update_fulfill_htlc` and `update_fail_htlc`](#removing-an-htlc-update_fulfill_htlc-and-update_fail_htlc)
29
29
*[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)
31
31
*[Authors](#authors)
32
32
33
33
# Channel
@@ -450,18 +450,17 @@ Changes are sent in batches: one or more `update` messages are sent before a
450
450
| | | |
451
451
| |--(4)---- commit ------>| |
452
452
| A | | B |
453
-
| |<-(5)---- revocation -------| |
453
+
| |<-(5)--- revoke_and_ack-----| |
454
454
| |<-(6)---- commit -------| |
455
455
| | | |
456
-
| |--(7)---- revocation ------>| |
456
+
| |--(7)--- revoke_and_ack---->| |
457
457
+-------+ +-------+
458
458
459
459
460
460
Counterintuitively, these updates apply to the *other node's*
461
461
commitment transaction; the node only adds those updates to its own
462
462
commitment transaction when the remote node acknowledges it has
463
-
applied them.
464
-
463
+
applied them via `revoke_and_ack`.
465
464
466
465
Thus each update traverses through the following states:
467
466
1. Pending on the receiver
@@ -661,7 +660,7 @@ A receiving node MUST fail the channel if `signature` is not valid for
661
660
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.
662
661
663
662
664
-
A receiving node MUST respond with a `revocation` message.
663
+
A receiving node MUST respond with a `revoke_and_ack` message.
665
664
666
665
667
666
#### Rationale
@@ -673,12 +672,12 @@ There's little point offering spam updates; it implies a bug.
673
672
The `num-htlcs` field is redundant, but makes the packet length check fully self-contained.
674
673
675
674
676
-
### Completing the transition to the updated state: `revocation`
675
+
### Completing the transition to the updated state: `revoke_and_ack`
677
676
678
677
679
678
Once the recipient of `commitsig` checks the signature, it knows that
680
679
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`
682
681
message.
683
682
684
683
@@ -694,7 +693,7 @@ This message also supplies the signatures for the sender's HTLC-timeout transact
694
693
The description of key derivation is in [BOLT #3](03-transactions.md#key-derivation).
695
694
696
695
697
-
1. type: 133 (`MSG_REVOCATION`)
696
+
1. type: 133 (`MSG_REVOKE_AND_ACK`)
698
697
2. data:
699
698
*[8:channel-id]
700
699
*[32:per-commitment-secret]
@@ -707,7 +706,7 @@ The description of key derivation is in [BOLT #3](03-transactions.md#key-derivat
707
706
708
707
709
708
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.
711
710
712
711
713
712
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