Document the configurable maximum account payment size and optional
channel balance reservation check, including their defaults, fee
handling, and operational limitations.
Add an opt-in check that prevents the sum of all account balances from
exceeding the node's available local (outbound) channel balance. When
enabled via the new accounts.check-channel-balance config option, the
service rejects balance allocations that would over-provision the node:
creating an account, an administrative credit, or an administrative
balance increase now fails with ErrBalanceReservationExceeded if it
would push the total allocated balance above the node's local channel
balance.
Note that the total channel balance may still decrease below the already
allocated account balance. This can occur if the node operator decreases
the total channel balance through non-account related activity.
The check is a no-op by default to preserve the historical behaviour
where the operator manages over-provisioning themselves (accounts can
legitimately be created before channels are funded). Invoice-driven
credits are unaffected, as they are backed by real inbound payments.
Add an opt-in cap on the total amount a single account payment may
debit, including routing fees, enforced at the account interceptor for
both SendPaymentV2 and SendToRouteV2. When the new
accounts.max-payment-size-msat config option is set to a non-zero
value, payments whose amount plus fees exceeds it are rejected with
ErrPaymentExceedsMaxSize before the balance check and before any funds
are reserved.
For SendPaymentV2, the configured fee limit is included in the capped
amount. For SendToRouteV2, the route's stated fee is included.
This gives operators a guard rail against a compromised or misbehaving
account macaroon draining its balance in a single large payment. The
cap defaults to 0 (disabled), preserving existing behaviour, and is a
first step towards the finer-grained per-account spending controls
requested in the issue.
The `-V` flag inherited from lnd printed the integrated lnd version
(`build.Version()`) instead of litd's own version, while litd's own
`--version` flag already reported the correct value via RichVersion().
Consolidate both flags so either one prints litd's version.
Fixes#1091
Signed-off-by: 0xfandom <kashyapshivank01@gmail.com>
Add a release note to the upcoming release notes document for 0.17.0
detailing the newly added support for custom permissions via the
`--permission` flag in `litcli sessions add`.
Document the default KVDB-to-SQL migration in the 0.17.0 release
notes, including the new databasebackend option and the available
SQLite and Postgres backends.
Also note that users who want to remain on bbolt must set
databasebackend=bbolt before the SQL migration runs, since the legacy
bbolt database is tombstoned after a successful migration.
Mark the bbolt backend as deprecated and note that support will be
removed in a future release.
The Makefile uses GNU Make features, which on FreeBSD requires the
gmake port rather than the base system make. Add a short note to the
compile instructions so FreeBSD users know to install gmake and use
it in place of make.
Closes#859
Move the LiT/LND compatibility matrix into docs/compatibility.md for
archival so future releases no longer require README updates to adjust
the table.
Update README to direct users to release notes for minimum lnd versions
and fall back to the archived table when not specified.
