In this commit, we make sig job handling when singing a next commitment
non-blocking by allowing the shutdown of a channel link to prevent
further waiting on sig jobs by the channel state machine. This addresses
possible cases where the aux signer may be shut down via a separate quit
signal, so the state machine could block indefinitely on receiving an
update on a sig job.
This is a requirement for replacing the quit channel with a Context.
The Done() channel of a Context is always recv-only, so all users of
that channel must not expect a bidirectional channel.
In a future commit, we'll use the new field to ensure that if we add any additional records, they aren't over written by the TLV records that would be encoded.
In this commit, we expand some of the existing chan sync tests to cover
taproot channels (the others already did). Along the way, we always
assert that the `PartialSig` is populated on retransmission. In
addition, we now send the new commit sig rather than the existing
in-memory one to test the new logic that re-signs the commitment.
In this commit, we fix an existing bug with the taproot channel type that can cause force closes if a peer disconnects while attempting to send the commitment signature.
Before this commit, since the `PartialSig` we send is never committed to disk, the version read wouldn't contain the musig2 partial sig. We never write these signatures to disk, as each time we make a new session, we need to generate fresh nonces to avoid nonce-reuse.
Due to the above interaction, if we went to re-send a signature after a disconnection, the `CommitSig` message we sent wouldn't actualy contain a `PartialSigWithNonce`, causing a protocol error.
Before this commit, we weren't properly setting the aux HTLC blob when
we went to retransmit a signature. We fix this by setting the
`ExtraData` field as expected in the `CommitSig` message.
We need to check if it has a tapsript root first, as if it has a
tapscript root, then it's also a taproot channel. By checking if it has
a tapscript root first, we'll now display the proper commitment type for
RPC responses.
We want to re-use the logic of the SendPaymentRequest code, most notably
the logic that prints the payment updates as a nicely formatted table to
the console, in other projects.
We might be trying to send an invoice amount that's greater than the size of the channel, but once you factor in the custom channel logic, an actual HTLC can be sent over the channel to pay that larger payment.
As a result, we'll skip over this check if a have a custom HTLC.
The goal of the test is just to make sure that we can pick up the wire
records. With the prior bug fix, if we also modify the outgoing amount
here, the normal checks to ensure that the fee has been paid will
trigger with this larger amount, which wasn't factored in during initial
route creation.
This fixes an issue where the switch's forwarding logic would think the
bandwidth to forward an HTLC was insufficient for a custom channel HTLC,
because we only overwrote the HTLC's amount and not the packet's (which
is just a short cut struct member anyway).
It seems like the amount given to the getBandwidth is 0 in some cases
(keysend) and non-zero in other cases (invoice payment).
If we use custom channels, then that amount will likely not be the
actual HTLC amount we're going to put on chain. So we have to use a zero
amount for the MayAddOutgoingHtlc check, otherwise we might seem to go
below the local channel reserve even though we'll end up sending a very
small amount only.
And since the check here is just to find out we're not already at the
maximum HTLC capacity for this channel, we can safely use the amount of
0 for the check, which is handled properly in the link logic.
In this commit, we fix a bug that would cause a global message router to
be stopped anytime a peer disconnected. The global msg router only
allows `Start` to be called once, so afterwards, no messages would
properly be routed.
