GlcoinCore/lightning-terminal
1
0
Fork 0
mirror of https://github.com/lightninglabs/lightning-terminal.git synced 2026-08-13 12:33:36 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 2
lightning-terminal/docs/release-notes/release-notes-0.17.1.md
Viktor Torstensson a493b6a3d6
accounts: optionally cap account balances at the node channel balance 
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.
2026-08-07 12:26:29 +02:00

5.3 KiB
Raw Blame History

Release Notes

Lightning Terminal

Bug Fixes

  • Gate wallet-ready status on lnd's actual RPC readiness: Fixed a startup race where litd could report the LND sub-server as "Wallet Ready" before lnd's RPC interceptor had actually left its WAITING_TO_START state, so the very next call could still fail with rpc error: ... waiting to start.

  • Don't mask account payment errors when request values are absent: When a streaming account payment (SendPaymentV2/SendToRouteV2) fails and lnd returns a terminal error after the request values have already been cleaned up, lnd's underlying error is now passed through to the caller instead of being masked by a confusing no request values found for request: <id> error.

  • Wait longer for lnd during the kvdb-to-SQL migration: 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 poll budget and caused the migration (and therefore litd startup) to fail permanently, requiring a manual restart. The wait is now bounded by a configurable, generous timeout (--lndreadytimeout, defaulting to 10 minutes) instead of a fixed attempt count.

Functional Changes/Additions

  • Add accounts payments history subcommand: Added the litcli accounts payments subcommand and corresponding gRPC endpoint AccountPayments to retrieve the off-chain payment history of an account, supporting pagination (sorted in ascending lexicographical order of their payment hash) and counting of total payments.

  • Auto-bake super macaroon on startup: Added config options --bake-super-macaroon (choice: none, read-only, read-write) and --super-macaroon-path to automatically bake a super macaroon on startup and keep its permissions in sync. When set to read-only or read-write, the daemon will automatically bake a super macaroon containing read-only or read-write permissions, respectively, for all active sub-servers on startup. If the macaroon already exists but has different permissions, it will be automatically regenerated.

  • Add a configurable maximum account payment size: Addresses #583. Added an accounts.max-payment-size-msat config option. When set to a non-zero value, the account interceptor rejects any single account payment (SendPaymentV2/SendToRouteV2) whose total amount, including fees, exceeds the configured cap, providing a guard rail against a compromised or misbehaving account macaroon draining its balance in one large payment. It defaults to 0 (no cap), preserving existing behaviour. This is a first step towards the finer-grained per-account spending controls tracked in the issue (e.g. per-interval spend limits).

  • Optionally cap total account balances at the node's channel balance: Addresses #495. Added an opt-in accounts.check-channel-balance config option. When enabled, the accounts service rejects balance allocations (new accounts, administrative credits and administrative balance increases) that would push the sum of all account balances above the node's available local (outbound) channel balance, helping operators avoid over-provisioning custodial accounts beyond what the node can actually pay out. It defaults to off to preserve existing behaviour.

Technical and Architectural Updates

RPC Updates

Integrated Binary Updates

LND

Loop

Pool

Faraday

Taproot Assets

Contributors (Alphabetical Order)

  • 0xfandom
  • bitromortac
  • Cyberguru1
  • Vandit Singh