<p>Both the <code>min_htlc_msat</code> and <code>max_htlc_msat</code> in this case are part of the channel policy for forwarding HTLCs. The parameters are communicated in the <a href="https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#the-channel_update-message" rel="nofollow noreferrer"><code>channel_update</code></a> message.</p>
<p>In LND, you set them with the <a href="https://github.com/lightningnetwork/lnd/blob/master/cmd/lncli/commands.go#L1987" rel="nofollow noreferrer"><code>updatechanpolicy</code></a> command.</p>

CC BY-SA 4.0
2023-01-16T08:18:06.627Z
2023-01-16T08:18:06.627Z
Mark H
<p>Using an arbitrarily chosen channel, the <code>getchaninfo</code> command returns a json object like this:</p>
<pre><code>$ lncli getchaninfo 848897743567126529
{
    &quot;channel_id&quot;: &quot;848897743567126529&quot;,
    &quot;chan_point&quot;: &quot;e39544821899c05499ed1c3271b6668aea90246bfe181b72d20463a6579496f4:1&quot;,
    &quot;last_update&quot;: 1673788833,
    &quot;node1_pub&quot;: &quot;025407ac7bd16419f4ae9e7827665c031323184514618c390278ec4a2708d3558f&quot;,
    &quot;node2_pub&quot;: &quot;03e865ea04a93245a0685e9dd5280514a9ff0d9162c3c3c004efab2636631229ef&quot;,
    &quot;capacity&quot;: &quot;5000000&quot;,
    &quot;node1_policy&quot;: {
        &quot;time_lock_delta&quot;: 34,
        &quot;min_htlc&quot;: &quot;1&quot;,
        &quot;fee_base_msat&quot;: &quot;0&quot;,
        &quot;fee_rate_milli_msat&quot;: &quot;842&quot;,
        &quot;disabled&quot;: false,
        &quot;max_htlc_msat&quot;: &quot;4950000000&quot;,
        &quot;last_update&quot;: 1673788833
    },
    &quot;node2_policy&quot;: {
        &quot;time_lock_delta&quot;: 40,
        &quot;min_htlc&quot;: &quot;1000&quot;,
        &quot;fee_base_msat&quot;: &quot;1000&quot;,
        &quot;fee_rate_milli_msat&quot;: &quot;300&quot;,
        &quot;disabled&quot;: false,
        &quot;max_htlc_msat&quot;: &quot;5000000000&quot;,
        &quot;last_update&quot;: 1673788419
    }
}
</code></pre>
<p>Excluding the <code>disabled</code> and <code>last_update</code> fields, there are 5 other fields that are specific to each node in the channel. It looks like four of these parameters are set from settings in <code>lnd.conf</code> as follows:</p>
<ul>
<li><code>time_lock_delta</code> = bitcoin.timelockdelta</li>
<li><code>min_htlc</code> = bitcoin.minhtlc</li>
<li><code>fee_base_msat</code> = bitcoin.basefee</li>
<li><code>fee_rate_milli_msat</code> = bitcoin.feerate</li>
</ul>
<p>But what about <code>max_htlc_msat</code>? I don't see anything in the <a href="https://docs.lightning.engineering/lightning-network-tools/lnd/lnd.conf" rel="nofollow noreferrer">lnd.conf documentation</a> that looks like it could be that field.</p>
<p>I thought it might be set at the time of opening the channel, but in looking at the help for the <code>openchannel</code> command, I don't see anything that looks like it would be <code>max_htlc_msat</code>.</p>
<pre><code>$ lncli help openchannel
NAME:
   lncli openchannel - Open a channel to a node or an existing peer.

USAGE:
   lncli openchannel [command options] node-key local-amt push-amt

CATEGORY:
   Channels

DESCRIPTION:
   
  Attempt to open a new channel to an existing peer with the key node-key
  optionally blocking until the channel is 'open'.

  One can also connect to a node before opening a new channel to it by
  setting its host:port via the --connect argument. For this to work,
  the node_key must be provided, rather than the peer_id. This is optional.

  The channel will be initialized with local-amt satoshis local and push-amt
  satoshis for the remote node. Note that specifying push-amt means you give that
  amount to the remote node as part of the channel opening. Once the channel is open,
  a channelPoint (txid:vout) of the funding output is returned.

  If the remote peer supports the option upfront shutdown feature bit (query
  listpeers to see their supported feature bits), an address to enforce
  payout of funds on cooperative close can optionally be provided. Note that
  if you set this value, you will not be able to cooperatively close out to
  another address.

  One can manually set the fee to be used for the funding transaction via either
  the --conf_target or --sat_per_vbyte arguments. This is optional.

