Repository navigation
Conversation
Update LDK Node's Cargo.toml to use recurrence-aware versions of rust-lightning and bitcoin-payment-instructions. This makes the recurrence APIs available for implementing recurrence support in subsequent commits. Co-authored-by: GLaDOS
|
👋 Hi! I see this is a draft PR. |
shaavan
force-pushed
the
node-recurrence
branch
2 times, most recently
from
October 5, 2026 10:33
ea3bf1e to
bd797ab
Compare
Recurring offers outlive individual payment attempts and node processes. To resume a recurrence safely after restart, the node must retain its original offer terms, lifecycle state, payment progress, and payee-provided opaque state. Add RecurrenceDetails and RecurrenceStatus with TLV serialization and RecurrenceId-based persistence. Load recurrence records during node construction under a dedicated "recurrences" namespace, retaining all entries for the lifetime of each recurrence. Thread RecurrenceStore through Node, EventHandler, and Bolt12Payment to establish the persistence foundation for recurrence scheduling and payment handling. Recurring payment execution remains disabled in this commit. Co-Authored-By: GLaDOS
shaavan
force-pushed
the
node-recurrence
branch
2 times, most recently
from
October 9, 2026 15:26
cf19305 to
09ff237
Compare
Add an API to start a recurring payment by submitting the initial invoice request. Persist the recurrence state so subsequent payments can continue the same recurring relationship. Co-Authored-By: GLaDOS
On successful completion of a payment that corresponds to a recurrence we introduce logic to update the details after validating the invoice parameters. Co-authored-by: GLaDOS
A terminal payment failure must release the recurrence's active attempt while retaining its payment ID. Otherwise, the recurrence continues to appear busy after the attempt has ended. Update only the unique recurrence whose active payment ID matches the failed payment. Replayed failures leave already-handled or newer attempts unchanged. Request event replay when persistence fails. Co-Authored-By: GLaDOS
Allow callers to submit subsequent payments using the stored recurring offer and payment parameters. Require an active recurrence, a successful initial payment, no active attempt and an open payment window. Validate the next period against the inclusive recurrence limit. After submission, persist the payment record and associate its ID with the recurrence for event handling. Return the payment ID on successful submission and an error on synchronous failure. Submission failures other than duplicate payment IDs are recorded as failed payments, while the recurrence attempt is marked active. Co-Authored-By: GLaDOS
Abandon active payments and persist the cancelled recurrence status. Queue a cancellation request for the payee after a successful payment. Co-Authored-By: GLaDOS
Failed initial payments cannot be retried through pay_next_recurrence, which requires the first payment to have succeeded. Add retry_recurrence for active recurrences with a failed attempt. Reuse payment submission without advancing the recurrence period. Require an open payment window unless the first payment has not yet established the basetime. Co-Authored-By: GLaDOS
Recurrences need to progress without callers polling payment windows or manually retrying failed attempts. Scan active recurrences every 30 seconds to retry failed payments, update missed/completed status, and submit future payments when automatic payment is enabled. Reserve attempts before submission and serialize cancellation to prevent concurrent manual and scheduled payments from paying the same period. Keep uncertain attempts active to avoid duplicate payments. Co-Authored-By: GLaDOS
shaavan
force-pushed
the
node-recurrence
branch
from
October 12, 2026 13:51
09ff237 to
d3f8ca8
Compare
Member
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
This PR adds recurring BOLT 12 payments to LDK Node, based on lightning/bolts#1240 and the recurrence support in rust-lightning #4882.
rust-lightning handles the protocol: recurrence fields in offers, invoice requests, and invoices; message validation; payment-window calculations; stable payer identity; and requests to pay or cancel a recurrence.
LDK Node manages the payer’s ongoing workflow. It persists recurrence state, links individual payments to a recurrence, updates that state as payments succeed or fail, resumes after a restart, schedules and retries payments, and provides APIs for applications to manage recurrences.
Scope
Development approach
I’ll develop the implementation incrementally in this PR. If it becomes too large to review effectively, I’ll split out independently reviewable components into separate PRs and link them here.