Explicit commit_sig retransmission for interactive-tx

[t-bast]

When disconnecting in the middle of the signing steps of an interactive-tx transaction, we must retransmit signatures on reconnection to complete the interactive-tx protocol.

Nodes first exchange commitment_signed, followed by tx_signatures once they have both sent and received commitment_signed.

We previously always retransmitted commitment_signed, even when our peer had already received it. We now include an explicit bitfield that lets nodes request commitment_signed if they haven't received it.

Note that this is a breaking change, and we are thus changing the TLV type to make it easier to detect. In practice it should be fine, since only eclair and cln have shipped support for dual funding, and those two implementations are already incompatible on reconnection because eclair implements #1214 but cln doesn't. This edge case only creates an issue when nodes disconnect after exchanging tx_complete but before receiving signatures, which should happen very infrequently.

Replaces #1214.

[niftynei]

We previously always retransmitted commitment_signed, even when our peer had already received it. We now include an explicit bitfield that lets nodes request commitment_signed if they haven't received it.

Can you remind me again why we can't just retransmit the commitment_signed message? It seems much simpler to implement and requires less logic in general, but maybe I'm missing an edge case here where having a duplicate message is problematic.

[t-bast]

Can you remind me again why we can't just retransmit the commitment_signed message? It seems much simpler to implement and requires less logic in general, but maybe I'm missing an edge case here where having a duplicate message is problematic.

Because it's hacky, why retransmit a message that doesn't need retransmission? Also, it's trivial without taproot, because the sender could simply store their commit_sig and re-send it on reconnection, but with taproot it's much more annoying:

• nonces need to be shared before-hand (your peer must send you nonces for this specific commitment)
• you cannot simply retransmit, you have to re-sign because nonces have changed

If we can avoid an unnecessary musig2 round, I think it's worth it, especially since it makes the protocol conceptually cleaner.

[niftynei]

why retransmit a message that doesn't need retransmission?

Well, without a signal you don't know if it doesn't need retransmission. You can leave the signal out and retransmit the message and the protocol will work. It's simpler and requires less if statements/state checks to take the same action on every reconnection.

avoid an unnecessary musig2 round

It's only "unnecessary" in some fraction of cases; in others it will be necessary. You can easily remove an if switch by taking the same action on every reconnection, which makes the protocol simpler to write and verify.

[jkczyz]

ACK 1d25dd1 modulo a minor wording issue.

[t-bast]

@niftynei @ddustin can you please take a look and ACK this PR? We'd really like to move forward and get it merged since we have cross-compat with LDK and it works with cln for splicing (but it doesn't work for dual-funding yet).

This PR is a pre-requisite for the splice PR and is blocking its progress.

[jkczyz]

ACK 7646fc2