OPTIONS:
   --node_key value                         the identity public key of the target node/peer serialized in compressed format
   --connect value                          (optional) the host:port of the target node
   --local_amt value                        the number of satoshis the wallet should commit to the channel (default: 0)
   --push_amt value                         the number of satoshis to give the remote side as part of the initial commitment state, this is equivalent to first opening a channel and sending the remote party funds, but done all in one step (default: 0)
   --block                                  block and wait until the channel is fully open
   --conf_target value                      (optional) the number of blocks that the transaction *should* confirm in, will be used for fee estimation (default: 0)
   --sat_per_vbyte value                    (optional) a manual fee expressed in sat/vbyte that should be used when crafting the transaction (default: 0)
   --private                                make the channel private, such that it won't be announced to the greater network, and nodes other than the two channel endpoints must be explicitly told about it to be able to route through it
   --min_htlc_msat value                    (optional) the minimum value we will require for incoming HTLCs on the channel (default: 0)
   --remote_csv_delay value                 (optional) the number of blocks we will require our channel counterparty to wait before accessing its funds in case of unilateral close. If this is not set, we will scale the value according to the channel size (default: 0)
   --max_local_csv value                    (optional) the maximum number of blocks that we will allow the remote peer to require we wait before accessing our funds in the case of a unilateral close. (default: 0)
   --min_confs value                        (optional) the minimum number of confirmations each one of your outputs used for the funding transaction must satisfy (default: 1)
   --close_address value                    (optional) an address to enforce payout of our funds to on cooperative close. Note that if this value is set on channel open, you will *not* be able to cooperatively close to a different address.
   --psbt                                   start an interactive mode that initiates funding through a partially signed bitcoin transaction (PSBT), allowing the channel funds to be added and signed from a hardware or other offline device.
   --base_psbt value                        when using the interactive PSBT mode to open a new channel, use this base64 encoded PSBT as a base and add the new channel output to it instead of creating a new, empty one.
   --no_publish                             when using the interactive PSBT mode to open multiple channels in a batch, this flag instructs lnd to not publish the full batch transaction just yet. For safety reasons this flag should be set for each of the batch's transactions except the very last
   --remote_max_value_in_flight_msat value  (optional) the maximum value in msat that can be pending within the channel at any given time (default: 0)
   --channel_type value                     (optional) the type of channel to propose to the remote peer (&quot;tweakless&quot;, &quot;anchors&quot;)
   --zero_conf                              (optional) whether a zero-conf channel open should be attempted.
   --scid_alias                             (optional) whether a scid-alias channel type should be negotiated.
</code></pre>
<p>The <code>openchannel</code> command includes a <code>min_htlc_msat</code> parameter, but no <code>max_htlc_msat</code> parameter. So where does that value come from?</p>

<lightning-network><lightning-network-daemon>
Where does the max_htlc_msat field in the getchaninfo results come from?
Zephyrus
# Where does the max_htlc_msat field in the getchaninfo results come from?

(Asked by: username_0 on 2023-01-15)

Using an arbitrarily chosen channel, the `getchaninfo` command returns a json object like this:

```
$ lncli getchaninfo 848897743567126529
{
    "channel_id": "848897743567126529",
    "chan_point": "e39544821899c05499ed1c3271b6668aea90246bfe181b72d20463a6579496f4:1",
    "last_update": 1673788833,
    "node1_pub": "025407ac7bd16419f4ae9e7827665c031323184514618c390278ec4a2708d3558f",
    "node2_pub": "03e865ea04a93245a0685e9dd5280514a9ff0d9162c3c3c004efab2636631229ef",
    "capacity": "5000000",
    "node1_policy": {
        "time_lock_delta": 34,
        "min_htlc": "1",
        "fee_base_msat": "0",
        "fee_rate_milli_msat": "842",
        "disabled": false,
        "max_htlc_msat": "4950000000",
        "last_update": 1673788833
    },
    "node2_policy": {
        "time_lock_delta": 40,
        "min_htlc": "1000",
        "fee_base_msat": "1000",
        "fee_rate_milli_msat": "300",
        "disabled": false,
        "max_htlc_msat": "5000000000",
        "last_update": 1673788419
    }
}

```

Excluding the `disabled` and `last_update` fields, there are 5 other fields that are specific to each node in the channel. It looks like four of these parameters are set from settings in `lnd.conf` as follows:

* `time_lock_delta` = bitcoin.timelockdelta
* `min_htlc` = bitcoin.minhtlc
* `fee_base_msat` = bitcoin.basefee
* `fee_rate_milli_msat` = bitcoin.feerate

