[Splicing] Preserve `funding_transaction` for the later lifecycle of the channel by optout21 · Pull Request #3317 · lightningdevkit/rust-lightning

optout21 · 2024-09-16T15:10:32Z

In splicing, the funding transaction (not just the ID) is needed during splice negotiation.
Funding transaction is kept in field ChannelContext.funding_transaction.
However, the way it is currently used is that it is cleared when the tx is broadcast, and this fact is used in some logic.

This change:

does not clear ChannelContext.funding_transaction when tx is broadcast, but it's preserved
adds a funding_transaction_broadcast bool field to indicate if it has been broadcast

So behavior of not (re)broadcasting twice is preserve (though I am not sure whether this was intentional and it is needed, one test fails if this is changed (test_completed_payment_not_retryable_on_reload)).

Alternative would be to leave funding_transaction unchanged, and introduce a new funding_transaction_saved field, that is set the same way, but never cleared. This way existing logic would not be affected, but the tx would be kept in two copies.

codecov · 2024-09-16T15:18:02Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.88%. Comparing base (66fb520) to head (8339270).
Report is 64 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3317 +/- ##
==========================================
+ Coverage 89.66% 90.88% +1.22% 
==========================================
Files 126 127 +1 Lines 102676 115316 +12640 Branches 102676 115316 +12640 ==========================================
+ Hits 92062 104806 +12744 + Misses 7894 7869 -25 + Partials 2720 2641 -79

Flag	Coverage Δ
	`?`

Flags with carried forward coverage won't be shown. Click here to find out more.

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

jkczyz

Does this mean existing channels cannot be spliced?

jkczyz · 2024-10-04T22:04:00Z

 {
- self.context.funding_transaction.take()
+ let res = self.context.funding_transaction_unless_rebroadcast();
+ // Note: this is legacy logic, prevents (re)broadcasting twice, unclear if needed


Not sure what is meant by this. Why is it legacy logic?

What I mean by legacy:
I don't fully understand why it works this way
I suspect it is not by intention
but I chose to introduce an extra field just to keep the exact behavior
changing it would break one unit tests, and who knows what else in the field

@TheBlueMatt Any thoughts on making funding_transaction a three-state enum instead of introducing a flag and continuing to use Option? We'd probably need the flag in the serialization logic, though.

We could do that. That said, I do think the rebroadcasting logic is really dumb right now, so this may be an opportunity to clean it up. We could/maybe should drop all the tracking of if we broadcasted a transaction and replace it with a much simpler "if its not confirmed, broadcast it" heuristic.

Is there any downside for occasional repeated broadcast? At most some unnecessary resource usage?

Not hugely, no. We do get users confused when broadcasts fail all the time, so we mostly try to avoid it, but there's not a huge cost. We should definitely not rebroadcast forever though.

jkczyz · 2024-10-09T15:44:03Z

 let cur_holder_commitment_point = Some(self.context.holder_commitment_point.current_point());
 let next_holder_commitment_point = self.context.holder_commitment_point.next_point();

+ let funding_transaction_rebroadcast_flag = Some(self.context.funding_transaction_rebroadcast_flag);


Instead of wrapping this, use required below.

It's optional due to backwards compatibility.

It's an odd TLV so older versions will simply ignore it.

jkczyz · 2024-10-09T15:47:03Z

 let mut next_holder_commitment_point_opt: Option<PublicKey> = None;
 let mut is_manual_broadcast = None;

+ let mut funding_transaction_rebroadcast_flag: Option<bool> = None;


And then use (default_value, false) below instead of option.

jkczyz · 2024-10-09T16:49:57Z

 {
- self.context.funding_transaction.take()
+ let res = self.context.funding_transaction_unless_rebroadcast();
+ // Note: this is legacy logic, prevents (re)broadcasting twice, unclear if needed


@TheBlueMatt Any thoughts on making funding_transaction a three-state enum instead of introducing a flag and continuing to use Option? We'd probably need the flag in the serialization logic, though.

optout21 · 2024-10-09T19:15:51Z

Note: Changing this behavior causes a single test case to fail: ln::payment_tests::test_completed_payment_not_retryable_on_reload
(reproducible by not resetting funding_transaction in the original code, or keeping funding_transaction_rebroadcast_flag always false in the version of this PR)

The check that fails expects 1 broadcasted transaction, while with the change it will have the transaction broadcasted 4 times. I suspect this change does not really affect the desired behavior, this checks is simply over-specific and that can be updated, and the change is acceptable.

 assert_eq!(nodes[0].tx_broadcaster.txn_broadcasted.lock().unwrap().split_off(0).len(), 4);

…f the channel

optout21 · 2024-10-23T17:35:55Z

Alternative simpler solution in #3380 -- never clears the funding_transaction field, no new fields, which may result in additional rebroadcasts.
One should be chosen -- I lean for the simpler solution, but I have no strong opinion.

TheBlueMatt · 2024-10-29T17:54:58Z

Supersceded by #3380.

optout21 mentioned this pull request Sep 16, 2024
Dual-funded channels and Splicing Project Tracking #1621
Closed
7 tasks

TheBlueMatt reviewed Sep 16, 2024
View reviewed changes

Comment threadlightning/src/ln/channel.rs Outdated

optout21 force-pushed the channel_funding_tx branch from 2e925ee to 78f428eCompare September 18, 2024 15:33

jkczyz self-requested a review September 19, 2024 16:08

optout21 force-pushed the channel_funding_tx branch from 78f428e to bb043a1Compare September 20, 2024 09:25

optout21 marked this pull request as ready for review September 20, 2024 09:42

optout21 force-pushed the channel_funding_tx branch from bb043a1 to 020ac76Compare September 23, 2024 22:02

optout21 added the Splicing label Sep 25, 2024

jkczyz reviewed Oct 4, 2024
View reviewed changes

optout21 force-pushed the channel_funding_tx branch from 020ac76 to 8339270Compare October 9, 2024 13:12

jkczyz reviewed Oct 9, 2024
View reviewed changes

dunxen self-requested a review October 10, 2024 15:50

optout21 marked this pull request as draft October 17, 2024 16:59

Preserve ChannelContext.funding_transaction for the later lifecycle o…
6103652
…f the channel

optout21 force-pushed the channel_funding_tx branch from 8339270 to 6103652Compare October 23, 2024 17:19

optout21 mentioned this pull request Oct 23, 2024
[Splicing] Preserve funding_transaction for the later lifecycle of the channel, simple solution #3380
Merged

TheBlueMatt closed this Oct 29, 2024

Uh oh!

Conversation

optout21 commented Sep 16, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecovBot commented Sep 16, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

optout21 commented Oct 9, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

optout21 commented Oct 23, 2024

Uh oh!

TheBlueMatt commented Oct 29, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

optout21 commented Sep 16, 2024•
edited
Loading

codecovBot commented Sep 16, 2024•
edited
Loading

optout21 commented Oct 9, 2024•
edited
Loading