Add splice RBF support by jkczyz · Pull Request #888 · lightningdevkit/ldk-node

jkczyz · 2026-04-24T02:52:02Z

Adds a public Node::rbf_channel API that replaces an in-flight splice transaction with a higher-feerate version.

An RBF leaves multiple candidate splice transactions in flight; only one of them will confirm on chain, and the payment record needs to reflect whichever one did — its amount and this node's share of the fee. The transition from Pending to Succeeded should also match when the Lightning protocol actually considers the new channel state usable — the moment ChannelReady fires — rather than after ANTI_REORG_DELAY confirmations, which doesn't fit the zero-conf extreme on one end or higher-confirmation-depth peer configurations on the other.

To support those properties, this PR:

ties channel-funding and splice payment status to channel lifecycle instead of confirmation depth;
retains each candidate's contribution on the pending record until one of them confirms;
updates the record's amount and fee to match the confirmed candidate's contribution;
discards a funding payment when its channel closes without the funding ever confirming.

Every broadcast from LDK now triggers a store write. For a remote KV store, running that write on LDK's thread would block message handling for hundreds of milliseconds per call, so persistence happens asynchronously while still guaranteeing that the record is committed before the transaction reaches the chain client.

Based on #878.

ldk-reviews-bot · 2026-04-24T02:52:05Z

👋 Thanks for assigning @benthecarman 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.

jkczyz · 2026-04-24T02:53:37Z

@tnull Any feedback on the last few commits would be appreciated: https://github.com/lightningdevkit/ldk-node/pull/888/changes/492ec9124ae02a4048ecb5270309174b05b366d2..c770999887e1287bef8abe4f4c92ca36e9434067

tnull · 2026-04-29T08:43:42Z

Btw, we just landed #839 - maybe it would be nice to add splicing interop tests with CLN and/or Eclair (see #880 though), in this PR or in a follow-up?

tnull

Excuse the delay. Took a first look, generally makes sense, though it's kind off odd to block the broadcast queue on persistence. Hopefully we'd never get a lot of backpressure from remote persistence, for example.

I have yet to review the (rather verbose) new code for updating/persisting the pending payments in wallet.rs in more detail.

tnull · 2026-05-21T08:10:54Z

@jkczyz Is this ready for review or are we waiting for any upstream changes still?

jkczyz · 2026-05-21T14:39:23Z

@jkczyz Is this ready for review or are we waiting for any upstream changes still?

Yeah, upstream has landed but this is now based on the splicing portion of #882. We can take those here if you prefer.

tnull · 2026-05-21T14:54:14Z

@jkczyz Is this ready for review or are we waiting for any upstream changes still?

Yeah, upstream has landed but this is now based on the splicing portion of #882. We can take those here if you prefer.

Ah, was unaware of that cross dependency, will see to review #882 next to keep things moving then.

ldk-reviews-bot · 2026-05-23T14:40:53Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-25T14:40:57Z

🔔 2nd Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-05-27T14:41:41Z

🔔 3rd Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Camillarhi

Thanks for this. I took a look at this, and I have a few questions. I have taken a little look at splicing in general.
For this PR, if a user calls bump_fee_rbf on a record with funding_details, the replacement is picked up as a WalletEvent::TxReplaced event on the next sync, and this will currently rewrite the funding_details as NONE. Is bumping a funding/splice payment through bump_fee_rbf meant to be possible at all, or should those records be excluded here in favor of rbf_channel? AND is overwriting an existing funding_details with None intended in the TxReplaced path?

ldk-reviews-bot · 2026-05-30T00:01:35Z

🔔 4th Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-01T00:02:16Z

🔔 5th Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-03T00:02:47Z

🔔 6th Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

jkczyz · 2026-06-05T19:46:08Z

Rebased and dropped commits added in #912.

Ah, was unaware of that cross dependency, will see to review #882 next to keep things moving then.

Sorry, that should have said #872. Relevant commits were moved to #912, which has been merged.

