Group channel funding transaction fields (small refactor) [splicing]

[optout21]

Groups three Channel fields storing funding transaction status into a separate structure TransactionConfirmation. This is a small refactor with very minimal code logic change.

Motivation:

• In the upcoming Splicing feature, there is a need to keep info about multiple funding transactions (e.g. while the new spliced tx is being confirmed, both the new and old must be kept around). With the current structure of multiple fields this is cumbersome.
• In Dual Funding, in case of RBF multiple funding transaction candidates have to be kept.
• Group together the several fields that relate to the funding transaction state (funding_transaction, funding_tx_confirmed_in, funding_tx_confirmation_height).

Changes:

• New TransactionConfirmation struct, with fields for transaction, confirmed_in, and confirmation_height
• convenience method for computing confirmation depth, handling special cases

Note: The serialization format is untouched.
See also #2743 .

[jkczyz]

Some concerns at a first glance and based on discussion in the weekly sync-up. Will defer to @wpaulino on any possible alternatives.

[optout21]

Some concerns at a first glance and based on discussion in the weekly sync-up. Will defer to @wpaulino on any possible alternatives.

Thx for the comments, some reactions:

• serializaion b/w compatibility is an important point, should be done
• ChannelFundingTransaction and ChannelFundingTransactions: The 's' here only holds an Option<> to the singular struct, with the idea that it can be easily changed to a Vec later; but on a second thought this may be a bit overengineered
• Serialization of the additional funding tx info (if any) is also to be decided/considered.
• An alternative is to keep one 'main'/'first' funding tx info as currently (maybe packed in one simple struct), and optionally add additional ones in a spearate Vector. This approach is more b/w compatible, not over-generalzied. Serialization can follow the same style.
• A simple TransactionConfirmation (as suggested here) struct could be used here.
  CC: @dunxen

I will rework in light of the above.

[optout21]

Reworked, simplified.

[codecov-commenter]

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (870a0f1) 88.55% compared to head (401254f) 88.56%.

Files	Patch %	Lines
lightning/src/ln/channel.rs	97.45%	0 Missing and 3 partials ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2736 +/- ##
==========================================
+ Coverage 88.55% 88.56% +0.01% 
==========================================
Files 113 113 Lines 89330 89409 +79 Branches 89330 89409 +79 ==========================================
+ Hits 79110 79189 +79 + Misses 7849 7847 -2 - Partials 2371 2373 +2 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[devrandom]

you might be interested in how we did it in the VLS project - https://gitlab.com/lightning-signer/validating-lightning-signer/-/blob/2023-09-funding6-signing/vls-core/src/channel.rs?ref_type=heads#L477-481

(although you have somewhat different needs than us)

[jkczyz]

If there are a distinct set of possibilities for how these are set and well-defined transitions, we may want to consider using an enum instead.

[optout21]

Would make a lot of sense, but as I see currently the transitions are not so well defined... Doing this would require a much bolder change with a larger impact.

[optout21]

Cleaned up, adjusted description/title, marked ready.

[wpaulino]

Do we plan to track a TransactionConfirmation per funding transaction (this doesn't really make sense since only can transaction can be confirmed), or keep a single one and add the other funding candidates later on as part of #2743? If the latter, I don't see how this refactor helps achieve that. It does make the confirmation logic a bit nicer to follow though.

[optout21]

Do we plan to track a TransactionConfirmation per funding transaction (this doesn't really make sense since only can transaction can be confirmed)

Yes, that's the idea. It is true that only one can get confirmed, but in some rare edge cases, due to reorg, a confirmed candidate can become unconfirmed, and theoretically another candidate can get confirmed. So I think it is needed to keep track of confirmation status of all candidates.

[wpaulino]

Right, but they can't happen at the same time. We must first see the reorg before seeing the new confirmation, and by then the confirmation status should have been reset, so I don't see the benefit to tracking the confirmation status individually per transaction candidate.

[optout21]

Right, but they can't happen at the same time. We must first see the reorg before seeing the new confirmation, and by then the confirmation status should have been reset, so I don't see the benefit to tracking the confirmation status individually per transaction candidate.

I think this small change makes sense even without considering Dual funding or Splicing. But you may be right that per-candidate confirmation tracking will not be needed.
I put it back to Draft for further considerations for now.

[optout21]

Closing. Now I'm less sure that this would be needed in Splicing, and outside of Splicing it brings only minor benefits.