Instead of deleting the partial order (which had a bug in it that it
didn't remove the order creation timestamp) we for now only update its
status to failed. We'll want to implement proper housekeeping at one
point to get rid of archived orders. But for now we have the
--active_only flag that helps to easily filter out archived orders on
the command line.
When a terminal error is received, it is not enough to stop the server
itself to terminate the trader daemon because the main goroutine still
blocks on the read from the shutdown channel.
Instead we have to request a proper shutdown through the signal package
to initiate a full trader daemon stop.
In this commit, we restrict the validation in SubmitOrder to only accept
durations of orders that show up in the Terms call. The way this is
implemented, we'll be able to easily add new durations in the future
without modifying the client each time too much.
In this commit, we replace the existing min/max duration system with a
single field that expresses the expected duration of a lease. Note that
we've left some of the exiting logic in place that select a duration
from a bid in an attempt to make this more of a "soft fork" which will
allow any existing orders to be cleared out as normal before we switch
over.
Once we add multiple durations (this commit assumes a single duration),
we'll need to modify the verification logic to be able to handle
multiple clearing prices for a given batch.
In this commit, in order to make accounting for account
modification/creation transactions a bit easier, we'll now always add a
label describing the transaction within the account manager. The user is
also able to set their own prefix to the label as well to allow
insertion of custom meta data.
We also want to know whenever we reject a batch either fully or
partially so we also store an event for each involved order in case of a
reject message.
We create and store an event every time an order is involved in a match
making process. We track the three distinct phases a batch goes through
from the trader's point of view so we can visualize this process in the
future.
We add a new verbose flag to the ListOrdersRequest message that causes
the RPC server to include all events of an order in the response.
The orders are now also returned sorted by their creation timestamp.
In this commit, we modify our connection logic to accommodate tor nodes
that wish to sell channels. If we detect a node has even a single Tor
addr, then we'll also try to connect out to the taker that we're selling
a channel to.
We are going to use the same timeout for multiple different things and
rename it to be more generic. At the same time we use route.Vertex
instead of [33]byte to make things easier to read.
If a trader wishes to only get channels from new peers, we check each
match against all nodes we already have open or pending channels with.
We don't look at pending closing channels in case a trader wants to buy
new channels as soon as one closed out.
To avoid a race error in lnd when we try to connect to the same node
twice in a short interval, we instead de-duplicate the connection
attempts by node pubkey and only try connecting once per remote peer.
Because we have to always expect an OrderMatchPrepare to be sent
multiple times, we need to make sure we clean up our funding shims from
the previous pending batch.
This commit allows the account manager to handle the situation where
an account participates in multiple consecutive batches that might still
be in the mempool. Once the first batch confirms, the database state of
the account might differ from the batch key used in that earlier batch.
We need to cancel old spend and conf watches and only watch the latest
batch for confirmation. While an account is in this pending batch state, no
user modification like deposits or withdrawals are allowed so it's safe
to just jump to the latest batch and wait for confirmations on that one.
