bolt02 requirements for closing_signed with musig2-taproot

[Crypt-iQ]

This makes simple musig2-taproot channels use fee_range by making it fully turn-based with a new message closing_rejected.

[Roasbeef]

Great observation re needing to move towards a turn-based protocol. While we're at it...I wonder if we should just move all the negotiation upfront, and then have a single accept message that contains the final valid signature?

We can likely defer that though, as this may be aa change we want to make fore all channel types.

Main comment here is re the two nonces still, and also moving this to the extension doc.

[Roasbeef]

In the "extension" style, I think we want to instead add these new TLV fields and requirements to the new document.

[Crypt-iQ]

I am of two minds here. On one hand it's nice to have things in a new document, but I also think it would be confusing to split up closing_signed requirements between multiple files without any sort of reference (hyperlink?) from one file to the other

[Roasbeef]

Interesting addition, same comment re moving to the extension doc.

[Roasbeef]

Why are two sets of nonces needed here? I was under the impression that in the co-op close case, there's actually just one message being signed, so we can get away with a single nonce?

[Crypt-iQ]

For dust limit, unless there's a way to agree on a single tx

[Crypt-iQ]

I wonder if we should just move all the negotiation upfront, and then have a single accept message that contains the final valid signature?

That's possible. With fee_range in the current spec (which is mostly the same to this proposal), there are a couple scenarios:

• Done in two messages

---fee_range(100, 200), fee_sats(150)---->
<--fee_range(120, 180), fee_sats(150)-----

• Done in three messages

---fee_range(100, 200), fee_sats(150)---->
<--fee_range(120, 180), fee_sats(170)-----
---fee_range(100, 200) fee_sats(170)----->

• Done in N messages

---fee_range(100, 200), fee_sats(150)----> (recipient doesn't like fee_range)
---fee_range(150, 250), fee_sats(200)---->
...
---fee_range(500, 600), fee_sats(550)----> (...)
<--fee_range(500, 700), fee_sats(550)----- (recipient immediately agrees)

• Done in N messages part 2

---fee_range(100, 200), fee_sats(150)----> (recipient doesn't like fee_range)
---fee_range(150, 250), fee_sats(200)---->
...
---fee_range(500, 600), fee_sats(550)----> (...)
<--fee_range(500, 700), fee_sats(650)----- (recipient doesn't agree)
---fee_range(500, 600), fee_sats(650)---->

You could change it so that the initiator doesn't send a signature until the recipient does. That lengthens the round-trip time in the cases where the recipient immediately agrees, but it doesn't seem to be a big deal. It does let you get rid of nonce exchanging in closing_rejected, but the message should stay to signal that the recipient doesn't agree with the range. I was mostly going for keeping the fee_range stuff as similar as possible to what's existing