In this commit, we test all the combinations of rbf close and taproot
chans. This ensures that the downgrade logic works properly.
Along the way we refactor the tests slightly, and also split them up, as
running all the combos back to back mines more than 50 blocks in a test,
which triggers an error in the itest sanity checks.
In this commit, we implement logic to downgrade to the legacy coop close
for taproot channels. Before this commit, we wouldn't allow nodes to
start up with both the taproot flag and the rbf flag activated.
In the future, once we implement the spec updates, we'll add support for
this combo, and can revert parts of this commit.
Previously, if a DB version wasn't available, we re-ran all schema
migrations without verifying the schema version. However, setting a
base schema version is essential because some earlier migrations were
not idempotent. This commit addresses the issue by using the current
schema version provided by sqlc as the base.
In this commit, we fix a flake in the
`TestRbfChannelFlushingTransitions/early_offer` test. The fix is simple:
this is actually an "iteration", as we have a self transition to the
ChannelNegotiation state first. We also don't need to send the
remoteOffer, so we set `sendInit` to false. The offer still needs to be
passed in to ensure that the assertions work however.
In this commit, we reduce log spam a bit during state transitions. We
only log the type of the event when sending the event, as we'll print
the same event when creating the queue "applying", and later when
processing". Next we remove the "applying" log as that first event will
always be logged twice.
The combo of these to changes makes the logs much easier to follow.
Fixes a bug introduced by #9605, fixes#9648.
We return a specific error in the RPC permission interceptor for the
case where the wallet is already unlocked or is still locked.
We need to catch those errors correctly to give the user a bit more
context on what to do.
We now return the next retry fee rate in `TxFailed` event in
`TxPublisher`. When handling the event, `UtxoSweeper` will update the
inputs to make sure the starting fee rate is set before attempting the
next sweep.
We now always create the sweeping tx even though the budget cannot be
covered so we don't miss the deadline. Note that the fee bump will fail
once the provided wallet input cannot cover the increase fees, which is
fine as these inputs will be marked as failed and be retried again in
the next block. When that happens, if there are new wallet UTXOs, a new
batch will be created to perform the fee bump.
