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`. 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`) 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. 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 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.
generated as specified in "Commitment Key Generation"[FIXME] below.
Nodes MUST NOT broadcast old (revoked) commitment transactions; doing Nodes MUST NOT broadcast old (revoked) commitment transactions; doing