Should nodes store signatures sent during interactive transaction sessions ?

[sstone]

Should we require nodes to temporarily store signatures that they send during an interactive transaction construction session so they can be re-sent if nodes are disconnected before the session has completed ?

Context

Alice and Bob start an interactive transaction construction session.
Alice gets disconnected after she's sent commitment_signed but before she's received Bob's tx_signatures.

Alice                         Bob
 |                              |
 |       <interactive-tx>       |
 |                              |
 |         tx_complete          |
 |----------------------------->|
 |         tx_complete          |
 |<-----------------------------|
 |         commit_sig           |
 |----------------------------->|
 |         commit_sig           |
 |              XXXXX  ---------|

Upon reconnection, Alice will ask Bob to retransmit his commit_sig and tx_signatures. Similarly, Bob will ask Alice to retransmit her tx_signatures (he has already received her commit_sig).

In order to retransmit commit_sig and/or tx_signatures, there are two possible strategies:

• store them along with interactive session data, re-send it if necessary and discard when the session completes
• re-compute them

Re-computing signatures is easy for the current commitment formats, but becomes more difficult with taproot channels which use musig2 signatures that require peer to first exchange nonces that match the commitment or funding transaction being signed.

With splicing, there can be multiple commitments that are valid at the same time (all with different funding transactions but with the same commitment number), which all need to be signed and revoked using different nonces (they cannot be reused accross splice commitment transactions, unlike commitment points for example). To easily identify which nonces should be used for a given commitment transaction, we propose to attach list of (funding tx id, verification nonce) tuples to revoke_and_ack and channel_reestablish(this is not part of the simple taproot channel BOLT proposal yet), each of these nonces being used to sign and verify the "next" remote commitment transaction.

So we have 2 options:

1. If we require that implementations do indeed store the commitment signature that they've sent during the interactive session until it has been completed, then handling re-reconnection when a splice is in progress is the same for taproot and non-taproot channels: just re-send the stored signature.

2. If we don't, the above scheme is not enough: nodes will need to re-compute a signature for the current interactive session commitment transaction, but will have received a nonce for the next commitment transaction: we'll need to attach an optional current remote nonce TLV to channel_reestablish that matches the interrupted interactive session's funding tx id and current commitment number.

We have the exact same issue with tx_signatures, which for taproot channel splices will include a partial signature for for the new funding transaction. tx_signatures could either be stored or re-computed but in that case, nodes will also need to attach a funding_nonce to channel_reestablish.

Which one do you think is acceptable ?

[t-bast]

@ddustin @rustyrussell @jkczyz @TheBlueMatt we'd like your feedback on this!

You have only implemented the interactive-tx part, not the taproot part yet, but knowing whether your implementation currently stores its previous commit_sig / tx_signatures or if it recomputes it on reconnection would really help inform our design decision here!

[ddustin]

We currently store the tx_signature signatures. We have to because the user may provide some signatures through the RPC and we can't prompt them during reestablish if we need to resend them.

Additionally storing the single splice candidate commit sigs shouldn't be too difficult and if it avoids complex rounds for taproot that seems worthwhile to me 👍.

[t-bast]

We currently store the tx_signature signatures. We have to because the user may provide some signatures through the RPC and we can't prompt them during reestablish if we need to resend them.

Agreed, that's the main reason why we also currently store them. Even though in theory, you could store the signatures for all wallet inputs, and only recompute the signature for the previous funding output on reconnection, so it's still possible to re-sign the musig2 inputs on reconnection without adding too much complexity.

Let's see what the LDK folks think about these options!

[jkczyz]

@wpaulino or @TheBlueMatt can correct my understand, but AFAICT we store tx_signatures but recompute commitment_signed.

• https://github.com/lightningdevkit/rust-lightning/blob/ed16b5f90fef01cc1f7c0175966c52e855f074d3/lightning/src/ln/interactivetxs.rs#L327
• https://github.com/lightningdevkit/rust-lightning/blob/ed16b5f90fef01cc1f7c0175966c52e855f074d3/lightning/src/ln/channel.rs#L7854

[t-bast]

AFAICT we store tx_signatures but recompute commitment_signed.

This is what we currently do as well, but it's not very consistent. I think it would make more sense to be consistent and either store both messages or re-sign both on reconnection. If we decide to be consistent, which one would you rather do? Or do we really care about being consistent here or is it fine to re-sign commit_sig but not tx_signatures?

[t-bast]

After discussing it again in yesterday's spec meeting, the consensus is to:

• re-sign commitment_signed on reconnection (which needs fresh nonces in the taproot case)
• re-transmit tx_signatures without re-signing it (no need for fresh nonces)

This aligns well with the requirements for the corresponding keys:

• keys used for commitment_signed are "hot" and always available since they are used whenever payments are added / settled
• keys used for tx_signatures are "colder" since they may involve wallet inputs