This addresses a potential panic when a tower has one of its candidate
sessions chosen, but its only reachable address was removed by a
user-initiated RPC before the fact.
In this commit, we update the tower+link logic to tag a commitment as
the new (tweakless) format if it applies. In order to do this, the
BackupTask method has gained an additional parameter to indicate the
type of commitment that we're attempting to upload. This new tweakless
bool is then threaded through all the way to back up task creation to
ensure that we make the proper input.Input.
Finally, we've added a new test case for each existing test case to test
each case w/ and w/o the tweakless modifier.
With the introduction of the WatchtowerClient RPC subserver, the lnd
configuration flag to specify private watchtowers for the client is no
longer needed and can lead to confusion upon users. Therefore, we remove
the flag completely, and only rely on the watchtower client being active
through a new --wtclient.active flag.
We do this as a convenience for WatchtowerClient users so that they do
not need to re-add towers upon restarts. We ensure not to re-add towers
that have been previously removed by determining whether it has any
lingering active sessions.
In this commit, we extend the wtclient.Client interface with the
following methods:
* AddTower
* RemoveTower
* RegisteredTowers
* LookupTower
* Stats
Care has been taken to ensure that any in-memory state updates are
_only_ performed after a successful database update.
These methods are currently unused, but they serve as a dependency for
the upcoming WatchtowerClient RPC subserver.
These operations are currently unused, but will be integrated into the
TowerClient at a later point as future preparation for the
WatchtowerClient RPC subserver, which will allow users to add, remove,
and list the watchtowers currntly in use.
This currently takes O(N) time as there does not exist an index of
active client sessions for each watchtower within the client's database.
This index is likely to be added in the future.
This commit modifies the client's filtering when selecting from existing
sessions. The new logic compares the configured TxPolicy with the
TxPolicy of the candidate sessions, which has the effect of ignoring
operational parameters such as MaxUpdates. Prior, changing MaxUpdates
would cause the client to request a new session even if it had perfectly
good slots available in a policy with an equal TxPolicy.
This commit fixes a bug that would cause us to request more sessions
that needed from the session negotiator. With the current stat ticker,
we'd ask the negotiator for a new session every 30s if session
session negotiation did not return before printing the stats. Now we'll
avoid requesting to sessions by jumping back into the select loop.
Now that the committed and acked updates are persisted across restarts,
we will use them to filter out duplicate commit heights presented by the
client.
