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.
This commit removes another check for TLV payload support of the
destination node. We assume TLV payloads as the default everywhere else,
so we just remove two checks that were previously forgotten.
In this commit, we fix three existing bugs in the way we make
`ResolutionReq` for breach handling:
1. We were passing in the commit blob of the *current* channel state,
instead of the one stored in the revocation log for this breached
state.
2. We were using theirDelay for CsvDelay, when we want ourDelay, which
in this case will be 1 CSV, as this is a non delayed output.
3. We also need to pass in the delay for the remote party's to_local
delayed output.
Similar to the sweeper, when we're about to make a new breach
transaction, we ask the sweeper for a new change address, if it has one.
Then when we go to publish, we notify broadcast.
We checked for OP_DROP, but both of the local+remote scripts end in `N
OP_CSV OP_DROP`.
So for now, we'll check for the maturity delay, with the assumption that
this won't be 1 for regular taproot chans. Either way, everything else
is correct as the witness is the same, but this may lead to display
issues down the line.
In this commit, we start to use the AuxSweeper (if present) to obtain a
new extra change addr we should add to the sweeping transaction. With
this, we'll take the set of inputs and our change addr, and then maybe
gain a new change addr to add to the sweep transaction.
The extra change addr will be treated as an extra required tx out,
shared across all the relevant inputs. This'll also be used in
NeedWalletInput to make sure that we add an extra input if needed to be
able to pay for the change addr.
In this commit, we add a new AuxSweeper interface. This'll take a set of
inputs, and a change addr for the sweep transaction, then optionally
return a new sweep output to be added to the sweep transaction.
We also add a new NotifyBroadcast method. This'll be used to notify
that we're _about_ to broadcast a sweeping transaction. The set of
inputs is passed in, which allows the caller to prepare for the ultimate
broadcast of the sweeping transaction.
We also add ExtraTxOut to BumpRequest pass fees to NotifyBroadcast. This
allows the callee to know the total fee of the sweeping transaction.
