- 
                Notifications
    You must be signed in to change notification settings 
- Fork 421
Group channel funding transaction fields (small refactor) [splicing] #2736
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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: 
 I will rework in light of the above. | 
2918c4a    to
    97c3969      
    Compare
  
    | Reworked, simplified. | 
97c3969    to
    c0784b6      
    Compare
  
    | Codecov ReportAttention:  
 
 ❗ 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. | 
c0784b6    to
    11bbc01      
    Compare
  
    | 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) | 
| struct TransactionConfirmation { | ||
| /// The transaction, or None. | ||
| transaction: Option<Transaction>, | ||
| /// The hash of the block in which the transaction was included, or None. | ||
| confirmed_in: Option<BlockHash>, | ||
| /// The height of the block in which the transaction was included, or 0. | ||
| confirmation_height: u32, | ||
| } | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
11bbc01    to
    401254f      
    Compare
  
    | Cleaned up, adjusted description/title, marked ready. | 
| Do we plan to track a  | 
| 
 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. | 
| 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. | 
| Closing. Now I'm less sure that this would be needed in Splicing, and outside of Splicing it brings only minor benefits. | 
Groups three
Channelfields storing funding transaction status into a separate structureTransactionConfirmation. This is a small refactor with very minimal code logic change.Motivation:
funding_transaction,funding_tx_confirmed_in,funding_tx_confirmation_height).Changes:
TransactionConfirmationstruct, with fields fortransaction,confirmed_in, andconfirmation_heightNote: The serialization format is untouched.
See also #2743 .