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 kvdb-to-SQL data migration polls lnd's ListMacaroonIDs RPC, which
only becomes available once lnd reaches its "RPC active" state. On
nodes with a large channel/graph state, lnd can take well over a
minute to get there after the wallet is unlocked, which exceeded the
previous fixed 60-second (120 x 500ms) poll budget and caused the
migration - and therefore litd startup - to fail permanently,
requiring a manual restart.
Replace the fixed attempt cap with a wait bounded by the new
--lndreadytimeout config option, defaulting to a generous 10 minutes,
while still aborting early if the daemon is shutting down. The wait
happens inside the migration's SQL write transaction, so it is kept
bounded rather than unbounded as a safety backstop.
Add testSuperMacaroonOnStartup to verify startup baking logic. The test
restarts the node with the auto-baking config flags and asserts the
macaroon is baked with read-only or read-write permissions accordingly.
Also add validation tests verifying that starting with an invalid path
suffix or in stateless-init mode with baking enabled fails as expected.
Verify permission addition/expansion by starting the node with sub-servers
disabled and then restarting with sub-servers re-enabled. Also verify
the none config choice, asserting that no super macaroon file is
baked/created on startup.
Automatically bake a super macaroon on startup if it doesn't already
exist on disk and the `bake-super-macaroon` option is configured.
On startup, the node verifies if the super macaroon file exists. If
it does, it parses the macaroon, extracts and verifies the version and
root key ID, and asserts that the macaroon permissions exactly match
the expected active permissions. If there is a mismatch, the macaroon
is regenerated and overwritten on disk. If the file does not exist, a
new super macaroon is baked and written directly to disk.
Also validate that the `bake-super-macaroon` option is not enabled when
LND is running in stateless initialization mode, failing startup early
if they are used together.
Introduce configuration flags to enable baking a super macaroon on
startup. Add --bake-super-macaroon (none, read-only, read-write) and
--super-macaroon-path.
Also add validation logic to ensure that the configured super macaroon
path ends with the expected '.macaroon' suffix, rejecting startup early
otherwise.
Introduce helper functions in the macaroons package to manage super
macaroon files and permissions. Add SuperMacaroonExists,
MacaroonMatchesPermissions, and BakeAndWriteSuperMacaroon.
Add integration tests inside itest/litd_accounts_test.go to verify
retrieval of account payments against a running LND node, validating
correct responses for ID/label lookup, offsets, pagination limits,
and counting of total payments.
Introduce the 'payments' subcommand under 'litcli accounts' to query
account payment history. Supports parameters for offset, page size
limits, and counting of total payments.
Implement the AccountPayments handler on the Accounts RPC server.
The handler resolves accounts by ID or label, loads its payment hashes,
applies pagination constraints, and fetches complete payment details
concurrently from LND's TrackPaymentV2. It also returns pagination
metadata including the total count of payments.
Introduce the ListAccountPayments and CountAccountPayments methods to
the accounts Store interface.
ListAccountPayments enables retrieval of a paginated list of payment
entries associated with a given account ID, supporting offset and
limit. CountAccountPayments returns the total number of payments
associated with the account.
Implement ListAccountPayments in the Bolt-based kvdb account store.
The retrieved account payments are sorted in ascending lexicographical
order of their payment hash.
Add sqlc queries to select account payment hashes from the database.
Implement the ListAccountPayments method in the SQLStore, allowing
retrieval of stored payment hashes for SQLite and Postgres backends.
Also define the AccountPaymentEntry helper struct in
accounts/interface.go to wrap payment hashes and details.
Define the AccountPayments RPC endpoint and its request/response
messages in lit-accounts.proto. This endpoint allows querying
paginated payment history for a specific account.
Also update the frontend JS/TS proto sanitization script to map the
imported lnd.proto file to its flat directory path, fixing app build.
Utilize a sync.Pool for *big.Int instances in CryptoRandIntn to avoid
frequent heap allocations. This significantly reduces garbage collection
pressure when randomizing timestamps, amounts, and fees inside loops
(e.g. iterating over forwarding history responses).
Upgrade the randIntn function signature from int to int64 to prevent
unpredictable integer truncation on 32-bit systems (e.g., Raspberry Pi).
This ensures UnixNano timestamps in hideTimestamp and large amounts in
hideAmount do not cause unexpected runtime failures when calling
ForwardingHistory.
