Update to select funding inputs before sending open_channel2 and splice_init#2903
Closed
remyers wants to merge 8 commits intoACINQ:masterfrom
Closed
Update to select funding inputs before sending open_channel2 and splice_init#2903remyers wants to merge 8 commits intoACINQ:masterfrom
remyers wants to merge 8 commits intoACINQ:masterfrom
Conversation
We replace our experimental version of `splice_init`, `splice_ack` and `splice_locked` by their official version. If our peer is using the experimental feature bit, we convert our outgoing messages to use the experimental encoding and incoming messages to the official messages. We also change the TLV fields added to `tx_add_input`, `tx_signatures` and `splice_locked` to match the spec version. We always write both the official and experimental TLV to updated nodes (because the experimental one is odd and will be ignored) but we drop the official TLV if our peer is using the experimental feature, because it won't understand the even TLV field. This guarantees backwards-compatibility with peers who only support the experimental feature.
We initially supported splicing with a poor man's quiescence, where we allowed splice messages if the commitments were already quiescent. We've shipped support for quiescence since then, which means that new even nodes relying on experimental splicing should support quiescence. We can thus remove support for the non-quiescent version.
If the latest splice transaction doesn't confirm, we allow exchanging `tx_init_rbf` and `tx_ack_rbf` to create another splice transaction to replace it. We use the same funding contribution as the previous splice. We disallow creating another splice transaction using `splice_init` if we have several RBF attempts for the latest splice: we cannot know which one of them will confirm and should be spent by the new splice.
When 0-conf isn't used, we reject `splice_init` while the previous splice transaction hasn't confirmed. Our peer should either use RBF instead of creating a new splice, or they should wait for our node to receive the block that confirmed the previous transaction. This protects against chains of unconfirmed transactions.
This change passes `maxExcess` to Peer via OpenChannel and from Peer to Channel via INPUT_INIT_CHANNEL_INITIATOR. The `maxExcess` parameter will be used by bitcoind funding calls but is not currently used.
…ion calls These parameters are only supported in a testing branch of bitcoind for now.
This will be used by non-initiators when funding dual funded channels and splicing
Member
|
I haven't done a thorough review yet, but the approach is looking good, concept ACK 👍. This is even less invasive than I thought, I was afraid we would have to do the funding in the It's a good thing we had already separated the funding step ( |
remyers
force-pushed
the
2409-funder-first-dual-official
branch
2 times, most recently
from
81ab7d2 to
dc102b5
Compare
…ce_init - If `addExcessToRecipientPosition_opt` is set, excess from funding (if any) will be added to the proposed `fundingAmount`/`fundingContribution` before sending `open_channel2`/`splice_init` respectively. - 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.
remyers
force-pushed
the
2409-funder-first-dual-official
branch
from
dc102b5 to
38ae09a
Compare
Contributor
Author
|
Closed in favor of #2924 which does not require changes to bitcoind. |
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
2 participants
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.
When funds are added to a dual funded channel, or spliced into an existing channel, our channel should be credited in their channel balance any excess that is added to the channel over what the user requests. Currently if a changeless solution is found for funding, excess value over what was requested will be treated as waste and used as extra fees.
The motivation for this change is to take advantage of the new Bitcoin channel selection options proposed in PR 30080 to retain excess funding from changeless transactions and add it to our channel balance.
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 usingInteractiveTxFunderto fund the transaction. The call toInteractiveTxFunderis now made before sendingopen_channel2orsplice_initand the results are then passed toInteractiveTxBuilder.This PR builds on PR #2887 - Use final spec values for splicing.