Repository navigation
Conversation
The splice intent was added to pending-payment entries as groundwork for tracking a user-initiated splice from its submission (lightningdevkit#1079); the splice entry points that were to write it were part of lightningdevkit#1080 and were dropped from it before it merged. As a result, LDK Node never writes the intent. Its one reader, the id resolution at signing time, never finds one, so the field, the types describing it, the merge rule that kept it from being overwritten, and the tests exercising them are dead. Remove them. The first signed round of a splice gets a fresh id, as it already did whenever the intent was absent. TLV type 10 of the entry is left unused; it never reached a release. The tests that set up an intent to assert it was adopted or left alone are dropped or reduced to what they still show: a replayed signing writes nothing, a counterparty's broadcast joins the record under the id the signing chose rather than the transaction's own, and a fee bump joins the record of the round it replaces. Written with the help of an AI tool. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
👋 Thanks for assigning @tnull as a reviewer! |
This was referenced Nov 11, 2026
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.
Follow-up to #1079 and #1080.
#1079 added a splice intent to pending-payment entries as groundwork: the splice entry points in #1080 were to persist it before handing a contribution to LDK, so a splice LDK never durably learned of could be recognized after a restart. Those entry points were dropped from #1080 before it merged (recovery of a lost splice is to come with the input locks of #1037), so on
mainLDK Node never writes the intent. Its one reader,find_splice_payment_id, never finds one, and the field,SpliceIntent,SpliceKind, the merge rule that protected the intent, and their tests are dead.This removes them. The first signed round of a splice gets a fresh id, as it already did whenever the intent was absent. TLV type 10 of
PendingPaymentDetailsis left unused; it never reached a release.The tests that set up an intent to assert it was adopted or left alone are dropped or reduced to what they still show: a replayed signing writes nothing, a counterparty's broadcast joins the record under the id the signing chose rather than the transaction's own, and a fee bump joins the record of the round it replaces.
Written with the help of an AI tool.
🤖 Generated with Claude Code