mirror of
https://github.com/lightninglabs/lightning-terminal.git
synced 2026-08-20 13:28:34 +02:00
f8a36010e2
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.
23 lines
1.4 KiB
Markdown
23 lines
1.4 KiB
Markdown
# On-chain budget rule
|
|
|
|
The on-chain budget rule enforces constraints on the funds that can be spent
|
|
through on-chain related RPC calls, for example those that deal with channel
|
|
opening. The rule maintains a per-session budget that is spent down by
|
|
successive API calls. An incoming request's amount (say for `BatchOpenChannel`)
|
|
is checked against the already total spent and pending budget and persisted as a
|
|
pending balance entry if enough balance is available. The request is then
|
|
transmitted to LND. In case of errors or responses from LND, pending amounts are
|
|
either deleted or moved to the spent budget accordingly.
|
|
|
|
Pending amounts are persisted to handle requests with unclear outcomes and to
|
|
ensure safety from intermediate restarts or crashes. However, this approach has
|
|
a downside as there is currently no mechanism to remove pending balances after a
|
|
restart, leading to stronger constraints on the budget than needed, as the
|
|
pending balance is counted towards the total spent budget.
|
|
|
|
To identify unprocessed pending actions later, a unique identifier is added to
|
|
the request that corresponds to the pending balance's storage key. For the
|
|
channel opening RPC specifically, it's `Memo` field is prefixed with a unique
|
|
request identifier, which is exposed in `ListChannels` and `PendingChannels`.
|
|
This identifier could be used in the future to clean up any unprocessed pending
|
|
actions provided the `ClosedChannels` API gets support for the `Memo` field.
|