mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-02-22 14:22:46 +01:00
Code Issues Projects Releases Wiki Activity

MSG_REVOCATION -> MSG_REVOKE_AND_ACK.

Browse source 
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 <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2016-11-21 10:34:43 +10:30
parent 77afd570af
commit 60d91f2758
1 changed files with 9 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
02-peer-protocol.md
View file

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