mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 3: per-commitment not per-commit.

Browse Source 
Be consistent.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2016-12-02 11:44:35 +10:30
parent 296075ec96
commit aa594c2608
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
03-transactions.md
View File

@ -388,7 +388,7 @@ determine what the contents of commitment transaction is, even if
given the transaction ID to watch for and can make a resonable guess
as to what HTLCs and balances might be included. Nonetheless, to
avoid storage for every commitment transaction, it can be given the
`per-commit-secret` values (which can be stored compactly) and the
`per-commitment-secret` values (which can be stored compactly) and the
`revocation-basepoint` and `delayed-payment-basepoint` to regnerate
the scripts required for the penalty transaction: it need only be
given (and store) the signatures for each penalty input.
@ -397,7 +397,7 @@ Changing the `<localkey>` and `<remotekey>` every time ensures that commitment t
Finally, even in the case of normal unilateral close, the HTLC-success
and/or HTLC-timeout transactions do not reveal anything to the
watcher, as it does not know the corresponding `per-commit-secret` and
watcher, as it does not know the corresponding `per-commitment-secret` and
cannot relate the `<local-delayedkey>` or `<revocationkey>` with
their bases.
@ -407,7 +407,7 @@ For efficiency, keys are generated from a series of per-commitment secrets which
These keys are simply generated by addition from their base points:
pubkey = basepoint + SHA256(per-commit-point || basepoint)*G
pubkey = basepoint + SHA256(per-commitment-point || basepoint)*G
The `localkey` uses the local node's `payment-basepoint`, `remotekey`
uses the remote node's `payment-basepoint`, the `local-delayedkey`
@ -427,17 +427,17 @@ and the local node provides the blinding factor which it later
reveals, so the remote node can use the secret revocationkey for a
penalty transaction.
The `per-commit-point` is generated using EC multiplication:
The `per-commitment-point` is generated using EC multiplication:
per-commit-point = per-commit-secret * G
per-commitment-point = per-commitment-secret * G
And this is used to derive the revocation key from the remote node's
`revocation-basepoint`:
revocationkey = revocation-basepoint * SHA256(revocation-basepoint || per-commit-point) + per-commit-point*SHA256(per-commit-point || revocation-basepoint)
revocationkey = revocation-basepoint * SHA256(revocation-basepoint || per-commitment-point) + per-commitment-point*SHA256(per-commitment-point || revocation-basepoint)
This construction ensures that neither the node providing the
basepoint nor the node providing the per-commit-point can know the
basepoint nor the node providing the `per-commitment-point` can know the
private key without the other node's secret.
### Per-commitment Secret Requirements