bolt02 requirements for closing_signed with musig2-taproot#2
bolt02 requirements for closing_signed with musig2-taproot#2Crypt-iQ wants to merge 2 commits intoRoasbeef:simple-taproot-chansfrom
Conversation
Roasbeef
left a comment
There was a problem hiding this comment.
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.
| 2. data: | ||
| * [`u64`:`min_fee_satoshis`] | ||
| * [`u64`:`max_fee_satoshis`] | ||
| 1. type: 2 (`local_musig2_pubnonce`) |
There was a problem hiding this comment.
In the "extension" style, I think we want to instead add these new TLV fields and requirements to the new document.
There was a problem hiding this comment.
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
| No funds are at risk when that happens, but the channel must be force-closed as | ||
| the closing transaction will likely never reach miners. | ||
|
|
||
| ### Closing Rejected: `closing_rejected` |
There was a problem hiding this comment.
Interesting addition, same comment re moving to the extension doc.
| 1. type: 2 (`local_musig2_pubnonce`) | ||
| 2. data: | ||
| * [`66*byte`:`nonces`] | ||
| 1. type: 4 (`remote_musig2_pubnonce`) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
For dust limit, unless there's a way to agree on a single tx
That's possible. With
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 |
e95e7ac to
e25132d
Compare
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Header from folded patch 'bolt_2__set_an_initiator_in_quiescence.patch': BOLT #2: Set an initiator in quiescence. This is especially useful for protocols such as splicing; for simplified commitment transactions, there is already an implied initiator at each point, so having the negotiation at splicing time would be redundant. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Header from folded patch 'option_quiesce__feature_to_support_stfu_method.patch': option_quiesce: feature to support stfu method. In practice, sftu is useless unless you have something (e.g. channel_upgrade) which uses it, but adding a feature is best practice IMHO. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1ad02ee to
4c1314a
Compare
Remove the redundant nSequence paragraph from the cooperative close section. The `option_simple_close` spec in BOLT #2 already specifies that `nSequence` MUST be exactly `0xFFFFFFFD`, so restating it here with the weaker "less-than-or-equal" phrasing was both redundant and inconsistent. Also fix "next closee nonce" to "closer nonce" in the JIT nonce description for `closing_complete`, matching the terminology used throughout the rest of the spec.
This makes simple musig2-taproot channels use fee_range by making it fully turn-based with a new message
closing_rejected.