Update splice_in/splice_out to use new LDK two-phase funding API #794
Update splice_in/splice_out to use new LDK two-phase funding API #794jkczyz wants to merge 4 commits intolightningdevkit:mainfrom
splice_in/splice_out to use new LDK two-phase funding API #794Conversation
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>
|
👋 Hi! I see this is a draft PR. |
| Ok(txid) | ||
| } | ||
|
|
||
| pub(crate) fn select_confirmed_utxos( |
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
Yeah, that seems preferable, if we have everything we need in the API by now?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Huh, well the branch shows the fixup. Not sure why the PR hasn't updated.
There was a problem hiding this comment.
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.
| let txid = self.onchain_payment.send_to_address(&address, amt_sats, None)?; | ||
| return Ok(UnifiedPaymentResult::Onchain { txid }); | ||
| }, | ||
| PaymentMethod::Cashu(_) => todo!(), |
There was a problem hiding this comment.
Uh, let's not panic if someone includes Cashu instructions in the string above. Could just error and skip if this is hit.
| Ok(txid) | ||
| } | ||
|
|
||
| pub(crate) fn select_confirmed_utxos( |
There was a problem hiding this comment.
Yeah, that seems preferable, if we have everything we need in the API by now?
jkczyz
force-pushed
the
2026-02-splicing-api-change
branch
from
4c01c07 to
4891c0b
Compare
3 participants
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.