Schema for AMP invocies.
AMP invoices can be paid multiple times and each payment to an AMP invoice
is identified by a `set_id`.
The A in AMP stands for `Atomic`. All the htlcs belonging to the same
AMP payment (share the same set_id) will be resolved at the same time
with the same result: settled/canceled.
AMP invoices do not have an "invoice preimage". Instead, each htcl has
its own hash/preimage. When a new htlc is added the hash for that htlc
is attached to it. When all the htlcs of a set_id have been received we
are able to compute the preimage for each one of them.
Set of queries to deal with invoices. A couple of things to take into
account:
- Because the queries are not rewritten at runtime, we cannot have a
generic `INSERT` with different tuples.
- Because the queries are not rewritten at runtime, we cannot build
one query with only the filters that matter for that queries. The
two options are a combinatorial approach (a new query for every
permutation) or a generic query using the pattern
```
SELECT *
FROM table
WHERE (
-- Can be read as:
-- Match the filter 1 value if filter_1 != nil
column_1 >= sqlc.narg('filter_1') OR
sqlc.narg('filter_1') IS NULL
) AND (
column_2 >= sqlc.narg('filter_2') OR
sqlc.narg('filter_2') IS NULL
) ...
```
This is the schema for "ordinal" BOLT11 invoices.
The invoices table aims to keep an entry for each invoice, BOLT11 or not,
that will be supported.
Invoice related HTLCs will be stored in a separete table than forwarded
htlcs.
SQLite does not support `SEQUENCE`. We achieve atomic autoincrementals
using primary keys with autoincrement/serial. An invoice `AddIndex`
translates to `invoices(id)` while `SettleIndex` is `invoice_payments(id)`.
sqlc is a tool that generates fully type-safe idiomatic code from SQL.
The result is Go code can then used execute the queries in the database.
The noraml flow looks like:
- The developer write some sql that will update the schema in the
database: new tables, indices, etc
- The developer updates the set of queries that will use the new schema.
- `sqlc` generates type-safe interfaces to those queries.
- The developer can then write application code that calls the methods
generated by sqlc.
The tool configuration needs to live in the repo's root and its name is
`sqlc.yaml`.
LND will support out of the box sqlite and postgres. The sql code needs to
be (almost) the same for both engines, so we cannot use custom functions
like `ANY` in postgres.
The SQLC config file needs to define what is the target engine, we will
set postgres but the generated code can be executed by sqlite too.
In some specific cases, we will `match and replace` some sql lines to be
sure the table definitions are valid for the targeted engine.
As new pending channels will be tracked in the following commits, the
`newChannels` is now renamed to `newActiveChannel` to explicitly refer
to active, non-pending channels.
With this commit we avoid calling LookupHost if we already have an IPv4
or IPv6 address, as we can return that directly.
This avoids asking Tor to resolve an IPv6 address, which it cannot do.
This commit fixed a wrong ordering of initializing subsystem loggers. We
need to make sure "third party" loggers are initialized first such that
when we customize the names later in `lnd`'s packages, the overwriting
of the logger names will take effect.
Without this commit, PRs can fail to be merged via the merge queue, as
it'll fail with this error:
```
Run scripts/check-release-notes.sh
PR gh-readonly-queue didn't update release notes
Error: Process completed with exit code 1.
```
In a previous PR we added a Memo field for channels that could be
specified when opening a channel. This was a reference note-to-self
with no bearing on the functioning of the channel. In that PR, the
memo value was returned only through ListChannels. This commit builds
upon that PR by also returning the Memo field for channels returned by
PendingChannels RPC.
This commit removes the `PrivateTowerURIs` member from the `WtClient`
config struct. This field has been deprecated since v0.8.0-beta and
currently, LND would fail to start if the field was specified.
In this commit, a `DefaultWatchtowerCfg` function is added which is used
to construct a default `lncfg.Watchtower` struct. This is then used to
populate the default watchtower config in the main LND config struct.