Thanks for this. I took a look at this, and I have a few questions. I have taken a little look at splicing in general. For this PR, if a user calls bump_fee_rbf on a record with funding_details, the replacement is picked up as a WalletEvent::TxReplaced event on the next sync, and this will currently rewrite the funding_details as NONE. Is bumping a funding/splice payment through bump_fee_rbf meant to be possible at all, or should those records be excluded here in favor of rbf_channel? AND is overwriting an existing funding_details with None intended in the TxReplaced path?

Good catch @Camillarhi! Updated to disallow using bump_fee_rbf since that won't work for interactively constructed transactions. We need use the interactive-tx construction protocol given some signatures come from the counterparty.

Overwriting the existing funding_details is also unintended. Added a guard to prevent that.

ldk-reviews-bot · 2026-06-06T00:01:15Z

🔔 7th Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-08T00:02:06Z

🔔 8th Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-10T00:02:34Z

🔔 9th Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-10T14:50:49Z

🔔 1st Reminder

Hey @tnull @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

benthecarman

Needs rebase.

Would be nice if we had an api to see if a channel has a currently in-progress splice. Currently the only way to know is to call one of the splice functions and see if it fails.

benthecarman · 2026-06-12T21:44:31Z

-					"Failed to splice channel: a prior splice contribution is pending"
+					"Failed to splice channel: a prior splice contribution is pending; use rbf_channel instead"
 				);
 				return Err(Error::ChannelSplicingFailed);


It says use rbf_channel instead but that function doesn't let us change the amount in/out. Some like use rbf_channel to bump fee would be more accurate. Also would be nice if this had a separate error.

Fixed the message, but I'm not sure it justifies a new error type. Callers will be able to check SpliceDetails once lightningdevkit/rust-lightning#4687 is included. @tnull Any preference?

Should that be added to the 0.3 milestone?

Yeah, added.

Fixed the message, but I'm not sure it justifies a new error type. Callers will be able to check SpliceDetails once lightningdevkit/rust-lightning#4687 is included. @tnull Any preference?

No preference, fine to leave it as-is.

benthecarman · 2026-06-12T22:00:35Z

also needs rebase and I imagine this will have conflicts with #660

jkczyz · 2026-06-12T22:57:55Z

Would be nice if we had an api to see if a channel has a currently in-progress splice. Currently the only way to know is to call one of the splice functions and see if it fails.

Yeah, good point.

#930 adds a store for handling retries on disconnect. But I have an upstream change to expose this information on ChannelDetails. See lightningdevkit/rust-lightning#4687.

ldk-reviews-bot · 2026-06-13T00:01:00Z

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-15T00:02:31Z

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

When a splice is already pending, the user needs a way to replace its funding transaction at a higher feerate. This adds rbf_channel() to handle that case and guards splice_in/splice_out against being called while a pending splice exists, directing users to rbf_channel instead. Also fixes signing for RBF replacements, which requires accessing outputs spent by unconfirmed transactions. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude <noreply@anthropic.com>

jkczyz · 2026-06-15T16:53:26Z

Rebased. Still need to address the comments, but I will need to investigate some test flakiness first.

bump_channel_funding_fee only bumps a pending splice's fee; it cannot change the splice amount, so phrasing it as an alternative to splicing was misleading. Co-Authored-By: Claude <noreply@anthropic.com>

Channel-opening and splice transactions transition to Succeeded when ChannelReady fires, not after ANTI_REORG_DELAY confirmations. This matches the point at which the Lightning layer considers the channel usable: a zero-conf channel graduates as soon as its counterparty signals, and a high-conf channel waits however many confirmations the peer requires, rather than always stopping at six. For splice RBF, the payment records whichever candidate actually confirmed, with that candidate's amount and this node's share of the fee — not the fee-estimate used for weight at coin-selection time, and not the whole-tx fee for a multi-contributor splice. A channel closure whose funding or splice never confirmed discards its payment record instead of leaving it pending forever. Generated with assistance from Claude Code. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The TxReplaced wallet event rebuilt the payment record from scratch, dropping its funding details. When a wallet sync fell between a splice broadcast and its RBF, the replacement of the original candidate cleared those details, so the payment no longer graduated to Succeeded on ChannelReady. Funding records are managed by the classify path and the Lightning lifecycle handlers, so leave them untouched on replacement. Co-Authored-By: Claude <noreply@anthropic.com>

