Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple funding transaction (candidates) per channel (Splicing, Dual Funding) #2743

Open
optout21 opened this issue Nov 22, 2023 · 2 comments

Comments

@optout21
Copy link
Contributor

optout21 commented Nov 22, 2023

Currently one channel has one funding transaction, this is expected to change with Dual funding and Splicing use cases. This issue is created to collect some of the concerns.

Current setup

A channel has one funding transaction, initially unset. During the channel opening process it gets set, then confirmed. Afterwards it does not change during the lifetime of the channel.

New use cases

V2 channel opening with RBF. It is possible to RBF a pending funding transaction, so it is possible to have two -- or more -- funding candidates. It is not known which will confirm first.

Spicing. In the transitional period before the new spliced funding transaction is confirmed, both old and new funding has to be kept. Only the new one can confirm, but at close both have to be attempted to closed (it is not known if old has been already spend by the new or not yet).

Splicing plus RBF. A combination of the above.

Some concerns

  • Currently channel has several fields keeping info about the funding transaction, these should be grouped for convenience. See Group channel funding transaction fields (small refactor) [splicing] #2736.
  • An additional structure for holding multiple funding TX candidates should be introduced. Probably a map where ID is TXID. It should be persisted.
  • When transactions get confirmed, we need to check against all candidates (not just against the single funding TX)
  • The existing field(s) should be kept and used for already locked funding TX, and for pending in the case of V1 opening. For V2 opening and Splicing, funding candidates should be kept in the new map.
  • Serialization b/w compatibility: the serialization of existing funding TX fields should not change. The new map should be serialized separately.
  • Support reorg. With a chain reorg it is possible that a confirmed transaction becomes unconfirmed. This is handled, and it should be handled similarly for multiple candidates.
  • Exclusivity, what happens with other candidates if one gets locked? In case of RBF only one of the candidates can confirm, but the others still need to be kept around for the case of an eventual reorg. It's also more robust not to assume that only one can get locked.
  • Channel closing: In case of Splicing, the pending candidate(s) needs to be considered, but the old funding tx as well (e.g. if the new funding was broadcast but rejected and will never lock).
@optout21 optout21 changed the title Support multiple funding transaction (candidates) per channel (Slicing, Dual Funding) Support multiple funding transaction (candidates) per channel (Splicing, Dual Funding) Nov 22, 2023
@optout21
Copy link
Contributor Author

optout21 commented Sep 9, 2024

Note: related: #3281

@optout21
Copy link
Contributor Author

A current proposal for channel states/phases is described here: https://gist.github.com/optout21/2ead7a0f4e2c3d34aed1c9703c8cfb39

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant