getting WIRE_EXPIRY_TOO_SOON

[dslingo]

Issue and Steps to Reproduce

./lightnig-cli sendpay "$route" id
and getting WIRE_EXPIRY_TOO_SOON from one of the peers
what is causing the error?

getinfo output

[cdecker]

Can you share a concrete example (route and error message returned by sendpay)?

This caused by one of the nodes along the route not being given a sufficient CLTV delta. This can be cause by a number of issues:

• Your node not being in sync with the bitcoin blockchain (compare blockheights from lightning-cli getinfo against the one from bitcoin-cli getblockchaininfo). This could also be temporary because a new block was found that we didn't see yet.
• The node has sent a channel_update that we haven't seen yet, thus we produce a small CLTV delta, or we have added the delta incorrectly
• The remote node did not advertise correctly
• This is the last hop, and we disagree on what the last hop should have as a CLTV delta.

I think it's most likely the first, but we'll need more information to confirm that.

[dslingo]

1. node is in sync with bitcoind

2. route i am using:
   [
   {
   "id": "0232e20e7b68b9b673fb25f48322b151a93186bffe4550045040673797ceca43cf",
   "channel": "555922:1422:1",
   "msatoshi": 2000,
   "delay": 14
   },
   {
   "id": "02ff275afd48040cd0d4a54f00c5cc3552a7152a89f3c089e290666104f04a3c2c",
   "channel": "550339:2606:1",
   "msatoshi": 1000,
   "delay": 14
   }
   ]

3. error code from logs:
   2018-12-30T13:31:53.565Z lightningd(7570): 0232e20e7b68b9b673fb25f48322b151a93186bffe4550045040673797ceca43cf chan Another reason for declining an htlc #5: HTLC out 36 SENT_REMOVE_ACK_COMMIT->RCVD_REMOVE_ACK_REVOCATION
   2018-12-30T13:31:53.566Z lightningd(7570): 0232e20e7b68b9b673fb25f48322b151a93186bffe4550045040673797ceca43cf chan Another reason for declining an htlc #5: Removing out HTLC 36 state RCVD_REMOVE_ACK_REVOCATION REMOTEFAIL
   2018-12-30T13:31:53.566Z lightningd(7570): 0232e20e7b68b9b673fb25f48322b151a93186bffe4550045040673797ceca43cf chan Another reason for declining an htlc #5: htlc 36 failed from 0th node with code 0x100e (WIRE_EXPIRY_TOO_SOON)
   2018-12-30T13:31:53.567Z lightningd(7570): Reporting route failure to gossipd: 0x100e (WIRE_EXPIRY_TOO_SOON) node 0232e20e7b68b9b673fb25f48322b151a93186bffe4550045040673797ceca43cf channel 550339:2606:1 update

4. note that destination node is not advertised at all, routing table was made based on data from invoice from r field then passed to sendpay command. I was trying different values of "delay" and still the same error

[dslingo]

why "pay" command doest work in case nonadvertised nodes (channels)? giving "could not find a route" error. Is it related to: /* FIXME: use b11->routes */ in payalgo.c?

[cdecker]

Ok, so the issue is the delay in both hops being identical. The CLTV delays accumulate along the route so this should really be 28 and 14 not 14 and 14.

I take it you are building these routes manually?

@rustyrussell is working on a plugin version of the pay command which will indeed take the routeboost routes into consideration.

[dslingo]

as i said i tryed different combinations of delay, 28->14, 14->9, 9->14, 128->9 and many others, all of them gives same error. Yes route is build manually based on r record from invoice. But is correct, destinantin node is connected to the same peer as my node, getroute gives common peer route info and destination channelid is in invoice.

[cdecker]

The intermediate node appears to be an lnd node, which requires a CLTV delta of 144, hence you probably need 144+9=153 and 9 as delays.

[dslingo]

i didnt try exactly 153 so should it be like that?:
[
{
"id": "0232e20e7b68b9b673fb25f48322b151a93186bffe4550045040673797ceca43cf",
"channel": "555922:1422:1",
"msatoshi": 2000,
"delay": 153
},
{
"id": "02ff275afd48040cd0d4a54f00c5cc3552a7152a89f3c089e290666104f04a3c2c",
"channel": "550339:2606:1",
"msatoshi": 1000,
"delay": 14
}
]

[dslingo]

intermediate node is zigzag.io and oryginally on getroute returns delay=9

[cdecker]

Could be that the fees do not match exactly in the route, but at least you'll get a different error 😉

getroute always returns 9 as a convention for the last hop, and since zigzag is the last hop when issuing getroute <zigzag_id> that'll be returned. The handling of the last hop is a bit special, listchannels is authoritative, so you should check that instead.

[dslingo]

yes, fees miss much gives different error. I will check delay values You mentioned and let You know.

[dslingo]

otherwise i have to jump into lnd and GOshit

[dslingo]

You said that @rustyrussell is working on plugin to handle nonannouced nodes pay transactions. Why it is solved as plugin and not in main code?

[cdecker]

The reason it is being done as a plugin is that the pay code contains a lot of places that a user might want to customize (automatically retrying payments, how long to wait before reporting a failure when auto-retrying, which routes to prefer, up to what level of fees should we auto-retry, should we fuzz the amount paid, should we fuzz the cltv deltas, should we prioritize direct channels, can we attempt to rebalance a channel while performing a payment, ...).

We will provide a sane default plugin, but clearly we also want to give users the ability to add their own logic, and give them the control they might want to have, hence the plugin which allows users to implement their own policies.

[ZmnSCPxj]

Is this issue still relevant?

[ZmnSCPxj]

Closing possibly-stale issue