In this commit, we update all the taproot scripts spends to optionally
make the control block. This is useful in cases where we've already
created the control block, or may not have the items needed to construct
it in the first place.
We also add the control block to the sign descriptor itself.
This ensures that when loading the channel again after a normal chan
reest, we generate the local nonces, which ensures we can then process
nonces the remote party sends us in their chan reest message.
In this commit, we update the chain watcher to be able to generate the
correct pkScript so it can register for confirmation and spend
notifications for taproot channels.
In this commit, we start to set _internally_ a new feature bit in the
channel announcements we generate. As these taproot channels can only be
unadvertised, this will never actually leak to the public network. The
funding manager will then set this field to allow the router to properly
validate these channels.
In this commit, we add support for the new musig2 channel funding flow.
This flow is identical to the existing flow, but not both sides need to
exchange local nonces up front, and then signatures sent are now partial
signatures instead of regular signatures.
The funding manager also gains some new state of the local nonces it
needs to generate in order to send the funding locked message, and also
process the funding locked message from the remote party.
In order to allow the funding manger to generate the nonces that need to
be applied to each channel, then AddNewChannel method has been modified
to accept a set of options that the peer will then use to bind the
nonces to a new channel.
In this commit, we update the logic to handle nonce init in
ProcessChanSyncMsg. Once a channel is already open, this is where we'll
get the new nonce data from the remote party we'll use to gain the nonce
we need to sign for their next state.
Before this commit, we would conditionally generate nonces in
RevokeCurrentCommitment. We move this to generateRevocation as this is
called when doing channel sync, and we want to make sure we send the
correct set of nonces.
In this commit, we update the ChanSyncMsg to populate nonce information.
With this change, we can now hide nonce generation further down in the
pipeline and ensure that all callers will have the expected fields
populated.
In this commit, we fix a bug in the `deriveMusig2Shachain` function
where it didn't actually use the passed in revocation root as part of
the hmac invocation.
We also modify the function to be more generally useable as well, as now
the caller can just pass in the revocation root things should be derived
from.
In this commit, we update the co-op close flow to support the new musig2
keyspend flow. We'll use some new functional options to allow a caller
to pass in an active musig2 session. If this is present, then we'll use
that to complete the musig2 flow by signing with a partial signature,
and then ultimately combining the signatures at the end.
In this commit, we update the genHtlcSigValidationJobs function to be
taproot aware. As we actually need a schnorr signature for the taproot
validation, we need to coerce the entire wire type into a schnorr sig
with the ForceSchnorr() method.
In this commit, we update the genRemoteHtlcSigJobs function to be able
to generate taproot jobs. We also modify the sigpool to now use a
input.Signature everywhere. This'll allow us to pass around both ECDSA
and Schnorr signatures via the same interface.
We use a tapscript sighash in this case, as all the HTLC spends will
actually be script path spends.
In this commit, we update the channel state machine with a new set of
functional options that can be used to create/set the musig session
state. When a channel is made during the funding process, the set of
nonces we want to use is already known, so we allow them to be passed
in. Similarly, once the channel is confirmed, then we'll need to create
another channel instance that this times carries the newly generated
nonces to send along side funding_locked.
We also add some utility methods to permit callers to properly generate
nonces in the various contexts.
In this commit, we add a new NewCommitState struct. This preps us for
the future change wherein a partial signature is also added to the mix.
All related tests and type signatures have also been updated
accordingly.
In this commit, we modify the starting logic to note attempt to add a
tower client for taproot channels. Instead, we'll just log that this
isn't available yet.
In this commit, we build on all the prior commits and integrate the new
taproot channels into the existing internal funding flow. Along the way,
we do some refactoring to unify things like signing and verifying
incoming commitment transaction signatures.
For our local nonce, we use the existing functional option type to
derive the nonce based on the initial shachain pre-image we'll use as
our revocation.
In this commit, we add a new wallet level channel type, along with the
new fields we'll need to accept from both parties within the
contribution messages. In this case, we now have a local nonce, along
with the internal musig session.
By using the multimutex here, we'll no longer rely on a single mutex for
the entire musig session set like we used to. Instead, we can use the
session ID to key into a map of mutexes and use those directly.
In this commit, we add a series of abstractions that'll allow us to
easily do funding and also state updates for the new taproot channels. A
partial session is defined by the knowledge of a verification nonce.
Once the remote party sends a signature, we learn of their signing
nonce, and can then complete a session. By using a JIT nonce approach,
we ensure that the signer can generate their nonces randomly and also
at the very last step to avoid having to maintain state.
For our local nonces, we also have an option to use a counter based
nonce derived from the shachain instead of fully random nonces. This
allows us to not have to store ay additional state. Instead, when we
need to go to broadcast, we can just regenerate the nonce then use that
to broadcast.