Why is last channel's expiry different in Lightning Network Routes?

Question

Both in the Basic of Lightning Technology (BOLT) documents, and in the specification of lnd, there is a different treatment for the last channel in a route. In BOLT#2 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?

Answer 1

After some searching through the BOLT documents and talking with the lnd slack 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