Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simple taproot channels v2 #3005

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from
Draft

Simple taproot channels v2 #3005

wants to merge 4 commits into from

Conversation

sstone
Copy link
Member

@sstone sstone commented Feb 10, 2025

This is a simpler alternative to #2868: musig2 nonce exchange has been moved into the interactive tx session, and become much simpler as there open_v2/accept_v2, splice_ or rbfmessages remain unchanged. Channel re-establishment logic becomes a bit more complex, which is mitigated by storing and re-sending the lastcommit_sig` message if needed.

This commit implements:
  - feature bits for simple taproot channels
  - TLV extensions for funding/closing wire messages
  - modifications to how we handle channel funding, splicing and mutual closing
  - changes to the commitment structures

Since the current "simple taproot channels" proposal is not compatible with splices, we extend it to include a list of musig2 nonces (one for each active commitment transaction).
Similar to how commitment points are handled, `firstRemoteNonce` and `secondRemoteNonce` fields have been added to `SpliceInit` and `SpliceAck`, encoded as a list of nonces (instead of 2 expicit nonces)
We also need a nonce for the new commit tx that is being built, here it has been added to `SpliceInit` and `SpliceAck`.

The closing workflow is similar to the standard "simple close" workflow:
- Alice and Bob exchange `shutdown`, which includes a "closing nonce" (no changes here compared to the "simple taproot channels" spec).
- Alice selects possible closing transaction (closer_output_only, closee_output_only, closer_and_closee_output) and for each of them creates
a partial_signature_with_nonce using a new random local nonce and Bob's closing nonce (which she received in Bob's `shutdown` message).
- Alice send a `closing_complete` message to Bob that include these partial_signature_with_nonce.
- Bob receive Alice's `closing_complete` message, selects one of Alice's partial_signature_with_nonce, creates partial_signature_with_nonce using.
his closing nonce and the nonce attached to the partial_signature_with_nonce and sends it to Alice in a `closing_sig` message.
- Alice receives Bob's `closing_sig` and creates a partial signature for her closing tx using her closing nonce and the nonce attached Bob's partial_signature_with_nonce.
- Alice combines this signature with Bob's and can broadcat her closing tx.
Upon re-connection, when a splice has not been fully completed, nodes will re-send signatures for the previous remote commit tx. This signature will
be ignored by the receiving nodes if it has already received it before it was disconnected, simply by comparing them (signatures are deterministic).

With taproot channels, we also need to attach musig2 nonces for splices in progress to channel_reestablish, which are needed to re-generate the signature
for the old commit tx.
The exchange of Musig2 nonces is done in the interactive tx session, and are attached to the `tx_complete` message.
There are 2 types of nonces:
- "funding nonces", which are used to sign a new funding tx that spends the current funding tx (splice, rbf).
- "commit nonces", which are used to sign the commit tx that is one of the outputs of the interactive session.

"funding nonces" can be randomly generated on-the-fly: either the interactive session will fail, and they can be forgotten, or it will succeed
and we'll get a new, fully signed funding tx.
"commit nonces" can be deterministically generated.

This make nonce exchange simpler to reason about:
- when we send `tx_complete`, we know exactly what the funding tx and commit tx will be (so the funding tx id can be mixed in the nonce generation process).
- dual funding, splice and rbf message do not need to be modified

Channel re-establishment becomes a bit more complex, as one node could still be waiting for signatures while the other has completed the splice workflow, but it
can be mitigated by storing the last sent commit_sig and re-sending it again if needed.
@sstone sstone requested a review from t-bast February 10, 2025 16:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant