Skip to content

Fix funding-payment reclassification downgrade and deep-reorg duplication#962

Open
jkczyz wants to merge 2 commits into
lightningdevkit:mainfrom
jkczyz:2026-07-funding-payment-lifecycle-fixes
Open

Fix funding-payment reclassification downgrade and deep-reorg duplication#962
jkczyz wants to merge 2 commits into
lightningdevkit:mainfrom
jkczyz:2026-07-funding-payment-lifecycle-fixes

Conversation

@jkczyz

@jkczyz jkczyz commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Two independent fixes Codex raised in the review of #888:

  • Preserve funding-payment confirmation state on late reclassification — a broadcaster-queue classification that runs after wallet sync no longer downgrades an already-advanced (confirmed/graduated) funding payment.
  • Revert reorged funding payments instead of duplicating them — a deep reorg of a graduated RBF splice now reverts the payment in place instead of recording a duplicate generic on-chain payment.

jkczyz and others added 2 commits July 1, 2026 21:47
Funding broadcasts are classified into payment records off the
broadcaster's queue, which can run after wallet sync has already recorded
the transaction -- for instance when LDK re-broadcasts a still-pending
funding transaction on restart. In that case the classification overwrote
a record wallet sync had already advanced, downgrading a confirmed or
graduated funding payment back to unconfirmed/pending.

Merge only the classification and our contribution figures into an
existing record, leaving the confirmation state that the wallet-sync
events own in place.

Raised by Codex in the review of lightningdevkit#888.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A funding payment's id is anchored to its first negotiated candidate, but
once it confirms the record is stamped with the candidate that actually
confirmed. After it graduates and its pending-store entry is removed, a
later reorg event carrying the confirmed candidate's txid could no longer
be resolved to the payment, so it was recorded as a duplicate generic
on-chain payment rather than reverting the splice payment. RBF splices,
whose confirmed candidate differs from the first, are the reachable case.

Resolve such an event against the payment store by on-chain txid once the
pending store no longer holds it, and revert the funding payment to
pending so wallet sync re-graduates it when it reconfirms.

Raised by Codex in the review of lightningdevkit#888.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@ldk-reviews-bot

ldk-reviews-bot commented Jul 2, 2026

Copy link
Copy Markdown

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

2 participants