1
0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00

BOLT 2,3: fix changes requested

This commit is contained in:
Landon Mutch 2017-11-21 18:31:23 -08:00 committed by Rusty Russell
parent cd3c49eb88
commit 7a8a5d88dd
2 changed files with 5 additions and 5 deletions

View File

@ -251,7 +251,7 @@ signature, it will broadcast the funding transaction.
The sender MUST set:
- `temporary_channel_id` the same as the `temporary_channel_id` in the `open_channel` message.
- `funding_txid` to the transaction ID of a non-malleable transaction,
- and MUST NOT broadcast this non-malleable transaction.
- and MUST NOT broadcast this transaction.
- `funding_output_index` to the output number of that transaction which corresponds the funding transaction output, as defined in [BOLT #3](03-transactions.md#funding-transaction-output).
- `signature` to the valid signature using its `funding_pubkey` for the initial commitment transaction, as defined in [BOLT #3](03-transactions.md#commitment-transaction).
@ -574,7 +574,7 @@ received.
incoming HTLC from A; i.e. B can get the preimage from C and fulfill the incoming
HTLC on-chain before A can time it out on-chain.
The critical settings here are the [`cltv_expiry_delta` in
The critical settings here are the `cltv_expiry_delta` in
[BOLT #7](07-routing-gossip.md#the-channel_update-message) and the
related `min_final_cltv_expiry` in [BOLT #11](11-payment-encoding.md#tagged-fields).
`cltv_expiry_delta` is the minimum difference in HTLC CLTV timeouts, in

View File

@ -323,7 +323,7 @@ The fee for an HTLC-success transaction:
1. Multiply `feerate_per_kw` by 703 and divide by 1000 (rounding down).
The base fee for a commitment transaction:
- MUST BE calculated to match:
- MUST be calculated to match:
1. Start with `weight` = 724.
2. For each committed HTLC, if that output is not trimmed as specified in
[Trimmed Outputs](#trimmed-outputs), add 172 to `weight`.
@ -450,8 +450,8 @@ secrets are known (i.e. `localkey`, `local_htlckey`, and `local_delayedkey` only
### `revocationkey` Derivation
The `revocationkey` is a blinded key: when a local node wishes to create a new
commitment for a remote node, it uses its own `revocation_basepoint` and the remote
The `revocationkey` is a blinded key: when the local node wishes to create a new
commitment for the remote node, it uses its own `revocation_basepoint` and the remote
node's `per_commitment_point` to derive a new `revocationkey` for the
commitment. After the remote node reveals (thereby revoking that commitment) the
`per_commitment_secret` used, the local node