The channel-restriction rule was previously fragile because it failed to
initialize when a restricted channel was closed while the session was
inactive. This often caused unnecessary session invalidation and blocked
users from managing their nodes.
This change makes the rule resilient by allowing it to start even if
some channels in the deny-list are missing from the node's current
active set. To maintain high performance, this implements a negative
cache that tracks unknown channel IDs, shielding LND from redundant RPC
calls during request evaluation.
Only having a negative cache without invalidation can be a security
problem. Someone could apply a rule with a future guessed channel id
such that the channel restriction populates the checkedIDs map with it.
After the channel was opened, we'd then allow making actions on the
channel because we don't know about the channel's id in the getChannelID
check.
To ensure security isn't compromised by the cache, this adds a
self-healing retry mechanism. If the firewall encounters an unknown
channel outpoint while it still has unmapped restricted IDs, it clears
the negative cache and forces a single retry in the next RPC call. This
ensures that any newly opened restricted channels are correctly
identified and blocked without adding latency to the common path.
Note: This approach deliberately accepts potential cache thrashing in the
edge case where a user repeatedly requests an unknown channel point
while a permanently missing ID exists in the deny list. This trade-off
is accepted to prioritize security (fail close) over performance in this
specific invalid state.
- Replace occurrences of `// nolint:lll` with `// nolint:ll` across
files for consistency.
- Reformat multiline strings, comments, and function parameters to
improve clarity and adhere to style guidelines.
- Add `// nolint:ll` comments where necessary to prevent linter
warnings.
To better represent the interface and to free up the use of the
ActionsDB name as this will be used to represent the full Actions DB in
an upcoming commit.
This commit updates:
- LND
- pool
- loop
- taproot-assets
- faraday
- lighting-node-connect
- aperture
- lndclient
- btclog
We start using the new btclog v2 library and the associated breaking
changes in the lnd/build package.
With this commit, we deprecate the `--remote.lit-maxlogfiles` and
`--remote.lit-maxlogfilesize` options and introduce new logging options
under the `--remote.lit-logging` namespace.
Finally, the LND update introduced a new `MaxBlocksMinedPerTest`
variable in the `lntest` package that we now need to override in order
for our itests to pass.
Update the PrivacyMapDB interface methods to take contexts (both the
methods themselves and the call-back params) and then ensure all
implementations are updated and all call-sites pass contexts through
correctly.
We add a new channel constraint rule that enforces limits on channel
opening for the OpenChannelSync and BatchOpenChannel end points.
The channel constraint rule takes care about:
* min channel size
* max channel size
* max push amount
* no closing address was used
This adds an on-chain budget that handles requests and responses for the
following endpoints:
* OpenChannelSync
* BatchOpenChannel
The budget rule checks that the onchain fee rate is not violated and
that pending and confirmed amounts are handled correctly.
An edge case can occur when lit crashes or shuts down after the budget
rule has forwarded a request but didn't receive a response yet. The
pending budget is not removed in case the request didn't go through and
is not accounted towards the spent budget in case the request did go
through. To be able to handle these cases in the future we add a unique
identifier to the request, that can be checked by calling LND's channel
bookkeeping APIs. Not all of them expose the identifier yet, which is
why pending actions cannot be deleted yet. This leads to underspending
of the budget and can be fixed by user intervention by creating a new
session. The memo prefix is removed when reading forwarding the
bookkeeping requests for privacy reasons.
We pass a random lnd connection identifier to the rule enforcer that is
unique per lnd connection lifetime. It is used to generate unique
request identifiers that amend the non-unique request identifiers that
are passed from lnd.
This is to tolerate unknown rules sent from the autopilot for the
`autopilot features` command.
Otherwise, when trying to register a feature that requires an upgrade, a
more user friendly error is returned.
This commit expands the RealToPseudo methods to take in a privacy map db
reader. This allows the methods to check if the privacy map db already
contains an entry for a "real" string before generating a new one.
For now, only an empty PrivacyMapReader is ever provided to the
RealToPseudo call. This will be changed in the following commit.
