lightning
blip-0034: the `recommended_feerates` message
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.
More generally, the fix really should be Bitcoin Core 28, anchor channels, and no feerate enforcement.
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 update_fee? And it's true that for update_fee, it probably doesn't make much sense, because you wouldn't really know how to handle that information. I'm currently using this only for open_channel2 and splice_init, I probably should remove the mention of update_fee and clarify that?
Ah, okay, I understood this to be about update_fee, indeed, rather than channel open and splicing. Indeed, IMO we should drop the reference to update_fee. However, I still don't think this is as useful as it should be - you say "nodes receiving those messages are supposed to reject them if they are considered too low or too high" but the spec here doesn't provide the range which a peer will accept. Why not send the min/max you'll accept explicitly here?
Why not send the min/max you'll accept explicitly here?
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 recommended_feerates is issued, this would be more thorough. I'll change my implementation and will update this bLIP.
