With this commit we streamline the signing code somewhat to make it
easier to understand. With the new flow the spendPkg struct is no longer
needed as we directly pass back the (partially) signed TX.
If `poold` is using a different `lndclient.SignerClient` than the one
used during an account creation it won't be able to generate valid
signatures. `poold` wasn't checking the signatures before sending them
to the backend and it was sending invalid
`ClientAuctionMessage_Subscribe` messages.
With this change `poold` will detect invalid signatures before sending
them, instead of waiting for the backend to send back an error.
Generally the confirmation target is much less granular than a direct sat/byte
due to jumps in the confirmation confidence intervals. Changed the
account manager to take the `feeRate` instead of the `confTarget`. The
caller will be the one with the responsability of calculating the
`freeRate`. If the caller does not provide a value (`freeRate=0`) we
will calculate it from the default confTarget (6 blocks).
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 introduce two distinct ways traders can express their closing
transaction fees: a single address/output script along with a fee rate,
or a list of outputs (script and value) which implicitly expresses the
transaction fees. This provides traders with greater coin control
flexibility, allowing them to directly send their account funds to their
desired destinations efficiently without needing multiple transactions.
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 make sure we don't run into an error when actually sending the
desired amount to an account output, we invoke lnd's fee estimation RPC
to make sure we can construct a transaction that also respects the new
fee parameter.
This commit introduces support for trader account withdrawals to
arbitrary outputs. Traders are able to withdraw their accounts through
either spending paths, multi-sig or expiry, with the latter requiring a
new expiration (to be done as a follow-up). When spending through the
multi-sig path, traders submit their outputs to the auctioneer,
excluding the new account output as that can be reconstructed by the
auctioneer. The auctioneer then creates a transaction adhering to the
trader's constraints and provides a signature back.
This commit aims to address a current gap within the system where trader
account states can become desynchronized if they participated in a batch
and they never received a Finalize message from the auctioneer.
From now on, if an account spend arrives while a trader has a pending
batch, then we assume they weren't able to receive its Finalize message,
and use the spend as an indication that the batch has been finalized.
This works because if a trader signs for a batch and disconnects, the
batch should have already been persisted, and if the batch was actually
finalized (i.e., broadcast without any changes), then the account should
have been spent.
Traders are now able to close their accounts, whether or not they have
already expired, to arbitrary outputs or to a wallet output by default.
If an account hasn't expired, then the auctioneer's signature of the
closing transaction is required to successfully close the account.
In this commit, we overhaul the keys used in the multi-sig construction
of an account to prevent script reuse and provide plausible deniability
between account outputs to third parties. This is done by tweaking the
trader's key with two new components:
1. A per-batch key, which is obtained from the auctioneer during account
creation. Every time the account is modified or participates in a
cleared batch within the system, the per-batch key is incremented by the
curve's base point, resulting in a different key used in the account
script.
2. A shared secret derived using Diffie-Hellman between the trader's and
auctioneer's base keys. By using this secret, we provide plausible
deniability to third parties with knowledge of the base keys and
per-batch key.
The resulting tweaked key for the trader is then used as the tweak for
the auctioneer's base key.
The account manager is a subsystem of the client that will be
responsible for management of all CLM accounts on-chain. This initial
version only supports opening accounts at the moment, but this will be
extended later on to also support closing and modifying them. Open
accounts are also watched for their confirmation and spend, though the
spend path remains unhandled.
The commit stands alone by itself, and is not yet integrated into the
server as we still need to satisfy its dependencies, which we'll do in
the following commits.
