option_simple_close (features 60/61)

[t-bast]

This PR is a continuation of #1096, that @rustyrussell asked me to take over. The original description was:

This is a "can't fail!" close protocol, as discussed at the NY Summit, and on @Roasbeef's wishlist.  It's about as simple as I could make it: the only complexity comes from allowing each side to indicate whether they want to omit their own output.

It's "taproot ready"(TM) in the sense that `shutdown` is always sent to trigger it, so that can contain the nonces without any persistence requirement.

I split it into three commits for cleanliness:

1. Introduce the new protocol
2. Remove the requirement that shutdown not be sent multiple times (which was already nonsensical)
3. Remove the older protocols

I recommend reviewing it as separate commits, it'll make more sense!

I believe it is still useful to review as separate commits: however, we initially allowed setting nSequence, which we removed in favor of setting nLockTime. That part can probably be skipped. I squashed the fixup commits from the previous PR, but kept the rest.

[t-bast]

As described in #1096 (comment), the main question is whether we want to have stricter requirements on exchanging shutdown whenever one side sends a new one. This is probably required to ensure that we can correctly exchange nonces to produce partial signatures for taproot channels: we want to make sure we get this right, as the goal of this protocol is to be compatible with taproot channels!

@Roasbeef let me know what you think: I'm currently leaning towards your initial implementation where you must receive shutdown after sending one. If we decide on that, I'll clarify the spec!

[t-bast]

I added the requirement to strictly exchange shutdown before sending closing_complete again in a8fd1ab

This is implemented in ACINQ/eclair#2747, waiting for lnd for cross-compatibility tests (may need to update the feature bit either on the lnd side to use 60 or on the eclair side to use 160)!

[tnull]

I'm starting to look into implementing option_simple_close for LDK. For now I just have one question and a few nits after an initial round of review.

[Roasbeef]

Why won't Alice just proceed with scriptA2? It's what she sent in order to respond to Bob's shutdown initiation above.

If if Alice just ignores the closing_complete, then Bob has no way of knowing why she ignored it. Alice sent scriptA2 as part of this new RBF session, so should stick with it until the sigs are changed, then afterwards she can send her new script. This simplifies the state machine IMO. Otherwise you need to handle extra transitions each time the other party sends a new shutdown while you're already prepping to sign a new coop close txn.

[t-bast]

Why won't Alice just proceed with scriptA2? It's what she sent in order to respond to Bob's shutdown initiation above.

She could, but it's more complex because that means Alice must remember the state she had when she sent shutdown(scriptA2), whereas it's simpler to drop the old state as soon as you send shutdown. Note that the spec currently doesn't forbid Alice from doing so, but she isn't forced to do it if she doesn't want to store the state from shutdown(scriptA2) after sending her shutdown(scriptA3).

If if Alice just ignores the closing_complete, then Bob has no way of knowing why she ignored it.

