bolt 2: coop-closing clarification

[Crypt-iQ]

I am confused with the sending node requirements here at the bullet point "if there are updates pending on the receiving node's commitment transaction". The general overview under number 1 and diagram lead me to believe that sending shutdown with committed HTLC's is fine. So I think the referenced bullet point above is referring to uncommitted updates instead. If so, does this count HTLC's where we owe signatures to the remote party?

A                B
   <--add--
   <--sig---
   ---rev-->
   ---shutdown-->
   // allowed even though the add may be considered a "pending" update depending on your terminology?

My second point of confusion involves both the sending node and the receiving node requirements. The sending node "SHOULD fail to route any HTLC added after it has sent shutdown". Here I am assuming that this is when the sending node is receiving HTLC's from the counter-party as the sender routing through the channel they just sent a shutdown on would be a spec-violation. The receiving node "once there are no outstanding updates on the peer, UNLESS it has already sent a shutdown... MUST reply to a shutdown message with a shutdown". These two requirements seem to be at odds with one another, let's assume A & B start on a clean commitment state:

A                        B
   --shutdown-->
   <-----add----

Let's say that B received the shutdown message and then sent the add. While it is a spec violation (as B should have sent shutdown), A is unable to do anything here. It could be the case that B sent the add before receiving the shutdown message, and A has already sent the shutdown message. My question boils down to this: when does it become appropriate for A to enforce that B sends a shutdown if there is a clean channel state, rather than sending more HTLC's? If the answer is never, then the "MUST reply to a shutdown message with a shutdown" could use wording instead of "MUST".

[t-bast]

I can detail how eclair behaves in those cases, and how I interpret the spec (there may be mistakes, which would be my own).
Our behavior is to not send our own shutdown while we have added htlcs or fee updates that we haven't signed yet (the "pending updates" we consider here are actually only unsigned outgoing update_add_htlc and update_fee).
We expect our peer to do the same, otherwise we force-close.

So this would be valid:

    A                B
      -----add----->
      -----sig----->
      ---shutdown-->

But this would not:

    A                B
      -----add----->
      ---shutdown-->
      -----sig----->

Regarding your specific examples, they are both valid from my point of view.
Valid next steps for your last examples could for example be:

    A                B
      ---shutdown-->
      <----add------
      <----add------
      <----sig------
      <--shutdown---

Shutdown is a signal that we won't send any new update_add_htlc or update_fee, and will now only sign/resolve the existing ones. It doesn't force your side to do the same, until you also send shutdown.

[Crypt-iQ]

the "pending updates" we consider here are actually only unsigned outgoing update_add_htlc and update_fee

I agree that this makes sense, but it's not clarified in the spec. When I read the sending node requirements, I immediately think of all update_* messages.

Shutdown is a signal that we won't send any new update_add_htlc or update_fee, and will now only sign/resolve the existing ones. It doesn't force your side to do the same, until you also send shutdown.

This also makes sense to me, but the receiving node "once there are no outstanding updates on the peer ... MUST send a shutdown". If we can't enforce (by force closing) that the recipient of our shutdown do this, then the MUST isn't really a MUST. If that is the case, then maybe the spec could suggest a timeout after which a force close occurs. Does eclair do something like this? I am also curious to know how the other implementations handle this.

[t-bast]

once there are no outstanding updates on the peer ... MUST send a shutdown

It can probably be clarified, but what that means (at least to me) is that once you don't have any outstanding, unsigned update_add_htlc or update_fee that you want to send to your peer, then you must send your shutdown message. That allows you to "sneak in" your backlog of outgoing update_add_htlc and update_fee, but once you're done, you really must let the shutdown process continue.

I think you're misinterpreting "no outstanding updates on the peer" as "once the remote side has no outstanding updates to send us". We don't care about what the remote peer does (since we can't know what updates they're preparing but haven't sent yet), we only looks at what updates we want to send them.

It's true though that the remote peer may choose to never send their shutdown and keep adding updates. However after a while, since new htlcs will flow only in one direction, the channel will be depleted and they won't be able to send more updates. You could use a timeout and force-close after a while, but I'm not sure it's necessary.

[Crypt-iQ]

What does c-lightning / LDK do here? @rustyrussell @TheBlueMatt

[Roasbeef]

We need to confirm on the lnd side (if we count update_fee), but it seems the middle ground here spec wise is to only send the shutdown message once there are no uncommitted changes (including update_fee messages, so every update has been included in a commit_sig message). If you receive one early, then you should just wait until the coast is clear to enter the second stage of co-op close negotiation.

[TheBlueMatt]

SGTM, I believe LDK currently only considers update_add as the "pending updates" criteria here, but it seems like the correct way forward is to not verify that on receiving shutdown, but to include update_add/update_remove/update_fee all as things that block sending shutdown.

[niftynei]

clightning only sends shutdown after a commit has been sent + on reconnect, so there's never any pending updates.

[Crypt-iQ]

not verify that on receiving shutdown

I'm confused - what does this mean?

Also, I don't think the bolt specifies what should be done if a shutdown is received and there are pending updates?

[TheBlueMatt]

Also, I don't think the bolt specifies what should be done if a shutdown is received and there are pending updates?

Yes, my point is the way forward for all of us is probably to not verify anything about "pending updates" when receiving shutdown, but be conservative and only send shutdown if nothing is pending.

[Crypt-iQ]

Yes, my point is the way forward for all of us is probably to not verify anything about "pending updates" when receiving shutdown, but be conservative and only send shutdown if nothing is pending.

Ok that sounds fine to me.

It's not spelled out currently in the spec for shutdown (for closing_signed it is), but if shutdown has been exchanged and the connection goes down before reaching the closing_signed stage, should startup erase that shutdown "state", making the channel fully operational again? It would be easier on lnd's side to avoid any persistence there

[Crypt-iQ]

Should the spec only allow closing_signed if any update_remove/update_fee is locked-in on both commitments & there's no pending commitment? It could be the case that the non-pending remote commitment has an htlc and neither the local commitment or the remote pending does. It could also be the case that the remote commitment (pending or non-pending) is at a different feerate than the local commitment

[Roasbeef]

It's not spelled out currently in the spec for shutdown (for closing_signed it is), but if shutdown has been exchanged and the connection goes down before reaching the closing_signed stage, should startup erase that shutdown "state", making the channel fully operational again? It would be easier on lnd's side to avoid any persistence there

Turns out the spec has a section on this, brought up by bluematt:

• upon reconnection:
  • if it has sent a previous shutdown:
  • MUST retransmit shutdown.