bump_fee_rbf accepted channel-funding and splice payments because they are recorded as outbound, unconfirmed on-chain payments. Replacing such a transaction via wallet RBF would broadcast one LDK isn't tracking, and for splices the shared input can't be wallet-signed. Reject these and leave splice fee-bumping to rbf_channel. Co-Authored-By: Claude <noreply@anthropic.com>

Co-Authored-By: Claude <noreply@anthropic.com>

Once ChannelReady graduates a funding payment to Succeeded (removing its pending record), a concurrent wallet-sync event for one of its candidates could re-stamp the old Pending status and revert the graduation. Treat a Succeeded on-chain payment as terminal during sync, refining only the confirmation status of the candidate that locked. Co-Authored-By: Claude <noreply@anthropic.com>

Previously the BroadcasterInterface implementation wrote the payment record synchronously when LDK invoked it. With a remote KV store this could block LDK's message handling for hundreds of milliseconds per call, noticeably during force-close bursts or splice broadcasts. Persistence now happens asynchronously and must complete before the transaction is sent to the chain client. If persistence fails, the broadcast is dropped: a payment record must exist for every on-chain tx we emit, otherwise a crash could leave the tx confirmed with no matching record. Generated with assistance from Claude Code. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

ldk-reviews-bot · 2026-06-17T00:03:19Z

🔔 4th Reminder

Hey @tnull @benthecarman! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-06-17T19:47:51Z

🔔 1st Reminder

Hey @tnull @benthecarman! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2026-06-19T07:36:33Z

