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.
1.4 KiB
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.