Repository navigation
Count the funding fee in the anchor reserve check for splice-ins - #1223
Open
shubhamkmr04 wants to merge 3 commits into
Open
shubhamkmr04 wants to merge 3 commits into
shubhamkmr04 wants to merge 3 commits into
Conversation
Opening a channel with an exact amount only checked that our on-chain funds cover the amount plus the anchor reserve, leaving out the fee of the funding transaction, which is paid from the same funds. Since the fee rate can now be chosen freely (lightningdevkit#1099), a high one could spend part of the reserve, or leave too little to build the funding transaction once the counterparty had accepted the channel. Also check that the amount doesn't exceed what opening the channel with all funds would add at the same fee rate, which already accounts for the fee and the reserve, and fail with `InsufficientFunds` otherwise. We do so in `check_sufficient_onchain_funds`, which now takes the fee rate of the funding transaction. Part of lightningdevkit#1166. Developed with assistance from Claude Code.
When acting as an LSPS2 service, we open a JIT channel once its payment arrives, after checking that our on-chain funds cover the channel amount plus the anchor reserve. As for exact-amount opens, this left out the fee of the funding transaction, which is built later at our fee estimate and paid from the same funds, so it could spend part of the reserve. Also check that the channel amount doesn't exceed what funding with all our funds would add at that estimate, and don't open the channel otherwise. To do so, the LSPS2 service now has access to the fee estimator. Part of lightningdevkit#1166. Developed with assistance from Claude Code.
Splicing in an exact amount only checked that our on-chain funds cover the amount on top of the anchor reserve. The fee for our contribution to the splice transaction is paid from the same funds, though, and coin selection doesn't keep the reserve aside, so the fee could be taken from it. Once the contribution is built, also check that what it takes from our wallet, its inputs minus its change, fits in the funds beyond the reserve, and fail with `InsufficientFunds` otherwise. The check of the amount alone stays in front, so that a plain lack of funds still fails before coin selection. Part of lightningdevkit#1166. Developed with assistance from Claude Code.
|
I've assigned @tnull as a reviewer! |
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.
Part of #1166. Builds on #1204, so only the last commit is new here.
When splicing in an exact amount, we checked that our on-chain funds cover the amount on top of the anchor reserve, but not the fee for our contribution to the splice transaction, which is paid from the same funds. Coin selection doesn't keep the reserve aside, so the fee could come out of it.
Changes
splice_in: once LDK has built the contribution, we now pass what it takes from our wallet, its inputs minus its change, tocheck_sufficient_onchain_funds, and fail withInsufficientFundsif that exceeds the spendable balance. LDK runs coin selection with the shared input and output, so the change is net of the whole fee, and inputs minus change is exactly the amount plus our fee. Checking the built contribution also avoids estimating the fee up front, which Buildsplice_in_with_allfrom manually selected inputs #1176 moved away from forsplice_in_with_all.splice_in, and a CHANGELOG entry.Testing
splice_in_fee_does_not_spend_anchor_reserve: node B holds 1,000,000 sats with a 25,000 sat anchor reserve. Splicing in 970,000 at 50 sat/vB fails withInsufficientFunds, because the ~12,500 sat fee would leave only ~17,500 for the reserve. The same amount at the regtest estimate splices in and keeps the reserve on-chain.Fee bumps are left for a follow-up: the reserve check when a bump of an exact splice-in shrinks its change or re-runs coin selection, and when a bump of a splice-out falls back to the wallet, as discussed in #1181.
This change was developed with the assistance of Claude Code.