payment failed due to 'expiry too big'

[84adam]

payment failed, no money sent, while trying to send from phoenix to muun

error: cannot add htlc with origin=Local(<REDACTED>,Some(Actor[akka://system/user/$k/payment-initiator/$a/$f#-<REDACTED>])) reason=expiry too big: maximum=CltvExpiry(####12) actual=CltvExpiry(####16) blockCount=####04

any suggestions? does the original (unwrapped) invoice expiry need to match the wrapped expiry?

[lnproxy]

Interesting error.. do muun invoices have an unusually long min_final_cltv_expiry? Unfortunately, lnproxy needs it to be relatively short. See here for an explanation:

https://stacker.news/items/73416

Would you mind sharing another invoice from the wallet? Or, for better privacy, maybe just the output of an invoice parser (e.g. lncli decodepayreq or lightningdecoder.com) with the sensitive data redacted?

[Reckless-Satoshi]

The cause of this Phoenix error is their very tight management of maximum CLTVexpiry (ACINQ manages the channels and they are interested on not getting these channels locked for long periods).

This can only be solved if the first portion of the route from Phoenix -> Lnproxy fits within the blockcount Phoenix limits. The reason it failed most likely is due to a very large CLTV expiry for the final hop of the invoice towards the Lnproxy server (the hodl invoice). The second portion of the route (Lnproxy -> Muun) is not causing this issue (unless the wrapped invoice perfectly mirrors the CLTVexpiry of the original invoice without adding any extra blocks... then the problem is Muun's invoice :D).

We documented a similar issue when Phoenix users try to lock bonds in RoboSats (https://learn.robosats.com/docs/wallets/#phoenix-mobile). It seems Phoenix maximum CLTV is around ~450 blocks

[lnproxy]

This make sense. The current implementation requests a large CLTV expiry (https://github.com/lnproxy/lnproxy/blob/423723b58cc45daa2fdf6c8b22537d560aca4d7a/lnproxy.go#L146) and if Phoenix's max is low then it will not accept lnproxy invoices. The solution might be found in the probing approach (https://github.com/niteshbalusu11/lnproxy-ts) since then you can ask for a CLTV expiry only as large as strictly needed to complete the hodl invoice circuit without putting funds at risk.

I have been waffling on implementing probing since it seems like it would create a DoS vector, but there is no question that it would improve UX.

[lnproxy]

https://github.com/lnproxy/lnproxy/commit/6bcc8dd495d8f6c4bb4a2690e7526c9ff55cba8d should fix this, feel free to reopen if problem persists