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.
In this commit, we update the set of intents and assemblers to recognize
musig2. For this change, we use a new bool, `musig2`, then use that to
determine if we need to use the new taproot funding scripts or not.
In this commit, we extract the musig2 session management into a new
module. This allows us to re-use the session logic elsewhere in unit
tests so we don't need to instantiate the entire wallet.
In this commit, we modify the to_local script to use a script path for
the revocation scenario. With this change, we ensure that the internal
key is always revealed which means the anchor outputs can still always
be swept.
In this commit, we restore usage of the NUMS key for the to remote
output, as this allows a remote party to scan the chain in order to find
their remote output that in emergency recovery scenarios.
Unlike the old HTLC scripts, we now need to handle the various control
block interactions. As is, we opt to simply re-compute the entire tree
when needed, as the tree only has two leaves.
In this commit, we add GenTaprootFundingScript, which'll return the
taproot pkScript and output for a taproot+musig2 channel. This uses
musig2 key aggregation with sorting activated.
The final key produced uses a bip86 tweak, meaning that the output key
provably doesn't commit to any script path. In the future, we may want
to permit this, as then it allows for a greater degree of
programmability of the funding output.
In this commit, we add the new types that'll house musig signatures with
and without their nonces. We send the nonce along with the sig
everywhere but the co-op close flow.
In this commit, we update the Sig type to support ECDSA and schnorr
signatures. We need to do this as the HTLC signatures will become
schnorr sigs for taproot channels. The current spec draft opts to
overload this field since both the sigs are actually 64 bytes in length.
The only consideration with this move is that callers need to "coerce" a
sig to the proper type if they need schnorr signatures.
There is a race condition,
- goroutine_1: performing `stateStep` under `channelReadySent`. Once
`receivedChannelReady` returns true, it will mark the channel state as
`addedToRouterGraph`, which will delete the initial forwarding policy
for private channels.
- goroutine_2: performing `handleChannelReady`, which processes the
remote's channelReady message. It will ask brontide to `AddNewChannel`
in the end.
- goroutine_3: performing `handleNewActiveChannel` in brontide, which
will query the initial forwarding policy and fail to find it because
it's already deleted in goroutine_1.
To fix it, we require `receivedChannelReady` to also check that the
channel's barrier signal in the map `handleChannelReadyBarriers` doesn't
exist, as this signal is removed once `handleChannelReady` finishes
adding the channel in brontide.
This commit is a pure code move. We add a new method
`handleChannelReadyReceived` to handle the channel's state change after
the remote's channel ready message is received.
