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

BOLT 2, BOLT 3: fee-per-kw kilo == 1000, not 1024.

Browse Source 
I checked the bitcoin source to be sure, too.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2017-01-17 13:26:54 +10:30 committed by Olaoluwa Osuntokun
parent 96bbc8a9ee
commit fddc992b2d
2 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
02-peer-protocol.md
View File

@ -98,7 +98,7 @@ The `temporary-channel-id` is used to identify this channel until the funding tr
`max-htlc-value-in-inflight-msat` is a cap on total value of outstanding HTLCs, which allows a node to limit its exposure to HTLCs; similarly `max-accepted-htlcs` limits the number of outstanding HTLCs the other node can offer. `channel-reserve-satoshis` is the minimum amount that the other node is to keep as a direct payment. `htlc-minimum-msat` indicates the smallest value HTLC this node will accept.
`feerate-per-kw` indicates the initial fee rate by kiloweight (ie. 4 times by the more normally-used 'feerate per kilobyte') which this side will pay for commitment and HTLC transactions as described in [BOLT #3](03-transactions.md#fee-calculation) (this can be adjusted later with an `update_fee` message). `to-self-delay` is the number of blocks that the other nodes to-self outputs must be delayed, using `OP_CHECKSEQUENCEVERIFY` delays; this is how long it will have to wait in case of breakdown before redeeming its own funds.
`feerate-per-kw` indicates the initial fee rate by 1000-weight (ie. 4 times by the more normally-used 'feerate per kilobyte') which this side will pay for commitment and HTLC transactions as described in [BOLT #3](03-transactions.md#fee-calculation) (this can be adjusted later with an `update_fee` message). `to-self-delay` is the number of blocks that the other nodes to-self outputs must be delayed, using `OP_CHECKSEQUENCEVERIFY` delays; this is how long it will have to wait in case of breakdown before redeeming its own funds.
The `funding-pubkey` is the public key in the 2-of-2 multisig script of the funding transaction output. The `revocation-basepoint` is combined with the revocation preimage for this commitment transaction to generate a unique revocation key for this commitment transaction. The `payment-basepoint` and `delayed-payment-basepoint` are similarly used to generate a series of keys for any payments to this node: `delayed-payment-basepoint` is used to for payments encumbered by a delay. Varying these keys ensures that the transaction ID of each commitment transaction is unpredictable by an external observer, even if one commitment transaction is seen: this property is very useful for preserving privacy when outsourcing penalty transactions to third parties.

6
03-transactions.md
View File

@ -207,11 +207,11 @@ This gives us the following *expected weights* (details of the computation in [A
The fee for an HTLC-timeout transaction MUST BE calculated to match:
1. Multiply `feerate-per-kw` by 634 and divide by 1024 (rounding down).
1. Multiply `feerate-per-kw` by 634 and divide by 1000 (rounding down).
The fee for an HTLC-success transaction MUST BE calculated to match:
1. Multiply `feerate-per-kw` by 671 and divide by 1024 (rounding down).
1. Multiply `feerate-per-kw` by 671 and divide by 1000 (rounding down).
The fee for a commitment transaction MUST BE calculated to match:
@ -227,7 +227,7 @@ The fee for a commitment transaction MUST BE calculated to match:
transaction fee, then add 172 to `weight`, otherwise add
the HTLC amount to `fee`.
4. Multiply `feerate-per-kw` by `weight`, divide by 1024 (rounding down),
4. Multiply `feerate-per-kw` by `weight`, divide by 1000 (rounding down),
and add to `fee`.
#### Example