Update LDK dependency for splicing, http, and wallet_utils by jkczyz · Pull Request #794 · lightningdevkit/ldk-node

jkczyz · 2026-02-18T05:12:39Z

The LDK dependency bump introduced a new splicing API that separates negotiation from coin selection (lightningdevkit/rust-lightning#4290), letting LDK handle transaction construction internally rather than requiring manual UTXO selection and change address management.

Also handles changes to lightning-block-sync moving to bitreq (lightningdevkit/rust-lightning#4350), making a test macro a function (lightningdevkit/rust-lightning#4425), and moving some coin selection utils to wallet_utils (lightningdevkit/rust-lightning#4382).

ldk-reviews-bot · 2026-02-18T05:12:42Z

👋 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.

jkczyz · 2026-02-18T05:14:11Z

src/wallet/mod.rs

 		Ok(txid)
 	}

-	pub(crate) fn select_confirmed_utxos(


@tnull I'm wondering if we should implement CoinSelectionSource and use this rather than using LdkWallet for UTXO selection. It would prevent double persistence when we need a change output and the need for an explicit persist method after selection.

Yeah, that seems preferable, if we have everything we need in the API by now?

Right, I think the question may be whether we use our own CoinSelectionSource for anchor bumping, too. It depends on how UTXO locking will work. LdkWallet manages whether or not to try to double-spend based on the claim id, whereas for splicing we may accidentally double spend one of those if using our own CoinSelectionSource. Pushed a fixup commit implementing CoinSelectionSource for splicing.

Huh, well the branch shows the fixup. Not sure why the PR hasn't updated.

Right, I think the question may be whether we use our own CoinSelectionSource for anchor bumping, too.

It would be great to reuse the same codepaths, IMO. That is, if the API now permits for it.

It depends on how UTXO locking will work. LdkWallet manages whether or not to try to double-spend based on the claim id, whereas for splicing we may accidentally double spend one of those if using our own CoinSelectionSource.

Right, we're still waiting on bitcoindevkit/bdk_wallet#259 to ship with BDK 3.0. For now I'm not sure if we'd then need to also do some tracking based on ClaimId.

Discussed offline. We'll use the current approach and then once BDK ships a new release we can revisit coin selection for anchor bumping.

Alternatives would be to either (1) drop the fixup such that we use LdkWallet for both coin selections or (2) maintain a locked UTXO list for splice coin selection and filter WalletSource::list_confirmed_utxos so that anchor bumping doesn't double spend splicing.

src/payment/unified.rs

tnull · 2026-02-18T13:26:41Z

src/wallet/mod.rs

 		Ok(txid)
 	}

-	pub(crate) fn select_confirmed_utxos(


Yeah, that seems preferable, if we have everything we need in the API by now?

src/wallet/mod.rs

tnull

Seems this should be based on lightningdevkit/rust-lightning#4382 as it now has landed, as is the next related breaking change?

tnull

Changes LGTM, but as mentioned above it would be good to add a second commit to bump once more and include latest wallet-related API fixes, so that after this PR we can build against current LDK main again.

tnull · 2026-02-20T14:43:56Z

src/wallet/mod.rs

 	fn sign_psbt<'a>(
 		&'a self, psbt: Psbt,
 	) -> impl Future<Output = Result<Transaction, ()>> + Send + 'a {
+		debug_assert!(false);


Why is this unreachable?

It's only used for anchor bumping. For splicing, we provide signatures when handling FundingTransactionReadyForSigning and calling ChannelManager::funding_transaction_signed.

jkczyz · 2026-02-20T15:40:55Z

Seems this should be based on lightningdevkit/rust-lightning#4382 as it now has landed, as is the next related breaking change?

Yeah, unfortunately lightningdevkit/rust-lightning#4350 landed between the two PRs. Working on updating now.

jkczyz · 2026-02-20T16:41:50Z

Ok, I changed the branch I used for updating bitcoin-payment-instructions to be based on your branch. As a result the Cashu changes are no longer needed. Also, I made three separate changes to handle updates for lightningdevkit/rust-lightning#4290, lightningdevkit/rust-lightning#4350, and lightningdevkit/rust-lightning#4382. I didn't write the middle PR, so please take a close look at what Claude did to upgrade.

jkczyz · 2026-02-20T16:44:59Z

May need to rebase to fix CI. Looking...

jkczyz · 2026-02-20T16:49:30Z

May need to rebase to fix CI. Looking...

Ah, actually looks like we still need to update for lightningdevkit/rust-lightning#4425. Will update shortly.

tnull

Mostly looks good, two questions.

tnull · 2026-02-23T14:32:09Z

src/wallet/mod.rs

+			.filter(|txout| must_pay_to.iter().all(|output| output != txout))
+			.next();
+
+		locked_wallet.persist(&mut locked_persister).map_err(|e| {


Remind me, why is this persist call necessary now? I'm not positive any of the wallet state should change here?

We probably only need to do so if change_output is Some actually. Previously, we persisted in splice_in when calling get_new_internal_address to give to LDK a change script.

tnull · 2026-02-23T14:42:16Z

src/chain/bitcoind.rs

 impl TryInto<FeeResponse> for JsonResponse {
-	type Error = std::io::Error;
-	fn try_into(self) -> std::io::Result<FeeResponse> {
+	type Error = String;


Hmm, I think we previously used std::io::Result in these internal APIs as it was used by lightning-block-sync to begin with. If we now don't use it in lightning-block-sync and have rpc_client_error_to_io and http_client_error_to_io, I do wonder if we should rather introduce a dedicated local error type that then implements std::error::Error and we can add From<{HttpClientError,RpcClientError}> for NewLocalRpcError for?

Yeah, good idea. Though just made the conversions explicit with map_err.

Update splice_in/splice_out to use new LDK two-phase funding API The LDK dependency bump introduced a new splicing API that separates negotiation from coin selection, letting LDK handle transaction construction internally rather than requiring manual UTXO selection and change address management. Generated with the assistance of AI (Claude Code). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

The latest LDK dependency bump replaced the custom HTTP implementation in lightning-block-sync with the `bitreq` crate, changing constructor signatures, error types, and response parsing constraints. Update the bitcoind chain source to use the new string-based URL constructors and structured error enums. Use a dedicated BitcoindClientError type since std::io::Error was only used previously because that was used upstream. Generated with the assistance of AI (Claude Code). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

The macro was removed in favor of a function.

Some types previously existing in lightning::events::bump_transaction have been moved to lightning::util::wallet_utils.

benthecarman · 2026-02-23T23:27:30Z

Cargo.toml

 #lightning-liquidity = { version = "0.2.0", features = ["std"] }
 #lightning-macros = { version = "0.2.0" }

-lightning = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "b6c17c593a5d7bacb18fe3b9f69074a0596ae8f0", features = ["std"] }


can we do commit 2d2151a4e40734b871289e8bb0fa13466c0ea60a to include the paginated kv store stuff? Will need this for #772

Whoops... Looks like I need to account for some test changes. Will do so in little bit.

Hmm, but we also need to add the PaginatedKVStore impls for SqliteStore and VssStore. @benthecarman Do you plan to do that in commits in #772? IMO that's a bit odd as the PR is somewhat orthogonal? Or would you prefer me to do it in a separate PR?

jkczyz commented Feb 18, 2026

View reviewed changes

tnull reviewed Feb 18, 2026

View reviewed changes

jkczyz force-pushed the 2026-02-splicing-api-change branch from 4c01c07 to 4891c0b Compare February 18, 2026 18:04

jkczyz mentioned this pull request Feb 19, 2026

Split splice initiation into two phases lightningdevkit/rust-lightning#4290

Merged

jkczyz added this to Weekly Goals Feb 19, 2026

jkczyz self-assigned this Feb 19, 2026

jkczyz force-pushed the 2026-02-splicing-api-change branch 2 times, most recently from 7ccaa2a to 01102e6 Compare February 20, 2026 06:03

jkczyz marked this pull request as ready for review February 20, 2026 06:03

jkczyz requested a review from tnull February 20, 2026 06:13

tnull reviewed Feb 20, 2026

View reviewed changes

jkczyz mentioned this pull request Feb 20, 2026

lightning-block-sync: switch to bitreq, drop chunked_transfer lightningdevkit/rust-lightning#4350

Merged

jkczyz force-pushed the 2026-02-splicing-api-change branch from 01102e6 to f78aa6c Compare February 20, 2026 16:33

jkczyz changed the title ~~Update splice_in/splice_out to use new LDK two-phase funding API~~ Update LDK dependency for splicing, http, and wallet_utils Feb 20, 2026

jkczyz force-pushed the 2026-02-splicing-api-change branch from f78aa6c to ad6c554 Compare February 20, 2026 17:14

jkczyz requested a review from tnull February 20, 2026 17:22

tnull reviewed Feb 23, 2026

View reviewed changes

jkczyz force-pushed the 2026-02-splicing-api-change branch from ad6c554 to 9617ea5 Compare February 23, 2026 16:17

jkczyz and others added 4 commits February 23, 2026 10:20

Bump LDK dependency for check_closed_broadcast

0fe225a

The macro was removed in favor of a function.

Bump LDK dependency for wallet_utils refactor

3d1bb98

Some types previously existing in lightning::events::bump_transaction have been moved to lightning::util::wallet_utils.

jkczyz force-pushed the 2026-02-splicing-api-change branch from 9617ea5 to 3d1bb98 Compare February 23, 2026 16:20

jkczyz requested a review from tnull February 23, 2026 23:19

benthecarman reviewed Feb 23, 2026

View reviewed changes

Bump LDK dependency for v1::FilesystemStore

759a4d4

jkczyz force-pushed the 2026-02-splicing-api-change branch from e95e7a9 to 759a4d4 Compare February 24, 2026 00:41

Comments

Conversation

jkczyz commented Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

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

Uh oh!

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!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tnull left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull 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!

jkczyz commented Feb 20, 2026

Uh oh!

jkczyz commented Feb 20, 2026

Uh oh!

jkczyz commented Feb 20, 2026

Uh oh!

jkczyz commented Feb 20, 2026

Uh oh!

tnull 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!

Choose a reason for hiding this comment

Uh oh!

jkczyz Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jkczyz commented Feb 18, 2026 •

edited

Loading

ldk-reviews-bot commented Feb 18, 2026 •

edited

Loading

tnull left a comment •

edited

Loading

jkczyz Feb 23, 2026 •

edited

Loading

tnull Feb 24, 2026 •

edited

Loading