Sorry I may have shortened my initial post a bit too much with respect to the control valves section. As you pointed out the semantics of htlc_maximum_msat are clear in the sense that your node will not accept an hltc of a larger amount and indeed sending nodes will respect this in path or flow finding (though it is not clear what happens if a node tries to add a second HTLC with the same preimage that also respects htlc_maximum_msat).
However I have seen various motivations of why node operators select a specific value for htlc_maximum_msat for example
- I have seen node operators signaling the amount of liquidity that they have left in the channel (or a fraction of the remaining liquidity, such that they do not have to update the value after each successful routing).
- In my initial Blog article I suggested to use a markov process such that two peers that share a channel converge to a ratio of
htlc_maximum_msatvalues so that the expected flow through the channel is balanced - given the demand. That of course is a very different semantic than just selecting a fraction of the liquidity - In eclair it seems that you set the value to 0 if the channel is almost depleted and that you have various threasholds depending on the available liquidity. Also you seem to set the value to what you believe you can forward.
I am happy to hear that you an confirmed that a version of my suggestion works for you. I’d love to see some quantification for this. Maybe if it has sufficient interest from your end we could out of band discuss how we could measure and quantify this. Maybe it gives insights on weather this is sufficient or if other steps are necessary.
Yes that was exactly why I advocated for htlc_maximum_msat initially. It works out of the box without protocol upgrade which is extremely nice! However as in my first reply a protocol wide agreement on what nodes signal with their value may make this mechanism even stronger.