mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-03-10 09:10:07 +01:00
Code Issues Projects Releases Wiki Activity

BOLT #2: fix cross-references.

Browse source 
And remove a duplicate sentence.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2016-11-15 14:00:37 +10:30
parent 9b7a2922b1
commit d1b7c783ac
1 changed files with 4 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
02-peer-protocol.md
View file

@ -680,10 +680,10 @@ to apply to its own commitment, any pending updates it sent before
that `commitsig`.
This message also supplies the signatures for the sender's HTLC-timeout transactions. See FIXME for how this is used with a penalty transaction.
This message also supplies the signatures for the sender's HTLC-timeout transactions. See [BOLT #5](05-onchain.md) for how this is used with a penalty transaction.
The description of key derivation is in [BOLT #3: Key Derivation FIXME].
The description of key derivation is in [BOLT #3](03-transactions.md#key-derivation).
1. type: 133 (`MSG_REVOCATION`)
@ -702,11 +702,10 @@ A sending node MUST set `per-commitment-secret` to the secret used to generate k
previous commitment transaction, and must set `next-key-offset` and `next-revocation-halfkey` to the values for its next commitment transaction.
A receiving node MUST check that `per-commitment-secret` generates the previous `key-offset` and `revocation-halfkey`, and MUST fail if it does not. A receiving node MAY fail if the `per-commitment-secret` was not generated by the protocol in [FIXME].
A receiving node MUST check that `per-commitment-secret` generates the previous `key-offset` and `revocation-halfkey`, and MUST fail if it does not. 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).
A receiving node MUST fail the channel if any htlc-timeout-signature is not valid, or if num-htlc-timeout is not equal to the number of outputs in the sending node's commitment transaction corresponding to HTLCs offered be the sending node. A receiving node MAY fail the channel if the `revocation-key` was not
generated as specified in "Commitment Key Generation"[FIXME] below.
A receiving node MUST fail the channel if any htlc-timeout-signature is not valid, or if num-htlc-timeout is not equal to the number of outputs in the sending node's commitment transaction corresponding to HTLCs offered be the sending node.
Nodes MUST NOT broadcast old (revoked) commitment transactions; doing