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.
In this commit, we refactor all the other constructors for the input to
use MakeBaseInput. We also add a new set of functional options as well.
This'll be useful later on to ensure that new options are properly
applied to all the input types.
This will be used by external callers to modify the way we resolve
contracts on chain. For a given contract, we'll store an extra "blob",
that will later be presented during the sweeping phase.
This commit updates the traffic shaper's bandwidth query method to
accept the link bandwidth as a parameter. This allows an external
traffic shaper to optionally return the link bandwidth as the payment
bandwidth.
We added the custom data to the pending channels but forgot to also
send the response RPC message to the custom channel parser so it can
turn it into human-readable JSON.
We always need to set the close output in order for us to be able
to calculate the closing keys. Especially if there is only a dust
balance in BTC terms but perhaps a valuable amount in custom channel
funds.
With this commit we populate additional information about the close
outputs (including potential custom channel data) in the close update
RPC message.
This will allow custom channels to find out how the additional close
outputs look like on chain and what data they might commit to.
We also hook up the aux custom data formatter, so it can format the
custom channel data to JSON.
In this commit, we move to add the internal key to the delivery addr. This way, we give the aux chan closer the extra information it may need to properly augment the normal co-op close process.
In this commit, we fix an issue with co-op closes for taproot channels. Before this commit, we'd think that the remote party broadcasted a state very far in the future, and try to execute DLP. The wallet would properly credit the settled funds, but we'd mark the close in the DB as a force close.
To fix this, we also watch for the RBF sequence number we use in this scenario.
