Should the `htlc_maximum_msat` and `htlc_minimum_msat` fields in the `channel_update` be dynamic?

[cdecker]

During the discussion of #500 a disagreement about the wording was discovered. The spec currently states that while htlc_maximum_msat and htlc_minimum_msat fields are specified in each channel_update, they are effectively static, and cannot be updated.

It was proposed that the channel_update should be dynamic and allow the message creator to specify new values as necessary. This was previously prohibited in order to discourage leaking the current capacity of the channel, but could be relaxed with a warning.

[cryptagoras]

@cdecker imo htlc_minimum_msat (at least) should be dynamic. I'm mostly thinking with the Liq.Providers' interest in mind, but it will also help the overall liquidity health of network.

One current issue is that there is the possibility of channels being closed with the local_balance of the Liq.Provider being below the dust limit (after fees) which might end up erasing any profits or even causing losses.

One strategy that could be employed to manage this (among other flow optimizations) is to update dynamically the htlc_minimum_msat of a channel. A high-level strategy could be:

• if local_balance is below a level L, update htlc_minimum_msat to be make sure any new HTLC maintains the level L of the local_balance.
• if local_balance is above a comfortable level CL, then update htlc_minimum_msat to even 1msat to enable millisatoshi-level payment routing.

htlc_maximum_msat being dynamic will also allow better flow optimizations and help Liq.Providers construct more sophisticated systems for better flows.

[araspitzu]

It makes sense to use the channel_update messages to update something, just like a peer can use it to update its fee policy it should be able to update its relaying policy. htlc_maximum_msat is the only way that we have to limit the size of the HTLC we want to route, as such i believe nodes should be free to change it anytime. Regarding the privacy concerns we should note that a peer is not forced to update the htlc_maximum_msat at every change of balance, so perhaps the spec could advise peers to not follow this leaky behavior. We should also consider that using static fields in channel_update messages is quite inefficient as they are one of the most frequent gossip message, peers can still figure out the upper bound capacity of a channel by looking at the funding transaction.

[casey]

If htlc_maximum_msat can be updated, nodes would be able to raise it in response to DoS attacks or organically high network utilization, which seems useful.

[t-bast]

Yes, this something we want to make dynamic in the future. However it's currently hard to do so, because changing these values could make your current commitment invalid (if some htlcs don't match the updated parameters). When we last discussed this, it was the reason why we didn't fix this. We're now waiting for quiescence or some form of it to land to make it simpler to change these parameters.