option_closing_rejected: turn-based fee_range coop close (feature 60/61)

[Crypt-iQ]

Adds a feature bit. It's optional, but does simplify some of the spec logic and I think it's nice to have. The naming can change. It works with simple-taproot-channels to allow sending musig2 nonces in a turn-based way.

Fixes #1013

[Roasbeef]

Commentary from the latest spec meeting:

• This splits off a bit into paths of adding more information to the warning message (error code, context information, etc), and also a possible greater re-org for co-op close in general.
• Instead of the new message, we can add more info to warnings, then also add a new bit to help ppl recognize/enforce that
  • In addition to an error code, we might also want to add: suggested value, the field itself, maybe the first 16 bytes of message (or hash or something like that).
• Also a chance to make the "negotiation" part of co-op closing more explicit

[t-bast]

Concept ACK. I would add a feerate_range tlv in the closing_rejected message, it provides more information to the initiator even though it may be obsolete by the time the initiator acts on it (and of course, this will also later contain a tlv with musig2 nonces).

I think it would be confusing to use a warning or an error here. This is an explicit step of the protocol that will require protocol-related handling (e.g. extract musig2 nonces / analyze responder's proposed feerates), so it should use a message tailored for that protocol. It's easy to understand/debug a state machine by only looking at what messages are exchanged, and using a warning for this would force introspection of the message (adds one layer). For example we could have very confusing message flows such as:

• A sends closing_signed to B
• B sends warnings to A for a completely unrelated issues
• B send closing_signed to accept A's closing_signed

If we had a shortage of available message types I would understand the need to create that additional layer of indirection, but since we don't have such a shortage adding such indirection is creating unnecessary complexity?

[Crypt-iQ]

@t-bast

if there is no overlap between that and its own fee_range:
- SHOULD send a warning

Should the above be changed so that if you are sending closing_rejected, you don't send a warning?

[t-bast]

Should the above be changed so that if you are sending closing_rejected, you don't send a warning?

Yes, I believe we should replace the use of warning with this new closing_rejected message now that we have it (it lets us provide more structured data to the sender).

Of course, if others disagree with my previous comment and think we should extend warning/error instead of introducing a new message, this point would be moot.

[Roasbeef]

Comment from spec meeting: should this also include a fee range in this message?

[Crypt-iQ]

I thought we were going with the whole warnings approach for telling what parameters you didn't like about any message?