<p>Channel parameters (in some implementations called channel policies) are usually set for the outgoing channels. This may change to some degree with the way how some implementations try to push for inbound routing fees (which obviously have to be announced for inbound channels).</p>
<p>Also, on a more meta-level, I note that changing of your available liquidity in real-time may not work as peers will not forward that many <code>channel_update</code> messages. As the semantics of <code>max_htlc_msat</code> are clear and sending nodes respect those during the planning phase of payment routing, <a href="https://blog.bitmex.com/the-power-of-htlc_maximum_msat-as-a-control-valve-for-better-flow-control-improved-reliability-and-lower-expected-payment-failure-rates-on-the-lightning-network/" rel="nofollow noreferrer">I have previously suggested to find a more stable pair of values that you and your channel partner negotiate to statistically produce a balanced channel</a>. However, such a negotiation protocol has not been implemented yet as part of the protocol. Thus, you are back to square one with your observation that you cannot control the inbound value of this parameter.</p>

CC BY-SA 4.0
2023-10-09T19:51:19.683Z
Thanks! I was expecting the answer, but suddenly found it strange that if we ca set max htlc for our channel, we should be able to set it for both directions. My channel updates only update at most 1 max_htlc value for a single channel per hour, so generally the info is up to date enough. That article about valves was one of the few that motivated me to try tuning here, so thanks again!
bartoli
CC BY-SA 4.0
2023-10-09T15:04:27.983Z
2023-10-11T16:57:53.103Z
2023-10-11T16:57:53.103Z
Rene Pickhardt
<p>I'm currently setting max_htlc_msat value of my channels to a value similar to their curent local balance, in order to get hints about the max it can curently route (outbound).
Indeed, this made disappear the routing error 'unsufficients fee to route HTLC' because remote nodes don't even try to route when it wouldn't go through (when my outbound channel does not have enough liquidity on my side to send to the next hop).</p>
<p>But now, i realized that when a route succeeds, there is a HTLC for it on each channel. So would'nt it make sense that my value of this setting for the other channel is also checked, regardless of the direction (meaning the max htlc is the smallest value for the param of the values of each peer of the channel)?</p>
<p>Consider the case where a channel has everything in local balance, and the other has everything in remote balance. By limiting the outbound channel to a very low max_htlc_msat value, am i not also limiting the HTLC that would go the other way, so i am actually getting the channel 'stuck' because it also wouldn't be able to route big transactions in the direction that would rebalance the channels?</p>

<lightning-network><hash-time-locked-contract>
Is a channel's 'max_htlc_msat' setting only for outbound HTLCs, or for both sides?
bartoli
# Is a channel's 'max_htlc_msat' setting only for outbound HTLCs, or for both sides?

(Asked by: username_0 on 2023-10-09)

I'm currently setting max\_htlc\_msat value of my channels to a value similar to their curent local balance, in order to get hints about the max it can curently route (outbound).
Indeed, this made disappear the routing error 'unsufficients fee to route HTLC' because remote nodes don't even try to route when it wouldn't go through (when my outbound channel does not have enough liquidity on my side to send to the next hop).

But now, i realized that when a route succeeds, there is a HTLC for it on each channel. So would'nt it make sense that my value of this setting for the other channel is also checked, regardless of the direction (meaning the max htlc is the smallest value for the param of the values of each peer of the channel)?

Consider the case where a channel has everything in local balance, and the other has everything in remote balance. By limiting the outbound channel to a very low max\_htlc\_msat value, am i not also limiting the HTLC that would go the other way, so i am actually getting the channel 'stuck' because it also wouldn't be able to route big transactions in the direction that would rebalance the channels?

**Tags:** lightning-network, hash-time-locked-contract


---

## 1 answers

### Answer by username_1 on 2023-10-09. Score: 2 | Accepted answer

Channel parameters (in some implementations called channel policies) are usually set for the outgoing channels. This may change to some degree with the way how some implementations try to push for inbound routing fees (which obviously have to be announced for inbound channels).

Also, on a more meta-level, I note that changing of your available liquidity in real-time may not work as peers will not forward that many `channel_update` messages. As the semantics of `max_htlc_msat` are clear and sending nodes respect those during the planning phase of payment routing, [I have previously suggested to find a more stable pair of values that you and your channel partner negotiate to statistically produce a balanced channel](https://blog.bitmex.com/the-power-of-htlc_maximum_msat-as-a-control-valve-for-better-flow-control-improved-reliability-and-lower-expected-payment-failure-rates-on-the-lightning-network/). However, such a negotiation protocol has not been implemented yet as part of the protocol. Thus, you are back to square one with your observation that you cannot control the inbound value of this parameter.

> **Comments:**
> **username_0**: Thanks! I was expecting the answer, but suddenly found it strange that if we ca set max htlc for our channel, we should be able to set it for both directions. My channel updates only update at most 1 max_htlc value for a single channel per hour, so generally the info is up to date enough. That article about valves was one of the few that motivated me to try tuning here, so thanks again!  

---

