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.
This commit moves the deletion of the initial forwarding policy to the
end of `stateStep` to make sure the router has persisted it to disk
before the deletion.
Because we now send the correct initial forwarding policy to Brontide,
the correct initial values are inserted into the link and we no longer
need to update the link in a later step.
This will allow us to also set the TimeLockDelta and HTLC settings
when creating the channel. We leave the actual implementation of
the RPC and CLI changes to another PR, this is just to make
things more consistent.
