If we encounter an account in the state initiated when performing the
account recovery, we certainly don't want to send funds to it again. If
lnd finds the transaction that funded the account, great. We can try to
recover it. If the transaction isn't found, it is very likely that it
was never broadcast. We update the account's state to
StateRecoveryFailed in that case.
React to the special error that is sent from the auctioneer if it only
knows of a reservation. The RPC information is turned into a special
error so it can be handled by the account manager later.
We need the same error on the server and client side so we add it to
the client part of the repository. The new error message contains all
information about an account that was only reserved but never completed.
If we only have a reservation on the auctioneer's side when a
trader tries to connect, we cannot create a full account subscription
and therefore not follow the normal message flow for recovery. Instead
we return a special error message that contains the information we have
that should be enough to restore the account on the trader's side.
The trader still has to provide a valid signature with the trader key
so no probing for this information should be possible by any third
party.
To be able to recover an account that was only reserved before the
data loss occurred at the trader, we need to store more information
in the auctioneer's reservation. Specifically we also need to store
the account expiry, the trader key and the value. Previously the
value was only validated, now it will also be stored in the
reservation.
Most of the code is heavily borrowed from the chanfunding package in
lnd, except for some minor changes to account for the difference in
weights. Ideally, that package is refactored and abstracted such that it
doesn't only apply for channel funding.
We use the same proto message types everywhere for these kinds
of fields:
- absolute amounts (sats): uint64
- fee rates (sat/kWU): uint64
- fee rates (ppm): uint32
- blocks (absolute and relative): uint32
Additionally we unify the comments and remove the [ json_name = "" ]
declarations in the trader proto as they aren't needed with the
jsonpb marshaller that we use.
Then we align the naming of the account key to be called trader key
everywhere instead of user's sub key.
