Add quiescence

[remyers]

Porting quiescence PR from Eclair.

[remyers]

This is still in progress while I work out some issues with the last two tests related to what happens when an incoming htlc is about to timeout while quiescent.

[remyers]

This is still in progress while I work out some issues with the last two tests related to what happens when an incoming htlc is about to timeout while quiescent.

I believe the correct solution for htlcs that timeout is that on disconnect/reconnect or when quiescence ends, incoming htlcs are processed by the peer. If they are close to timing out, they will be failed at that point.

[t-bast]

I think the HTLC reprocessing is actually simpler than what you thought, see one of my comments.

[remyers]

I noticed while working on the test receive SpliceInit when channel is not quiescent that currently our peer can send SpliceInit immediately without negotiating quiescence first and if the peers are idle, it will not reject it. I can't think of a reason to reject SpliceInit in this situation except that it means something is wrong with your peer.

[remyers]

I noticed while working on the test receive SpliceInit when channel is not quiescent that currently our peer can send SpliceInit immediately without negotiating quiescence first and if the peers are idle, it will not reject it. I can't think of a reason to reject SpliceInit in this situation except that it means something is wrong with your peer.

Fixed in ef52264. I'll also make this change in the Eclair PR with feedback from this PR.

[remyers]

Is it correct that if our pending outoing htlc times out, we should force close during a splice? This is new situation we didn't have to consider before quiescence. It seems like the risk is on the htlc receiver's side so we shouldn't need to do a preemptive force close. We might have an unprocessed htlc success or fail that came in while we were quiescent. Since our node must be the source of the htlc, we don't risk our upstream force closing on us.

[t-bast]

It seems like the risk is on the htlc receiver's side so we shouldn't need to do a preemptive force close.

That's a very good point, in theory we wouldn't need to force-close, even if the HTLC has expired, because we have no funds at risk.

There are two different cases here:

• Our peer has the preimage for that HTLC
• Our peer doesn't have the preimage for that HTLC (it was failed on their side or they forced close the downstream channel)

In the first case, our peer will force-close before the HTLC times out anyway because they have funds at risk.

But in the second case, our peer won't preemptively force-close (at least eclair won't). So it could be beneficial if we don't force-close either, because we can wait any amount of time before receiving update_fail_htlc. But that opens the door to funds being stuck: if you never force-close, your peer can keep timed out HTLCs forever in the commitment, which locks some of your liquidity. Not force-closing would increase the trust required in your peer's behavior. This shouldn't happen anyway, since splice negotiation should always be quick, so I think we should keep the default behavior of force-closing when HTLCs time out.

[t-bast]

I've spent some time on the quiescence tests, reworked them and made some refactoring in 3ca8b06, could you include this commit?

It made me discover that we aren't correctly handling concurrency between stfu and shutdown. This commit contains fixes for all my comments below.

Can you also rebase to fix the conflict with Peer.kt?

[t-bast]

LGTM! Can you squash that into a single commit? It will make it easier for future rebase while you work on the follow-up PR that handles splicing with pending HTLCs.

[t-bast]

LGTM after rebase, still waiting to integrate along with the splice-htlc follow-up PR.

[t-bast]

ACK 32d4f29

[t-bast]

Included as part of #568