mirror of
https://github.com/lightning/bolts.git
synced 2025-02-23 14:40:41 +01:00
BOLT 2: correct sat/Kb to sat/Kw conversion to avoid over paying (#176)
This commit fixes an advisory error in the current spec draft. We currently use `fee-per-kw` where `kw = 1000` weight to determine the proper fee to pay for commitment transactions. Currently, the spec advises implementer to take the typical sat/Kb at _multiply_ by 4. This will result in implementations overpaying for commitment transactions as the scaling should actually be in the _opposite_ direction. As the weight is scaled up by 4, for fee-per-kw should be scaled down by 4. So: sat/Kb * 1/4, instead of sat/Kb * 4. [Minor fixup: "1/4th" to "1/4", better english, and doesn't trip spellcheck. -- RR]
This commit is contained in:
parent
1b4195c842
commit
3a359c8e1e
1 changed files with 1 additions and 1 deletions
|
@ -111,7 +111,7 @@ The `temporary_channel_id` is used to identify this channel until the funding tr
|
|||
|
||||
`max_htlc_value_in_flight_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 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.
|
||||
`feerate_per_kw` indicates the initial fee rate by 1000-weight (ie. 1/4 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.
|
||||
|
||||
|
|
Loading…
Add table
Reference in a new issue