This is an intermediate state where an account has met its expiration
while having a pending update waiting for confirmation. The introduction
of this state was necessary as the existing StateExpired state was not
sufficient to handle all edge cases regarding account renewals. Now
that this state exists, we can be sure renewals cannot happen until the
account is both confirmed, unspent, and expired.
We add a new order version that is allowed to submit lease durations
outside of the default/legacy 2016 block duration.
No new fields are added, so nothing changes in the serialization or the
digest. This version only signals that the client is able to process
batch requests with multiple duration buckets.
Because the batch Versions are in the order package, the use of
order.DefaultVersion is confusing and not clear to be related to the
version of the _batch_, just from its name. We fix that by renaming the
versions of the batch.
This commit fixes a wrong assumption the recovery was implemented with.
The auctioneer will only switch to the closed state once the closing TX
confirms. We therefore shouldn't map this to pending closed as that'll
try to re-broadcast the close TX (which fails for confirmed
transactions).
To make the account manager less dependent on the wallet state of lnd,
we use the latest TX state that we now store for the account instead of
the lnd ListTransactions RPC where possible.
This fixes account recovery for lnd nodes that were restored from the
seed and don't remember/detect all Pool transactions automatically.
If we detect we have a pending batch in the local database that was
replaced by a different transaction, we try to clean up funding shims
and pending channels on startup as well.
To allow that, we use the funding manager as the BatchCleaner
implementation.
We'll soon need a reference to the funding manager in the server, so we
can pass it to the auctioneer client. To enable that, we initialize and
use it in the server instead of the rpcserver.
Because we now only use the batch TX from the local pending batch
snapshot, the redundant information in the pending batch TX key is not
needed anymore.
To be able to fully clean up an old, pending batch snapshot on daemon
startup, we first need to switch to a method that returns the full
snapshot instead of just its ID.
In preparation for loading the full local pending batch snapshot instead
of only the ID when starting the daemon, we add a new function to the
database to retrieve the snapshot.
Since it's ultimately the funding manager's job to clean up
non-finalized pending channels and/or funding shims, we move that
functionality into the manager now.
To make testing easier and give the funding manager access to the
freshly refactored cleanup functions, we switch them over to use the
funding manager's base client interface instead of the full RPC client
interface.
Since this error caused quite some confusion among our users, we demote
it to info and change the text to further explain what's happened.
If a trader is involved in a batch and the channel funding fails in the
batch sign phase, a pending channel is never created in lnd. If the next
batch prepare message comes in, we try to clean up all pending channels
of the previous attempt. Because the channel negotiation failed and
there is no pending channel, cleaning up fails with this message.
We also need to make the channel abandonment independent of a particular
format of a pending batch, so we refactor it into a standalone function
instead of a method on the in-memory batch format.
We want to be able to clean up after a pending batch that is replaced.
We want to do this for both in-memory pending batches but also for
persisted local snapshot batches on startup. Therefore we need to
refactor the cleanup methods into independent functions.
We want to move the funding manager into its own package in the next
commit. This commit prepares everything we can to make the actual move
as simple as possible.
By passing in the quit channel where needed, we make the
funding manager a bit less stateful and easier to reason about.
By sending channel updates to the funding manager's update chan
directly, we also make it more clear who's responsible for processing
the updates.
To make iterating over batch IDs easier, we add a new helper function
that returns all batch IDs starting at the start key (inclusive) and
ending at the end key (inclusive) by decrementing the public keys. If
the end key cannot be reached by decrementing the start key by a maximum
of 10k times, we abort and return the first 10k items (without the end
key).
