To allign with our other projects, move our accounting docs into a base
docs dir. Since we've sent the existing link out, we leave a docs file
pointing to our new docs location so nobody gets lost.
To allow running our accounting report without a backing bitcoin node,
we allow the fee function provided to be nil. In these cases, we log
the entries which we cannot lookup fees for so that users have the
option to manually lookup those fees.
Previsously, we would try to get the best fiat granularity for a period
even if the disable fiat flag was set. If the period queried is longer
than the longest time that we can query the coincap api for, our request
would fail. This is not practically an issue, because the API allows
20 years of data, but this error does stop setting of a 0 start time,
which is nice for getting an all time report for your node.
LND includes the fee amount in the total amount for a transaction and
lists it in the fee field. In this change we separate the fee from the
amount so that we do not double count. We do not expect fees for
receives, so we add a check for this.
When the remote party spends one of our htlcs on chain, we report a zero
value transaction. These are of no auditing value, since they are
exposed in more detail in lnd's close summary, so we ignore them.
Previously, if we generated a report while a channel was pending open
or close, it would not have been picked up as a channel. This change
adds pending channels and simplifies our on chain sorting to just have
opened and closed channels (independent of the source where we got the
channel information).
Update our price getting function to return the timestamped data point
so that prices are easier to audit. We also choose to earlier timestamp
rather than picking the average when a timestamp lies between two points
to make our calculation more transparent.
We have a lot of different payment formats in lnd, since the payments
database has been migrated multiple times. We need to account for the
following:
- Legacy payments: settled, no htlcs present
- In flight payments: not settled, no htlcs present
- Keysend payments: no payment request
- Sendpayment + dest: no payment request present
Since we need to list all payments (an invoice settled in our period
could have been send by a payment before the period), we update our
code to not fail in the case where we do not know payment destination.
This will result in legacy circular payments (that were made with no
payment request) not being identified as circular payments (as well as
their corresponding invoices). We log an error for this, and make a
note of it in our docs. This should not be an issue for payments made
by newer versions on lnd, because they have the information we require.
Our reporting config structs are quite large, and require wrapping
paginated calls, so we add a constructor to easily create these structs.
This is particularly useful for packages that import this package
rather than running faraday as as service.
The granularity with which we query our price backend is an
implementation detail that we don't need to expose to users. Rather than
making this configurable, we just calculate our best possible level
of granularity server side, and leave this decision out of the user's
hands.
