blip-0034: the recommended_feerates message
#34
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,123 @@ | ||
| ``` | ||
| bLIP: 34 | ||
| Title: The `recommended_feerates` message | ||
| Status: Active | ||
| Author: Bastien Teinturier <[email protected]> | ||
| Created: 2024-07-02 | ||
| License: CC0 | ||
| ``` | ||
|
|
||
| ## Abstract | ||
|
|
||
| Many lightning messages include feerates for on-chain transactions. Nodes | ||
| receiving those messages are supposed to reject them if they are considered | ||
| too low or too high. However, there is no mechanism to let peers know which | ||
| feerates we currently find acceptable, which leads to frequent failures, | ||
| especially when the mempool feerates fluctuate quickly. | ||
|
|
||
| We introduce an optional message to advertise to our peers the feerates we'd | ||
| like to use when funding new or existing channels. | ||
|
|
||
| ## Copyright | ||
|
|
||
| This bLIP is licensed under the CC0 license. | ||
|
|
||
| ## Motivation | ||
|
|
||
| This feature is particularly useful when mobile wallets initiate channel | ||
| operations with their service provider: in most cases, they should use what | ||
| the service provider recommends since they don't have access to a full node | ||
| and the service provider would reject unacceptable feerates anyway. | ||
|
|
||
| ## Specification | ||
|
|
||
| ### The `recommended_feerates` message | ||
|
|
||
| 1. type: 39409 (`recommended_feerates`) | ||
| 2. data: | ||
| * [`chain_hash`:`chain_hash`] | ||
| * [`u32`:`funding_feerate_per_kw`] | ||
|
There was a problem hiding this comment. Should this also be a min+max similar to the There was a problem hiding this comment. Also I wonder if it's useful for the desired use case if this is always communicating as a mapping from conf target to the fee rate. Otherwise, it's unclear what type of confirmation delay the sender is comfortable with when they send their There was a problem hiding this comment.
I don't understand what you mean...there is a min/max range defined (
Good question. I don't think it's useful here, since the only thing you want to know is whether your peer will accept the feerate you set, and BOLT messages don't use a conf target but rather feerates. But it could be informative to have an optional TLV containing the confirmation target the sending node is using, I could add that if you think that's really useful (I'm not sure it is). Or we could add it later if we find it useful. |
||
| * [`u32`:`commitment_feerate_per_kw`] | ||
|
There was a problem hiding this comment. As a recipient I don't really care what value you would set, I care what value(s) you would reject. There was a problem hiding this comment. This is useful when combined with blip 33, where the non-opener is paying the commit fees: they can tell the opener what feerate they will accept in |
||
|
|
||
| 1. `tlv_stream`: `recommended_feerates_tlvs` | ||
| 2. types: | ||
| 1. type: 1 (`funding_feerate_range`) | ||
| 2. data: | ||
| * [`u32`:`min_funding_feerate_per_kw`] | ||
| * [`u32`:`max_funding_feerate_per_kw`] | ||
| 1. type: 3 (`commitment_feerate_range`) | ||
| 2. data: | ||
| * [`u32`:`min_commitment_feerate_per_kw`] | ||
| * [`u32`:`max_commitment_feerate_per_kw`] | ||
|
|
||
| ### Requirements | ||
|
|
||
| The sender: | ||
|
|
||
| * SHOULD frequently send `recommended_feerates` with feerates it currently | ||
| accepts for channel funding operations. | ||
| * SHOULD set `funding_feerate_per_kw` to the feerate it uses for funding | ||
| channels. | ||
| * SHOULD set `funding_feerate_range` to the range of acceptables feerates | ||
| for funding channels. | ||
| * SHOULD set `commitment_feerate_per_kw` to the feerate it uses for channel | ||
| commitment transactions. | ||
| * SHOULD set `commitment_feerate_range` to the range of acceptables feerates | ||
| for channel commitment transactions. | ||
| * SHOULD accept feerates that are inside the ranges it advertised. | ||
|
|
||
| The receiver: | ||
|
|
||
| * SHOULD NOT send `open_channel`, `open_channel2`, `splice_init`, `tx_init_rbf` | ||
| or other channel funding messages using feerates that are outside of the | ||
| advertised ranges. | ||
| * SHOULD NOT send `update_fee` using feerates that are outside of the | ||
| advertised range, unless it is necessary to guarantee the safety of its | ||
| channel funds. | ||
|
|
||
| ### Rationale | ||
|
|
||
| While it won't guarantee success every time, taking into account our peer's | ||
| recommended feerates reduces the frequency of failures when funding channels. | ||
|
|
||
| ### Test vectors | ||
|
|
||
| The following test vectors describe how the `recommended_feerates` message is | ||
| encoded: | ||
|
|
||
| ```json | ||
| [ | ||
| { | ||
| "recommended_feerates": { | ||
| "chain": "testnet3", | ||
| "funding_feerate_per_kw": "2500 sat/kw", | ||
| "commitment_feerate_per_kw": "2500 sat/kw" | ||
| }, | ||
| "encoded": "99f1 43497fd7f826957108f4a30fd9cec3aeba79972084e90ead01ea330900000000 000009c4 000009c4" | ||
| }, | ||
| { | ||
| "recommended_feerates": { | ||
| "chain": "testnet3", | ||
| "funding_feerate_per_kw": "5000 sat/kw", | ||
| "commitment_feerate_per_kw": "253 sat/kw" | ||
| }, | ||
| "encoded": "99f1 43497fd7f826957108f4a30fd9cec3aeba79972084e90ead01ea330900000000 00001388 000000fd" | ||
| }, | ||
| { | ||
| "recommended_feerates": { | ||
| "chain": "testnet3", | ||
| "funding_feerate_per_kw": "10000 sat/kw", | ||
| "min_funding_feerate_per_kw": "5000 sat/kw", | ||
| "max_funding_feerate_per_kw": "15000 sat/kw", | ||
| "commitment_feerate_per_kw": "1000 sat/kw", | ||
| "min_commitment_feerate_per_kw": "253 sat/kw", | ||
| "max_commitment_feerate_per_kw": "2000 sat/kw" | ||
| }, | ||
| "encoded": "99f1 43497fd7f826957108f4a30fd9cec3aeba79972084e90ead01ea330900000000 00002710 000003e8 01080000138800003a98 0308000000fd000007d0" | ||
| } | ||
| ] | ||
| ``` | ||
|
|
||
| ## Reference Implementations | ||
|
|
||
| * eclair: <https://github.com/ACINQ/eclair/pull/2860> | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We currently don't have any way to reject the fee updates though, other than force closing, which then locks you into a potentially undesirable fee (pre and post anchors, before package relay).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, but what does that have to do with this proposal? This introduction simply states that the BOLTs tell you to reject messages with offending feerates (where we don't really care what "reject" is) but doesn't give you tools to avoid creating a message with an offending feerate, which motivates this bLIP.