Yes he does: he sees that he receives shutdown after sending closing_complete (while he's waiting for closing_sig), which means Alice is starting a new signing round and may not answer to his closing_complete. It doesn't matter, because Bob will answer with shutdown and will then re-send closing_complete with the new parameters.

Alice sent scriptA2 as part of this new RBF session, so should stick with it until the sigs are changed, then afterwards she can send her new script.

That seems dangerous, because it introduces a risk of deadlock: if Bob never sends closing_complete, Alice would never be allowed to send a new shutdown?

Otherwise you need to handle extra transitions each time the other party sends a new shutdown while you're already prepping to sign a new coop close txn.

You have to implement those state transitions anyway, because there is no requirement for both nodes to re-sign with the new parameters, so at least one of the two nodes cannot know in advance if the other node will send closing_complete or not.

---

Overall I think that what you're suggesting is that you'd like to change the protocol to be more strict and require both nodes to re-sign their mutual close tx every time shutdown is exchanged, is that correct? That would indeed be a simpler state machine, but if any side doesn't send one of the expected messages, we're stuck and cannot send shutdown again to restart the signing session, so it feels less robust than the currently proposed protocol, where we can always restart by sending shutdown. Otherwise the only option is to disconnect, which negatively impacts the other channels you may have with that peer.

I don't know if I'm being too careful about avoiding deadlocks here, but I like having the property that we can restart the state machine without disconnecting...

[yyforyongyu]

but it's more complex because that means Alice must remember the state she had when she sent shutdown(scriptA2), whereas it's simpler to drop the old state as soon as you send shutdown.

Yeah this does look cleaner.

That seems dangerous, because it introduces a risk of deadlock: if Bob never sends closing_complete, Alice would never be allowed to send a new shutdown?

Could you clarity a bit? What prevents Alice from sending a new shutdown given that node can now send multiple shutdown msgs?

[yyforyongyu]

The sender of closing_sig needs to make sure the received closing_complete.locktime is equal to the closing_complete.locktime sent.

[t-bast]

I think you may be misunderstanding something about the proposal here: both nodes send closing_complete independently, with whatever value they choose for locktime, which don't have to match. The only thing that needs to be done is that when receiving closing_complete, a node must use the received locktime and fee_satoshis to create the closing transaction that they sign, for which they send closing_sig.

[yyforyongyu]

Given the sender MUST set closee_output_only if the local output amount is dust when the local outstanding balance is less than the remote outstanding balance, I interpret it as,

• the local node is the closer and,
• we allow the local balance to be dust or zero

Then this would make the fee_satoshis here either dust or zero because we require it to be <= local balance?

[t-bast]

I don't understand what the issue is here. You can never set fee_satoshis to something greater than your balance (because otherwise you simply cannot pay those fees). That's the only thing that this requirement says.

If, after deducing the fee_satoshis, the remaining value of your output is too small, then you're allowed to omit this output, which means the closing transaction will only have an output for the closee (closee_output_only).

[yyforyongyu]

I guess it's easier to look at this question - if I don't have local balance, am I allowed to start a shutdown session to kick off the coop close flow?

Based on this requirement here, since I am required to set the fee_satoshi to be no greater than my local balance in my closing_complete, it means the value I choose here is 0 and set the closee_output_only?

[t-bast]

I guess it's easier to look at this question - if I don't have local balance, am I allowed to start a shutdown session to kick off the coop close flow?

I guess that what you mean by not having a local balance is having a channel balance of 0 sat, correct? Which by the way can only happen on a new channel opened to you or when using 0-reserve.

If that's the case then no, you don't have any funds in that channel, so it doesn't make any sense for you to create a closing transaction, you have nothing at stake that you'd like to get back. So you will not send closing_complete. Your peer will send closing_complete though because they have funds in the channel. When they do, you will respond with closing_sig to let them get their funds back.

If by "I don't have a local balance" you mean that you have some funds in the channel, but they are trimmed (e.g. 200 sats), then you're allowed to create a closing transaction where you put all of your funds to mining fees, and in that case you are only allowed to include your peer's output, hence the use of closee_output_only.

[yyforyongyu]

As a receiver of fee_satoshi I'll send an error or warning if the specified value is below the min relay fee.

[t-bast]

No, you don't validate what your peer chooses for their closing transaction. It's their choice, they're paying the fees, they can do whatever they want even if it doesn't seem sane to you. You will use what you consider sane values in your closing transaction, when you send closing_complete.

[yyforyongyu]

There's no need for Bob to send the closing_sig since he just takes over?

[t-bast]

I think you're misunderstanding how this works, I believe you think that a single closing transaction is created (like the previous mutual close protocol). In this protocol, two independent closing transaction are created: one for each node. Each node independently sends closing_complete with the parameters they want for their closing transaction, and the receiver just signs it.

[yyforyongyu]

Nice diagram! And I think it may be more helpful if we could break it down case by case, also addresses the comment here, to make it clear that,

1. a pair of closing_complete and closing_sig completes the flow, and,
2. whoever sends the closing_complete pays the fees.

In a hindsight it probably makes more sense to name closing_complete closing_params and closing_sig closing_complete, well, but the code is written so nvm.

[yyforyongyu]

During normal flow, once the shutdown scripts are exchanged via shutdown messages, Alice sends a closing_complete to specify the fees she is willing to pay, and Bob replies with a closing_sig to complete Alice's closing transaction. Bob also sends a closing_complete to express his fee preference, and Alice replies with a closing_sig to provide signature for Bob's closing transaction.

 +-------+                              +-------+
 |       | shutdown(scriptA1)           |       |
 |       |----------------------------->|       |
 |       |           shutdown(scriptB1) |       |
 |       |<-----------------------------|       |
 |       |                              |       |
 |       | <complete all pending HTLCs> |       |
 |   A   |             ....             |   B   |
 |       |                              |       |
 |       | closing_complete             |       |
 |       |----------------------------->|       |
 |       |             closing_complete |       |
 |       |<-----------------------------|       |
 |       |                  closing_sig |       |
 |       |<-----------------------------|       |
 |       | closing_sig                  |       |
 |       |----------------------------->|       |
 +-------+                              +-------+

It's allowed to specify shutdown scripts multiple times.

+-------+                              +-------+
|       | shutdown(scriptA1)           |       |
|       |----------------------------->|       |
|       |           shutdown(scriptB1) |       |
|       |<-----------------------------|       |
|       |                              |       |
|       | <complete all pending HTLCs> |       |
|   A   |             ....             |   B   |
|       |                              |       |
|       |   <A updates their script>   |       |
|       |                              |       |
|       | shutdown(scriptA2)           |       |
|       |----------------------------->|       |
|       |           shutdown(scriptB1) |       | (*) Bob doesn't update his script
|       |<-----------------------------|       |
|       | closing_complete             |       |
|       |----------------------------->|       |
|       |             closing_complete |       |
|       |<-----------------------------|       |
|       |                  closing_sig |       |
|       |<-----------------------------|       |
|       | closing_sig                  |       |
|       |----------------------------->|       |
+-------+                              +-------+

It's possible to encounter a race condition when updating the shutdown script. This is handled by always sending an updated closing_complete with the latest shutdown script used.

+-------+                              +-------+
|       | shutdown(scriptA1)           |       |
|       |----------------------------->|       |
|       |           shutdown(scriptB1) |       |
|       |<-----------------------------|       |
|       |                              |       |
|       | <complete all pending HTLCs> |       |
|   A   |             ....             |   B   |
|       |                              |       |
|       |   <Bob updates his script>   |       |
|       |                              |       |
|       |           shutdown(scriptB2) |       |
|       |<-----------------------------|       |
|       | shutdown(scriptA2)           |       |
|       |----------------------------->|       |
|       |             closing_complete |       |
|       |          <-------------------|       |
|       |                              |       |
|       |  <Alice updates her script>  |       | (*) This is a concurrent update while Bob is sending closing_complete
|       |                              |       |
|       | shutdown(scriptA3)           |       |
|       |------------------->          |       |
|       |   closing_complete           |       |
|       |<-------------------          |       | (*) A doesn't answer with closing_sig because B's sig doesn't use scriptA3
|       |           shutdown(scriptA3) |       |
|       |          ------------------->|       |
|       |           shutdown(scriptB2) |       |
|       |<-----------------------------|       |
|       | closing_complete             |       |
|       |----------------------------->|       | (*) A now uses scriptB2 and scriptA3 for closing_complete 
|       |             closing_complete |       |
|       |<-----------------------------|       | (*) B now uses scriptB2 and scriptA3 for closing_complete 
|       | closing_sig                  |       |
|       |----------------------------->|       |
|       |                  closing_sig |       |
|       |<-----------------------------|       |
+-------+                              +-------+

[t-bast]

See my answers to your other comments to clarify some misunderstandings. There is one open comment that we will discuss during today's spec meeting that may affect the whole flow: #1205 (comment)

Let's see after this discussion is resolved if you still have open issues with the resulting protocol.

[yyforyongyu]

Yeah I did realize it's a dual flow - updated the diagram and description, could you verify if it's correct?