Attempting a cooperative close results in an unwanted force close if there are pending HTLCs

[merehap]

I opened a node between my Eclair mobile wallet and my (well-connected) LND node, and made multiple Lightning transactions using my Eclair wallet (through my LND node). One of these transactions got stuck in the pending state for three days at which point I decided to attempt to cooperatively close the channel (for unrelated reasons). At this point the cooperative close failed due to still having a pending HTLC (LND detected this and decided to error out). Upon the cooperative close failing, a force close was initiated without prompting me.

So there appear to be four issues here:

1. It is unclear to the user why the HTLC went pending rather than resolving almost immediately.
2. It doesn't seem like a standard HTLC should stay pending indefinitely (or at least for 3 days).
3. It doesn't seem like a cooperative close should be attempted at all if there are still pending HTLCs (both from a user experience perspective and so as to not rely on the peer to do validation).
4. It doesn't seem like a force close should be initiated without the user's permission.

Note I made several similar payments to the payment that triggered the pending HTLC that all went through, and unfortunately I don't have error logs from when it first went into pending. I assume that some random network condition or similar triggered the problem.

Here's the invoice associated with the pending htlc:

{ "destination": "03a9d79bcfab7feb0f24c3cd61a57f0f00de2225b6d31bce0bc4564efa3b1b5aaf", "payment_hash": "96e0fbc598f17f34240ccca3b14db836e2b0cb53ff101ab552bce29e66ce8377", "num_satoshis": "1004", "timestamp": "1522974543", "expiry": "3600", "description": "Coinpanic Community Jar", "description_hash": "", "fallback_addr": "", "cltv_expiry": "144" }

Is there any other information I can provide here?

[pm47]

I think what you are observing is the expected behavior:

It is unclear to the user why the HTLC went pending rather than resolving almost immediately.

This can happen if any node in the route, or even the final node becomes unresponding, there is nothing eclair-wallet can do in that case but wait for the htlc to timeout

It doesn't seem like a standard HTLC should stay pending indefinitely (or at least for 3 days).

In practice the timeout depends on the number of peers in the route, typically 144 blocks per peer currently (this may be reduced in the future when the network gains confidence).

It doesn't seem like a cooperative close should be attempted at all if there are still pending HTLCs (both from a user experience perspective and so as to not rely on the peer to do validation).

Spec explicitely allows it. The fact that LND decides to unilaterally close when there are pending htlcs is an implementation choice. Eclair would have waited in SHUTDOWN state until the htlc times out.

It doesn't seem like a force close should be initiated without the user's permission.

You can't decide when your counterparty will decide to force close on you (force close can be local or remote). In the remote case you get your money back immediately (except for htlcs which are refunded after they expire).

[merehap]

OK, makes sense on the first three points, though there should be a way to communicate to the user that they won't be getting their funds back for a while (it seemed to me like it was stuck indefinitely, as an example of user confusion).

For the fourth point, I don't think it was the counterparty that closed the channel, I think it was Eclair.

Here's the LND logs that make me conclude this, specifically the last two lines:

2018-04-08 11:51:58.492 [ERR] PEER: unable to respond to remote close msg: cannot co-op close channel w/ active htlcs 2018-04-08 11:52:27.297 [INF] DISC: Broadcasting batch of 74 new announcements 2018-04-08 11:52:36.864 [INF] NTFN: Dispatching spend notification for outpoint=63065eb97aa23600176b3ef9e7ab46f2aa524263199da0c160939f9e8102a6d5:0 2018-04-08 11:52:36.870 [WRN] CNCT: Unprompted commitment broadcast for ChannelPoint(63065eb97aa23600176b3ef9e7ab46f2aa524263199da0c160939f9e8102a6d5:0) 2018-04-08 11:52:36.871 [INF] CNCT: Unilateral close of ChannelPoint(63065eb97aa23600176b3ef9e7ab46f2aa524263199da0c160939f9e8102a6d5:0) detected 2018-04-08 11:52:37.012 [INF] CNCT: ChannelArbitrator(63065eb97aa23600176b3ef9e7ab46f2aa524263199da0c160939f9e8102a6d5:0): remote party has closed channel out on-chain

[pm47]

For the fourth point, I don't think it was the counterparty that closed the channel, I think it was Eclair.

Oh, I misread your statement.

At this point the cooperative close failed due to still having a pending HTLC

What makes you think that?

[merehap]

The first LND log line above is

2018-04-08 11:51:58.492 [ERR] PEER: unable to respond to remote close msg: cannot co-op close channel w/ active htlcs

So LND rejected cooperative channel closure due to there being a pending htlc, and Eclair initiated a force closure as a result.