+	/// # Experimental API
+	///
+	/// This API is experimental and may change in the future.
+	pub fn bump_channel_funding_fee(


Is the plan for ldk-node to eventually monitor pending splice candidates and automatically bump them? It seems a bit awkward to make users/applications notice that a pending splice is stuck and manually call this API.

Wonder how this method can be used to bump the fee much higher and not only to the next step. Invoke repeatedly while they monitor what the current pending splice fee rate is?

Is the plan for ldk-node to eventually monitor pending splice candidates and automatically bump them? It seems a bit awkward to make users/applications notice that a pending splice is stuck and manually call this API.

Hmm, maybe. We previously considered that for regular onchain payments but for now opted to keep it manual. But indeed some auto-bumping could make sense, though we'd of course need to work out a sane API so the user can clearly limit how much they are willing to spend on fees..

Manual is a good first step of course, even though not being able to provide a fee rate to this call might feel uncontrolled.

Eventually I don't think you can ask an end-user to make any kind of decision about how and when to RBF.

tnull

Thanks, and excuse the considerable delay here!

Generally looks good, but I'm a bit confused about the second commit - so far we use the anti reorg delay just to avoid necessarily having to implement full reorg protection logic for the payment store. It seems mixing concepts here is a bit odd - is there a way to avoid tieing the onchain 'payment's status to anything channel specific?

Also recently put up some long planned refactors over at #937, in particular there we also tried getting rid of duplicating the full payment details in the pending payment store and rather keep the payment store the authoritative store. Any thoughts on whether this would be compatible with the changes in this PR?

Feel free to squash fixups, btw.

tnull · 2026-06-19T12:42:19Z

+	///
+	/// # Experimental API
+	///
+	/// This API is experimental and may change in the future.


Given we don't offer API stability in general, what does concretely mean beyond the API signature possibly changing going forward? If that's all that's already expected at this point, so maybe we can drop this note?

tnull · 2026-06-19T12:50:18Z

 		let mut psbt = Psbt::from_unsigned_tx(unsigned_tx).map_err(|e| {
 			log_error!(self.logger, "Failed to construct PSBT: {}", e);
 		})?;
+		// Use list_output rather than get_utxo to include outputs spent by unconfirmed


This comment won't make sense after this is merged as it only annotates the transition from list_output to get_utxo. Would be better to explain what's happening and why we're using list_output in particular, not only that we do.

tnull · 2026-06-19T12:58:22Z

 	pub conflicting_txids: Vec<Txid>,
+	/// Set when the payment's transaction is an interactive-funding broadcast (channel
+	/// open or splice). The record transitions to [`PaymentStatus::Succeeded`] on
+	/// `ChannelReady` instead of after [`ANTI_REORG_DELAY`] confirmations.


Hmm, could you expand on why this is necessary? It seems a rather unintuitive change given we only require ANTI_REORG_DELAY so our payment store doesn't necessarily need full reorg logic. Not quite sure I'm following why the status of the 'payment' / transaction should be tied to anything to do with channels?

tnull · 2026-06-19T13:06:45Z

+	) -> Result<BroadcastPackage, Error> {
+		let wallet_opt = self.wallet.lock().expect("lock").as_ref().and_then(Weak::upgrade);
+		if let Some(wallet) = wallet_opt {
+			tokio::task::spawn_blocking(move || {


Now that we made everything async internally, we should be able to make this a spawn, no?

tnull · 2026-06-19T13:23:48Z

+		if let Some(channel_details) =
+			open_channels.iter().find(|c| c.user_channel_id == user_channel_id.0)
+		{
+			let min_feerate =


Codex:

Medium: /home/tnull/workspace/ldk-node-pr-888/src/lib.rs:1826 computes the current ChannelFunding fee estimate, but /home/tnull/workspace/ldk-node-pr-888/
src/lib.rs:1845 to rbf_prior_contribution. In LDK that means “use the minimum RBF feerate”, so this API ignores the current fee estimate when fees rise. It
can also fail if the current estimate fell enough that max_feerate = estimate * 1.5 is below the required RBF minimum. This should choose an explicit
target like max(current_estimate, min_rbf_feerate) and set the max from that target.

tnull · 2026-06-19T13:24:55Z

+			pending.details.fee_paid_msat = aggregate.fee_paid_msat;
+		}
+
+		// Preserve the confirmation status already on the record (set by wallet sync if


Codex:

Medium: /home/tnull/workspace/ldk-node-pr-888/src/wallet/mod.rs:1373 can graduate a funding payment to Succeeded while preserving an Unconfirmed on-chain
status, then removes the pending funding record at /home/tnull/workspace/ldk-node-pr-888/src/wallet/mod.rs:1382. After that, /home/tnull/workspace/ldk-
node-pr-888/src/wallet/mod.rs:1557 no longer recognizes it as a funding payment because it only checks pending_payment_store, and it only rejects
ConfirmationStatus::Confirmed. A user can hit a race where ChannelReady has fired but BDK has not yet updated the confirmation status, allowing plain
wallet RBF against a channel funding tx LDK already considers locked. Reject PaymentStatus::Succeeded here, or persist enough funding classification in the
main payment store to keep rejecting these after graduation.

ldk-reviews-bot · 2026-06-20T00:00:42Z

🔔 2nd Reminder

Hey @benthecarman! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

jkczyz force-pushed the 2026-04-splicing-payment-using-tx-type branch 2 times, most recently from 198bfbf to d5b6bda Compare April 28, 2026 16:14

jkczyz force-pushed the 2026-04-splicing-payment-using-tx-type branch from d5b6bda to 91166b9 Compare April 29, 2026 22:28

jkczyz mentioned this pull request Apr 29, 2026

Include interactive funding candidates on broadcast lightningdevkit/rust-lightning#4570

Merged

jkczyz self-assigned this Apr 30, 2026

jkczyz added this to Weekly Goals Apr 30, 2026

tnull reviewed May 5, 2026

View reviewed changes

Comment thread src/lib.rs Outdated

ca-ruz mentioned this pull request May 16, 2026

Topic Suggestions for Socratic Seminar #21 guadalajara-bitdevs/BitDevsGDL.github.io#66

Closed

jkczyz mentioned this pull request May 18, 2026

Safely migrate to FileSystemStoreV2 #872

Merged

jkczyz force-pushed the 2026-04-splicing-payment-using-tx-type branch from 91166b9 to c4d3282 Compare May 20, 2026 21:00

jkczyz marked this pull request as ready for review May 21, 2026 14:39

ldk-reviews-bot requested a review from tankyleo May 21, 2026 14:40

Camillarhi reviewed May 28, 2026

View reviewed changes

Comment thread src/wallet/mod.rs Outdated

jkczyz force-pushed the 2026-04-splicing-payment-using-tx-type branch from c4d3282 to bec7723 Compare June 5, 2026 19:46

jkczyz requested a review from tnull June 8, 2026 14:49

jkczyz mentioned this pull request Jun 11, 2026

Retry user-initiated splices across restarts and disconnects #930

Draft

tnull added this to the 0.8 milestone Jun 12, 2026

benthecarman reviewed Jun 12, 2026

View reviewed changes

tankyleo removed their request for review June 12, 2026 22:30

jkczyz and others added 2 commits June 15, 2026 10:41

f - Rename rbf_channel to bump_channel_funding_fee

9e6114b

Co-Authored-By: Claude <noreply@anthropic.com>

jkczyz force-pushed the 2026-04-splicing-payment-using-tx-type branch from bec7723 to f78025d Compare June 15, 2026 16:51

jkczyz and others added 7 commits June 15, 2026 14:40

f - Clarify the bump_channel_funding_fee hint for a pending splice

f1a0a79

bump_channel_funding_fee only bumps a pending splice's fee; it cannot change the splice amount, so phrasing it as an alternative to splicing was misleading. Co-Authored-By: Claude <noreply@anthropic.com>

f - Rename persist_pending to persist_pending_payment

88be9ce

Co-Authored-By: Claude <noreply@anthropic.com>

jkczyz force-pushed the 2026-04-splicing-payment-using-tx-type branch from f78025d to 328bdc3 Compare June 15, 2026 19:45

jkczyz requested a review from benthecarman June 15, 2026 19:47

joostjager reviewed Jun 19, 2026

View reviewed changes

tnull reviewed Jun 19, 2026

View reviewed changes

Conversation

jkczyz commented Apr 24, 2026

Uh oh!

ldk-reviews-bot commented Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jkczyz commented Apr 24, 2026

Uh oh!

tnull commented Apr 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tnull commented May 21, 2026

Uh oh!

jkczyz commented May 21, 2026

Uh oh!

tnull commented May 21, 2026

Uh oh!

ldk-reviews-bot commented May 23, 2026

Uh oh!

ldk-reviews-bot commented May 25, 2026

Uh oh!

ldk-reviews-bot commented May 27, 2026

Uh oh!

Camillarhi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ldk-reviews-bot commented May 30, 2026

Uh oh!

ldk-reviews-bot commented Jun 1, 2026

Uh oh!

ldk-reviews-bot commented Jun 3, 2026

Uh oh!

jkczyz commented Jun 5, 2026

Uh oh!

ldk-reviews-bot commented Jun 6, 2026

Uh oh!

ldk-reviews-bot commented Jun 8, 2026

Uh oh!

ldk-reviews-bot commented Jun 10, 2026

Uh oh!

ldk-reviews-bot commented Jun 10, 2026

Uh oh!

benthecarman left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

benthecarman commented Jun 12, 2026

Uh oh!

jkczyz commented Jun 12, 2026

Uh oh!

ldk-reviews-bot commented Jun 13, 2026

Uh oh!

ldk-reviews-bot commented Jun 15, 2026

Uh oh!

jkczyz commented Jun 15, 2026

Uh oh!

ldk-reviews-bot commented Jun 17, 2026

Uh oh!

ldk-reviews-bot commented Jun 17, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joostjager Jun 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

ldk-reviews-bot commented Apr 24, 2026 •

edited

Loading

tnull commented Apr 29, 2026 •

edited

Loading

joostjager Jun 19, 2026 •

edited

Loading

tnull left a comment •

edited

Loading