In this commit, we update the breach arb to support taproot channels. We
utilize the new taproot briefcase space to store both control blocks,
and also the first+second level scripts for the set of HTLCs.
We pull the information from the sign descriptors and store them in the
resolutions. However, the resolvers created end up duplicating the
resolution data, so we update the sign descs as needed during start up.
In this commit, we add a new taproot specific briefcase to store the
control block and tap tweaks for all taproot outputs. We chose this
route as many of the existing fields are serialized in line, so we
aren't able to serialize this new taproot specific information in the
existing briefcase.
For taproot channels, we need to thread through the control block in the
sign descriptor. We also ensure that the proper sign method is set. We
leverage the new input.Signature generalization be able to support
handling both schnorr and ECDSA signatures for the second level output.
In this commit, we add the tapscript tree to the ScriptInfo struct, as
in many cases the caller needs the tree in order to generate the control
block or obtain the taptweak which is needed to spend revoked outputs.
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.
Olaoluwa Osuntokun