Repository navigation
Allow specifying a fee rate when splicing - #1159
Conversation
|
👋 Thanks for assigning @tnull as a reviewer! |
| pub fn splice_in( | ||
| &self, user_channel_id: &UserChannelId, counterparty_node_id: PublicKey, | ||
| splice_amount_sats: u64, | ||
| splice_amount_sats: u64, fee_rate: Option<FfiFeeRate>, |
There was a problem hiding this comment.
We should probably name this min_fee_rate in the API to make it clear it's just the lower bound.
There was a problem hiding this comment.
Makes sense, will rename it to min_fee_rate and rebase once #1099 lands.
|
This needs a rebase now that #1099 landed. |
5d51bed to
b3f4a7f
Compare
Rebased and renamed the parameter to |
jkczyz
left a comment
jkczyz
left a comment
There was a problem hiding this comment.
Should we do the same for bump_channel_funding_fee? Otherwise, looks good.
| /// pending splice that requires a higher feerate to be replaced, or when the counterparty | ||
| /// initiates a splice concurrently and our contribution is added to theirs. | ||
| /// | ||
| /// The amount spliced in is determined at the feerate used for our contribution. |
There was a problem hiding this comment.
🤖 The amount is actually determined at min_fee_rate (or the estimate), not at the feerate the contribution ends up using: it's computed before the funding template is obtained, and the contribution may then be built at a pending splice's RBF minimum. Suggest "determined at min_fee_rate, or at the estimate if unset". The underlying mismatch is covered by #1168, which replaces the amount computation with manually selected inputs.
b3f4a7f to
27b9584
Compare
Added |
27b9584 to
e96d14e
Compare
tnull
left a comment
tnull
left a comment
There was a problem hiding this comment.
This needs another rebase now I'm afraid.
`Node::splice_in`, `Node::splice_in_with_all`, and `Node::splice_out` always contributed at our `ChannelFunding` feerate estimate, leaving no way to choose the feerate of a splice, unlike for on-chain sends. Add an optional `min_fee_rate` to all three. If set, it takes the place of the estimate as the minimum feerate of our contribution: the existing logic deriving the maximum feerate and meeting a pending splice's RBF minimum applies to it unchanged, and `splice_in_with_all` determines the amount to splice in at it. If unset, behavior is unchanged. Developed with assistance from Claude Code.
`Node::bump_channel_funding_fee` always started from our `ChannelFunding` feerate estimate, so the replacement couldn't be bumped to a chosen feerate, unlike the splice itself. Add the same optional `min_fee_rate`. If set, it takes the place of the estimate as the minimum feerate of the replacement: we still pay the pending splice's RBF minimum if that is higher, up to 1.5 times the minimum, and fail if replacing it requires more. If unset, behavior is unchanged. Developed with assistance from Claude Code.
Splice out, splice in and fee-bump the pending splice-in, and then splice in all funds, at feerates well above the one we estimate on regtest, and check that each splice transaction pays the requested feerate. Replacing the pending splice requires more than we would pay at our estimate, so the bump only succeeds at the requested feerate. As the amount to splice in is determined at the requested feerate, the final splice-in would otherwise fail to fund its fee. Developed with assistance from Claude Code.
e96d14e to
11cb500
Compare
4 participants
Node::splice_in,Node::splice_in_with_all, andNode::splice_outalways fund our contribution at theChannelFundingfeerate estimate. On-chain sends already accept an optional fee rate (#434), and #1099 proposes the same for channel opens. This extends that to splices, so applications and node operators can choose how quickly a splice confirms.We're adding channel splicing to ZEUS's embedded LDK Node (ZeusLN/zeus#4703) and want users to be able to select the fee rate when splicing, as they already can for on-chain sends.
Changes
splice_in,splice_in_with_all, andsplice_outtake an optionalfee_rate(FeeRate?in the bindings) as their last argument.splice_in_with_all, the amount spliced in, which is determined at the requested feerate. The docs note when we may pay up to 1.5x the requested feerate.payment/onchain.rsinto a function inffi/mod.rs, soOnchainPaymentandNodeshare it. Allow specifying a fee rate for channel-open funding transactions #1099 makes the same move; whichever lands second can drop its copy.Testing
splice_channel_with_fee_rateintegration test: splices out, then splices in all funds, at ten times the regtest feerate estimate, and checks each splice transaction pays the requested feerate (within 1% to allow for weight estimation). The splice-in would fail to fund its fee if the amount were determined at the estimate instead.onchain_wallet_full_scan_stop_gap_recovers_far_esplora_and_electrum_fundsfailure also occurs onmainand is unrelated to this change.This change was developed with the assistance of Claude Code.