<p>After some searching through the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md" rel="noreferrer">BOLT</a> documents and talking with the lnd <a href="https://lightningcommunity.slack.com/" rel="noreferrer">slack</a> community, I found an answer:</p>

<blockquote>
  <p>B->C. If B were to send 4,999,999 millisatoshi directly to C, it would
  neither charge itself a fee nor add its own cltv_expiry_delta, so it
  would use C's requested min_final_cltv_expiry of 9. Presumably it
  would also add a shadow route to give an extra CLTV of 42.
  Additionally, it could add extra CLTV deltas at other hops, as these
  values represent a minimum, but chooses not to do so here, for the
  sake of simplicity:</p>
</blockquote>

<p>Also, although <code>cltv_expiry_delta</code> is default to 9 in BOLT, in <code>lnd</code> they use 144, but without checking for the final hop. That is, they do not add the <code>final_cltv_expiry</code> because they have already a big <code>cltv_expiry</code> (I presume). Olaoluwa said in the slack 
that they plan to reduce the value of <code>cltv_expiry_delta</code> to get closer to the default value listed in BOLT. However, if they do this, I hope they take care of adding the additional <code>cltv_expiry_delta</code>, as it will be important to add in this case. For an example of what I mean, check the above-linked link for BOLT #007</p>

CC BY-SA 4.0
2018-11-30T11:20:12.897Z
2018-11-30T11:20:12.897Z
ranchalp
<p>Both in the Basic of Lightning Technology (<a href="https://github.com/lightningnetwork/lightning-rfc" rel="noreferrer">BOLT</a>) documents, and in the specification of lnd, there is a different treatment for the last channel in a route. In <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md" rel="noreferrer">BOLT#2</a> it refers to a variable <code>min_final_cltv_expiry</code>:</p>

<blockquote>
  <p><code>min_final_cltv_expiry</code> is the minimum difference between HTLC CLTV timeout and the current
  block height, for the terminal case (C).</p>
</blockquote>

<p>This value is 9, as opposed to 144 for <code>cltv_expiry_delta</code>.</p>

<p>This is most likely related with the output of a route when querying lnd, for example, suppose the route Alice -> Bob -> Carol -> Dave, routed from Alice:
the output is:</p>

<pre><code>$&gt; lncli-alice queryroutes --dest=&lt;Carol_pubkey&gt; --amt=5 --num_max_routes=1
total_time_lock: 1443640
total_fees: 1
total_amt: 6
hops {
  chan_id: &lt;id_chan_alice_bob&gt;
  chan_capacity: &lt;cap&gt;
  amt_to_forward: 6
  expiry: 1443610
  amt_to_forward_msat: 6000
  fee_msat: 1
}
hops {
  chan_id: &lt;id_chan_bob_carol&gt;
  chan_capacity: &lt;cap&gt;
  amt_to_forward: 5
  fee: 1
  expiry: 1443466
  amt_to_forward_msat: 5000
  fee_msat: 1000
}
hops {
  chan_id: &lt;id_chan_carol_dave&gt;
  chan_capacity: &lt;cap&gt;
  amt_to_forward: 5
  expiry: 1443466
  amt_to_forward_msat: 5000
}
total_fees_msat: 1001
total_amt_msat: 6001
</code></pre>

<p>Notice the last two hops have the same <code>expiry</code> value. Why is the last hop different with regard to the expiry?</p>

<lightning-network><lightning-network-daemon><lightning-routing><lightning-rfc>
Why is last channel's expiry different in Lightning Network Routes?
ranchalp
# Why is last channel's expiry different in Lightning Network Routes?

(Asked by: username_0 on 2018-11-14)

Both in the Basic of Lightning Technology ([BOLT](https://github.com/lightningnetwork/lightning-rfc)) documents, and in the specification of lnd, there is a different treatment for the last channel in a route. In [BOLT#2](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md) it refers to a variable `min_final_cltv_expiry`:

> `min_final_cltv_expiry` is the minimum difference between HTLC CLTV timeout and the current
> block height, for the terminal case (C).

This value is 9, as opposed to 144 for `cltv_expiry_delta`.

This is most likely related with the output of a route when querying lnd, for example, suppose the route Alice -> Bob -> Carol -> Dave, routed from Alice:
the output is:

```
$> lncli-alice queryroutes --dest=<Carol_pubkey> --amt=5 --num_max_routes=1
total_time_lock: 1443640
total_fees: 1
total_amt: 6
hops {
  chan_id: <id_chan_alice_bob>
  chan_capacity: <cap>
  amt_to_forward: 6
  expiry: 1443610
  amt_to_forward_msat: 6000
  fee_msat: 1
}
hops {
  chan_id: <id_chan_bob_carol>
  chan_capacity: <cap>
  amt_to_forward: 5
  fee: 1
  expiry: 1443466
  amt_to_forward_msat: 5000
  fee_msat: 1000
}
hops {
  chan_id: <id_chan_carol_dave>
  chan_capacity: <cap>
  amt_to_forward: 5
  expiry: 1443466
  amt_to_forward_msat: 5000
}
total_fees_msat: 1001
total_amt_msat: 6001

```

Notice the last two hops have the same `expiry` value. Why is the last hop different with regard to the expiry?

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


---

## 1 answers

### Answer by username_0 on 2018-11-30. Score: 7 | Accepted answer

After some searching through the [BOLT](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md) documents and talking with the lnd [slack](https://lightningcommunity.slack.com/) community, I found an answer:

> B->C. If B were to send 4,999,999 millisatoshi directly to C, it would
> neither charge itself a fee nor add its own cltv\_expiry\_delta, so it
> would use C's requested min\_final\_cltv\_expiry of 9. Presumably it
> would also add a shadow route to give an extra CLTV of 42.
> Additionally, it could add extra CLTV deltas at other hops, as these
> values represent a minimum, but chooses not to do so here, for the
> sake of simplicity:

Also, although `cltv_expiry_delta` is default to 9 in BOLT, in `lnd` they use 144, but without checking for the final hop. That is, they do not add the `final_cltv_expiry` because they have already a big `cltv_expiry` (I presume). Olaoluwa said in the slack
that they plan to reduce the value of `cltv_expiry_delta` to get closer to the default value listed in BOLT. However, if they do this, I hope they take care of adding the additional `cltv_expiry_delta`, as it will be important to add in this case. For an example of what I mean, check the above-linked link for BOLT #007


---