But what about `max_htlc_msat`? I don't see anything in the [lnd.conf documentation](https://docs.lightning.engineering/lightning-network-tools/lnd/lnd.conf) that looks like it could be that field.

I thought it might be set at the time of opening the channel, but in looking at the help for the `openchannel` command, I don't see anything that looks like it would be `max_htlc_msat`.

```
$ lncli help openchannel
NAME:
   lncli openchannel - Open a channel to a node or an existing peer.

USAGE:
   lncli openchannel [command options] node-key local-amt push-amt

CATEGORY:
   Channels

DESCRIPTION:
   
  Attempt to open a new channel to an existing peer with the key node-key
  optionally blocking until the channel is 'open'.

  One can also connect to a node before opening a new channel to it by
  setting its host:port via the --connect argument. For this to work,
  the node_key must be provided, rather than the peer_id. This is optional.

  The channel will be initialized with local-amt satoshis local and push-amt
  satoshis for the remote node. Note that specifying push-amt means you give that
  amount to the remote node as part of the channel opening. Once the channel is open,
  a channelPoint (txid:vout) of the funding output is returned.

  If the remote peer supports the option upfront shutdown feature bit (query
  listpeers to see their supported feature bits), an address to enforce
  payout of funds on cooperative close can optionally be provided. Note that
  if you set this value, you will not be able to cooperatively close out to
  another address.

  One can manually set the fee to be used for the funding transaction via either
  the --conf_target or --sat_per_vbyte arguments. This is optional.

OPTIONS:
   --node_key value                         the identity public key of the target node/peer serialized in compressed format
   --connect value                          (optional) the host:port of the target node
   --local_amt value                        the number of satoshis the wallet should commit to the channel (default: 0)
   --push_amt value                         the number of satoshis to give the remote side as part of the initial commitment state, this is equivalent to first opening a channel and sending the remote party funds, but done all in one step (default: 0)
   --block                                  block and wait until the channel is fully open
   --conf_target value                      (optional) the number of blocks that the transaction *should* confirm in, will be used for fee estimation (default: 0)
   --sat_per_vbyte value                    (optional) a manual fee expressed in sat/vbyte that should be used when crafting the transaction (default: 0)
   --private                                make the channel private, such that it won't be announced to the greater network, and nodes other than the two channel endpoints must be explicitly told about it to be able to route through it
   --min_htlc_msat value                    (optional) the minimum value we will require for incoming HTLCs on the channel (default: 0)
   --remote_csv_delay value                 (optional) the number of blocks we will require our channel counterparty to wait before accessing its funds in case of unilateral close. If this is not set, we will scale the value according to the channel size (default: 0)
   --max_local_csv value                    (optional) the maximum number of blocks that we will allow the remote peer to require we wait before accessing our funds in the case of a unilateral close. (default: 0)
   --min_confs value                        (optional) the minimum number of confirmations each one of your outputs used for the funding transaction must satisfy (default: 1)
   --close_address value                    (optional) an address to enforce payout of our funds to on cooperative close. Note that if this value is set on channel open, you will *not* be able to cooperatively close to a different address.
   --psbt                                   start an interactive mode that initiates funding through a partially signed bitcoin transaction (PSBT), allowing the channel funds to be added and signed from a hardware or other offline device.
   --base_psbt value                        when using the interactive PSBT mode to open a new channel, use this base64 encoded PSBT as a base and add the new channel output to it instead of creating a new, empty one.
   --no_publish                             when using the interactive PSBT mode to open multiple channels in a batch, this flag instructs lnd to not publish the full batch transaction just yet. For safety reasons this flag should be set for each of the batch's transactions except the very last
   --remote_max_value_in_flight_msat value  (optional) the maximum value in msat that can be pending within the channel at any given time (default: 0)
   --channel_type value                     (optional) the type of channel to propose to the remote peer ("tweakless", "anchors")
   --zero_conf                              (optional) whether a zero-conf channel open should be attempted.
   --scid_alias                             (optional) whether a scid-alias channel type should be negotiated.

```

The `openchannel` command includes a `min_htlc_msat` parameter, but no `max_htlc_msat` parameter. So where does that value come from?

**Tags:** lightning-network, lightning-network-daemon


---

## 1 answers

### Answer by username_1 on 2023-01-16. Score: 0 | Accepted answer

Both the `min_htlc_msat` and `max_htlc_msat` in this case are part of the channel policy for forwarding HTLCs. The parameters are communicated in the [`channel_update`](https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#the-channel_update-message) message.

In LND, you set them with the [`updatechanpolicy`](https://github.com/lightningnetwork/lnd/blob/master/cmd/lncli/commands.go#L1987) command.


---

