blip-0034: the recommended_feerates message
#34
Conversation
There was a problem hiding this comment.
I mean, sure, but I'm not really sure how I'd go about implementing this. Pre-Bitcoin Core 28 if I think the fee rate needed for confirmation/mempool acceptance is higher than the channel currently is, I need to update. Whether my peer said they think the fee rates are higher than I think or not I'm probably still gonna use the one I think I need? I guess a peer could tell me they require a fee rate a few % higher and I'd accept that too but the peer should at least accept an increase even if it's not a fee rate they think they need anyway?
More generally, the fix really should be Bitcoin Core 28, anchor channels, and no feerate enforcement.
| 2. data: | ||
| * [`chain_hash`:`chain_hash`] | ||
| * [`u32`:`funding_feerate_per_kw`] | ||
| * [`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 open_channel2.
I don't get what you mean here...sure, for the commitment feerate, this isn't very important once we have anchor channels. But for opening channels and creating splice transactions (funding feerate), you will have a specific confirmation target (especially when combined with 0-conf, which makes RBF impossible). In the LSP / mobile wallet case, the mobile wallet generally doesn't have access to its own Bitcoin Core instance, and doesn't know what confirmation target the LSP is using. So the LSP just tells the mobile wallet what feerate it will use when it initiates channel-open or splice, and the mobile wallet uses the same values when it is the initiator (e.g. swap-in or on-the-fly funding), which ensures that it will generally be accepted by the LSP. EDIT: reading your comment again, this probably comes from the fact that I mentioned |
|
Ah, okay, I understood this to be about |
I hesitated, mostly because the way I'm currently using this, it's not a real guarantee that the recommended feerates will be accepted (depending on how long you wait before initiating an on-chain funding based on those feerates). I felt that having a min/max may give a false assurance that it will be accepted so I decided to stick with the simplest one. But you're right, it's probably useful to change this to min/max/preferred and keep accepting them until the next |
t-bast
force-pushed
the
recommended-feerates
branch
from
4cd2bb9
to
f0a43ce
Compare
|
Done and rebased, I hope it's clearer now! |
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.
t-bast
force-pushed
the
recommended-feerates
branch
from
f0a43ce
to
38de574
Compare
|
|
||
| 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 |
There was a problem hiding this comment.
. Nodes receiving those messages are supposed to reject them if they are considered
too low or too high.
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.
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.
| 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 recommended_feerates_tlvs field below?
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 funding_feerate_per_kw field.
There was a problem hiding this comment.
Should this also be a min+max similar to the recommended_feerates_tlvs field below?
I don't understand what you mean...there is a min/max range defined (funding_feerate_range).
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.
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.
blip-0034.md
Outdated
|
|
||
| The receiver: | ||
|
|
||
| * SHOULD not send `open_channel`, `open_channel2`, `splice_init`, `tx_init_rbf` |
There was a problem hiding this comment.
Should add update_fee as well
There was a problem hiding this comment.
Done in 4cabcbf: the commit message explains why update_fee is a bit more complex, because it can involve funds safety.
It's a bit murky what to do for `update_fee`: if you think you have to update the feerate outside of the range your peer allows, you should still do it, because you're the one paying for it. Your peer is free to force-close if they're unhappy with that.
|
FYI, @vincenzopalazzo |
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 tell our peers the feerates we'd like to use.