Update to select funding inputs first before sending open_channel2, splice_init and tx_init_rbf #3111
Conversation
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
If a changeless set of inputs is found, excess funding (if any) will be added to the proposed `fundingAmount`/`fundingContribution` before sending `open_channel2`/`splice_init` respectively. InteractiveTxFunder sets `excess_opt` with the input value in excess of what is needed to achieve the requested target feerate. We assume our peer requires confirmed inputs. In the future we could add a heuristic for this, but it's safer to assume they want confirmed inputs.
Select funding inputs before sending splice_ack when adding liquidity Added the `SpliceStatus.SpliceInitiated` state for when `SpliceInit` is received with a valid liquidity request, but the wallet has yet returned funding inputs.
Reuse previous inputs when sending tx_rbf_ack if adding liquidity and adjust change amount to increase fees or modify the funding amount. Reject RBF attempts that increase liquidity requests, but allow valid lower liquidity requests. If we request liquidity in our RBF, our peer will not add additional inputs and may not be able to fully fund the feerate increase from their change output; that's ok. TODO: Check that all failure cases end quiescence, send tx_abort and/or unlocked inputs as needed. TODO: Refactor InteractiveTxBuilder to not call InteractiveTxFunder; fundingContributions should always be set now.
|
@t-bast This is ready for a first round of review now that I've added RBF support. Some areas that may require additional review or work:
|
When checking feerates, variation in signature sizes can make our remoteFundingTx feerate go below the target feerate. This doesn't matter because it will always have a larger feerate after removing the duplicate common elements.
This won't have any impact on Phoenix, since 0-conf wallets don't use RBF. |
2 tasks
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.
This PR replaces #2924 to find funding inputs first for all interactive funding requests: dual funding, splices and rbfs. The main reasons for this change is to retain excess funding from changeless inputs, but it also allows nodes to fail early if funding is not available.
When changeless inputs are used to fund a dual funded channel or spliced into an existing channel, our channel balance will be credited with any excess that is added to the channel over what the user requests. Previously that value would have gone to fees up to the dust limit which increases as fee rates increase. Before this PR when a changeless solution was used for funding, excess value over what was requested was treated as waste and used as extra fees.
This PR also changes the RBF behavior of nodes providing funding from a liquidity ad. A node will not add inputs in response to an RBF request when it added funding in response to a liquidity ad. This change protects a liquidity provider from locking a potentially unlimited number of inputs for a dual-funded channel or splice it did not initiate. Instead of adding inputs, only the change output amount will used to increase the feerate. The change amount may be insufficient to reach the newly requested RBF feerate and that's ok; the channel/splice initiator can lower their liquidity request in the RBF to allocate more of the liquidity provider's input amount to change.
We introduce a new optional funding contributions parameter to InteractiveTxBuilder. When set, we will start by processing the passed in funding inputs/outputs instead of using InteractiveTxFunder to fund the transaction. The call to InteractiveTxFunder is now made before sending open_channel2, splice_init, tx_init_rbf or tx_ack_rbf and the results are then passed to InteractiveTxBuilder.