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.
To allow a bidder to be a mobile or Tor only node, we only require the
asker to be reachable through clearnet. This requirement wasn't
implemented correctly in the funding flow. This commit fixes that and
turns the logic around. The asker creates the channel but the
bidder does all the work for it (connecting out and registering the
funding shim).
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.
As a preparation to avoid package import cycles when introducing more
generic terms, we move the FeeSchedule interface and its
LinearFeeSchedule implementation to the terms package.
To fix an issue where the trader daemon wouldn't properly shutdown if an
authentication was still ongoing, we add a quit chan to the account
subscription.
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.
To track whether or not an account was recently involved in one or more
batches, we need to add a new pending state. This pending state is
different from the normal pending update from a balance modification as
the auctioneer allows an account in this state to participate in a
batch. A scenario is possible where an account was involved in two or
more consecutive batches that both aren't confirmed on chain yet. To
handle that special case we need to also track the special account state
on the trader side.
With this commit we address two issues with the connection to lnd:
First, we didn't specify the required version of lnd even though we used
features of 0.11.0. This is fixed by pinning the version to 0.11.0
explicitly and specifying the subservers that are required to be active.
Second, we didn't wait for lnd to be synced to its chain backend. We use
the new functionality in the lndclient repo that does exactly this.
In this commit, we update the account response to return the total
"available balance". Which is computed as the total useable balance of
the account assuming all the outstanding orders are matched in a
worst-case manner.
In this commit, we add a new test that fails with the current logic in
`validateOrder`. The function as isn't doesn't isolate the orders for
each account, so the orders from account A can prevent a user from
making an order to account B.
The funding feerate field was previoulsy unused, so we rename it to
"max batch fee rate" in order to use it to communicate to the server the
maximum fee rate we are willing to pay to be included in a batch.
We also increase the default value to 500 sat/vbyte.
The ReservedValue method returns the worst case value the must be
available in the account to ensure the trader can pay for the order
including its fees.
In this commit, we add some new logic to reconcile our local order state
with what the auctioneer has on start up. However, we'll only update our
local order if the auctioneer shows the order as being cancelled. For
all other cases, we should reconcile that difference if we have a
pending batch that was confirmed while we were offline, or confirmed
after we sent our signature. In this case, we'll log the order nonce
with a warning log-level so users can track down any possible issues.
