multi: add initial implementation of simple taproot chans spec proposal #6877
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This matches the behavior when we encode TLV records.
This'll let us specify our _own_ nonce during the process. We'll need to do this for channel funding, and also to drive the state machine forward as well.
With taproot channels, both sides will send these nonces along side all the other params in open/accept channel.
In this commit, we add a small wrapper struct that implements the input.Signature interface. This'll let us drop this in anywhere the ECDSA signatures are currently accepted. When we serialize the signatures, as we want to pack it in 64 bytes, we use just the x-coordinate of the R point. Note that this means we aren't able to fully reconstruct the R point from just that value (even vs odd). This value is used as input to the challenge hash for verification, and we can recompute R (the full point), given: the combined nonces, the combined key, and the message.
…e logic In this commit, we add a new sturct: MusigSession that will handle all the new nonce + partial sig interaction for taproot channels. We also add a basic form of initial signing+verification nonce rotation: when we sign we generate a new signing nonce, when we verif we generate a new verification nonce.
In this commit, we build upon the prior commit by adding a new MusigPairSession struct. This holds two sessions: a local one and a remote one. A local session is created with the verification nonce of the local party and the signing nonce of the remote party. A remote session is created with the signing nonce of the local party, and the verification nonce of the remote party.
In this commit, we add another item to the commitment key ring: the CommitmentKeyRing. This'll be used for situations where we want to force a script path only. For example, the to_remote output on the party's commitment transaction. We use the pre-tweaked key here so we can avoid having to deal w/ two levels of tweaks.
This'll allow a new channel state machine to be created in contexts where the set of nonces is already known (funding locked + channel reest).
…hannel creation This'll be useful for when we need to bind the nonces we receive from a remote party to a channel state machine instance.
We implement a simpler version than the existing round based proposal, as with musig2 nonce semantics, it isn't possible to go back and "accept" an older proposal, as that was using an older nonce that has already been effectively revoked.
|
Pushed a bunch of back logged updates! Lots of existing conflicts vs master as this branch hasn't been rebased in months. At this point, things are ~80% working: funding works. co-op close works, and also all the channel state machine and HTLC logic. The only thing missing now is finalizing the on chain handling: force closes, HTLC sweeps, etc, etc. All the scripts and the logic to assemble control blocks are already in place, so the bulk of that should just be updating the various constants we have to properly estimate fees. The commit structure is also far from final (this PR will be split into prob 8 or so other PRs), and there're a few hacks I left in place to demonstrate areas where either we might want to use an entirely new sig type for the second level sigs, and also move over to the 98 byte (sig+nonce) that has been proposed. Some transactions on testnet created with this branch: |
alexbosworth
reviewed
Jan 2, 2023
| @@ -78,6 +78,11 @@ type Request struct { | |||
| // ChangeAddr is a closure that will provide the Assembler with a | |||
| // change address for the funding transaction if needed. | |||
| ChangeAddr func() (btcutil.Address, error) | |||
|
|
|||
| // Musig2 is true, then musig2 will be used to generate teh funding | |||
There was a problem hiding this comment.
Suggested change
| // Musig2 is true, then musig2 will be used to generate teh funding | |
| // Musig2 is true, then musig2 will be used to generate the funding |
alexbosworth
reviewed
Jan 2, 2023
| // While the HTLC verification jobs are proceeding asynchronously, | ||
| // we'll ensure that the newly constructed commitment state has a valid | ||
| // signature. | ||
| verifyKey := lc.channelState.RemoteChanCfg.MultiSigKey.PubKey | ||
| // | ||
| // To do that we'll, construct the sighash of the commitment |
There was a problem hiding this comment.
Suggested change
| // To do that we'll, construct the sighash of the commitment | |
| // To do that we'll construct the sighash of the commitment |
alexbosworth
reviewed
Jan 2, 2023
| return nil, nil, 0, err | ||
| } | ||
| } else { | ||
| // For regular channels we'll, sign the completed cooperative |
There was a problem hiding this comment.
Suggested change
| // For regular channels we'll, sign the completed cooperative | |
| // For regular channels we'll sign the completed cooperative |
alexbosworth
reviewed
Jan 2, 2023
lnwire/commit_sig.go
Outdated
| @@ -36,6 +38,14 @@ type CommitSig struct { | |||
| // transaction should be signed. | |||
| HtlcSigs []Sig | |||
|
|
|||
| // RemoteNnoce is the "remote" nonce of the sending party, which the | |||
There was a problem hiding this comment.
Suggested change
| // RemoteNnoce is the "remote" nonce of the sending party, which the | |
| // RemoteNonce is the "remote" nonce of the sending party, which the |
alexbosworth
reviewed
Jan 2, 2023
| @@ -221,6 +221,14 @@ const ( | |||
| // TODO: Decide on actual feature bit value. | |||
| ScriptEnforcedLeaseOptional FeatureBit = 2023 | |||
|
|
|||
| // SimpleTaprootChannelsRequred is an required bit that indicates the | |||
There was a problem hiding this comment.
Suggested change
| // SimpleTaprootChannelsRequred is an required bit that indicates the | |
| // SimpleTaprootChannelsRequired is a required bit that indicates the |
alexbosworth
reviewed
Jan 2, 2023
| // For schnorr signatures, we can use the same internal 64 bytes. | ||
| case sigTypeSchnorr: | ||
| // We'll make a copy of the signature so we don't return a | ||
| // refrence into the raw slice. |
There was a problem hiding this comment.
Suggested change
| // refrence into the raw slice. | |
| // reference into the raw slice. |
This allows us to not have to store any persistent nonce state to disk. When we go to broadcast, we'll re-generate our nonce based on the current shachain height, then use that to generate the combined nonce and sign the next state.
|
Latest commit is now caught up with: Roasbeef/lightning-rfc#5 I've also switched to using a counter-based (shachain derived) scheme for our local nonces. This lets us not have to store any secret nonce state to disk. Instead when we go to broadcast, we can just re-derive the nonce, then sign as normal. |
Force closing works, but the resolvers stop short as the contract court hasn't been updated yet for any of the new flows.
This was referenced Jan 17, 2023
|
we can close this now right? |
|
Yep! We merged the changes in a series of smaller PRs. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this (draft) PR, we add initial support for the new musig2 based taproot channels. The PR is still incomplete (commits are messy, many TODOs all over the place), but I wanted to get it up so I can start to update the spec PR in lock step with this implementation. I've found a few things worthy of revising along the way as I progressed with this implementation. A few of them are lingering in TODOs in the PR, while the others have already made it to the spec PR in form of revisions.
What Works
lnwiredefinitions and parsing for the new nonces we added to certain channel operation messagesmusig2session state w/ proper nonce rotationlnwalletlevel funding+reservation logic for the new channelsTestLightningWallet/btcwallet/btcd:single_funding_workflow_musig2exercising the e2e flow of the new signing protocol.What Almost Works
What's Missing
chanvalidatelogic for musig2 chan outputSigPoollogic to handle the P2TR script path signing pathsR = R1*b + R2)Fixes #6691