Add support for using last_funding_locked tlv in channel_reestablish #3007

remyers · 2025-02-14T15:59:17Z

This TLV is relevant for splice funding txs only.

When the my_current_funding_locked_txid TLV attribute confirms the latest funding tx we prune previous funding transaction similarly to receiving splice_locked from our peer for that txid.

When we receive your_last_funding_locked_txid that does not match our latest confirmed funding tx, then we know our peer did not receive our last splice_locked and retransmit it.

For public channels, nodes also retransmit splice_locked after channel_reestablish if they have not received announcement_signatures for the latest confirmed funding tx. This is needed to prompt our peer to also retransmit their own splice_locked and announcement_signatures.

For public channels, nodes respond to splice_locked with their own splice_locked if it has already been received, but only once. If any announcement_signatures have been sent then we do not do this to prevent exchanging an endless loop of splice_locked messages.

These changes ensures both sides will have exchanged splice_locked after a disconnect and will be relevant for simple taproot channels to exchange nonces.

If the last_funding_locked tlv is not set then nodes always send splice_locked on reconnect to preserve previous behavior for retransmitting splice_locked.

Note: Previous behavior was susceptible to a race condition if one node sent a channel update after channel_reestablish, but before receiving splice_locked from a peer that had confirmed the latest funding tx while offline.

cf. lightning/bolts#1223

codecov-commenter · 2025-02-14T16:12:38Z

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.04%. Comparing base (10edb42) to head (34209f2).
Report is 15 commits behind head on master.

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

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3007      +/-   ##
==========================================
+ Coverage   86.02%   86.04%   +0.01%     
==========================================
  Files         228      228              
  Lines       20452    20816     +364     
  Branches      846      865      +19     
==========================================
+ Hits        17594    17911     +317     
- Misses       2858     2905      +47

Files with missing lines	Coverage Δ
...in/scala/fr/acinq/eclair/channel/Commitments.scala	`96.36% <100.00%> (+0.06%)`	⬆️
...in/scala/fr/acinq/eclair/channel/fsm/Channel.scala	`83.90% <100.00%> (-0.17%)`	⬇️
...ala/fr/acinq/eclair/wire/protocol/ChannelTlv.scala	`100.00% <100.00%> (ø)`
...q/eclair/wire/protocol/LightningMessageTypes.scala	`99.19% <100.00%> (+0.04%)`	⬆️

... and 7 files with indirect coverage changes

remyers · 2025-02-17T10:51:18Z

Some things to note during review:

1) The logic in Channel processing of the channel_reestablish message from our peer to determine whether or not to resend splice_locked has a second clause with the comment, "Resend if we have not received their remote announcement_signatures for our latest locked commitment". The logic here is as clear as I could make it, but could perhaps be made more clear. I'm open to suggestions. -- edit: hopefully fixed in force push to c1ebbbc.

I defined lastFundingLockedTlv in Commitments rather than computing it inline in Channels because it's convenient for tests in the OfflineStateSpec tests.

This TLV is relevant for splice funding txs only. When the `my_current_funding_locked_txid` TLV attribute confirms the latest funding tx we prune previous funding transaction similarly to receiving `splice_locked` from our peer for that txid. When we receive `your_last_funding_locked_txid` that does not match our latest confirmed funding tx, then we know our peer did not receive our last `splice_locked` and retransmit it. For public channels, nodes also retransmit `splice_locked` after `channel_reestablish` if they have not received `announcement_signatures` for the latest confirmed funding tx. This is needed to prompt our peer to also retransmit their own `splice_locked` and `announcement_signatures`. For public channels, nodes respond to splice_locked with their own splice_locked if it has already been received, but only once. If any announcement_signatures have been sent then we do not do this to prevent exchanging an endless loop of splice_locked messages. These changes ensures both sides will have exchanged `splice_locked` after a disconnect and will be relevant for simple taproot channels to exchange nonces. If the last_funding_locked tlv is not set then nodes always send splice_locked on reconnect to preserve previous behavior for retransmitting `splice_locked`. Note: Previous behavior was susceptible to a race condition if one node sent a channel update after `channel_reestablish`, but before receiving `splice_locked` from a peer that had confirmed the latest funding tx while offline. cf. lightning/bolts#1223

remyers · 2025-02-17T21:36:43Z

In c1ebbbc I modified the PR to account for legacy channel_reestablish where the new last_funding_locked tlv is not set. I also made changes to prevent a potential splice_locked loop for public channels.

eclair-core/src/main/scala/fr/acinq/eclair/wire/protocol/ChannelTlv.scala

eclair-core/src/main/scala/fr/acinq/eclair/wire/protocol/LightningMessageTypes.scala

eclair-core/src/main/scala/fr/acinq/eclair/channel/Commitments.scala

eclair-core/src/main/scala/fr/acinq/eclair/channel/fsm/Channel.scala

Note: the special cases for the funding tx without locked remote commit will be simplified in another PR.

…l_ready When reconnecting in the Normal state, if a legacy channel does not have its remote funding status set to `Locked`, set and store it to migrate older channels. After reconnecting in other states, the remote funding status will be set to `Locked` and stored when receiving `channel_ready` or deferred if still waiting for the funding tx to be confirmed locally.

Ensure we do not respond to the splice_locked we sent after channel_reestablish with the same splice_locked. There can only be one signed channel announcement and so only one corresponding last splice_locked that could be re-sent after channel_reestablish.

eclair-core/src/main/scala/fr/acinq/eclair/channel/fsm/Channel.scala

eclair-core/src/main/scala/fr/acinq/eclair/channel/Commitments.scala

eclair-core/src/main/scala/fr/acinq/eclair/channel/fsm/CommonFundingHandlers.scala

eclair-core/src/test/scala/fr/acinq/eclair/channel/states/c/WaitForChannelReadyStateSpec.scala

eclair-core/src/main/scala/fr/acinq/eclair/channel/fsm/Channel.scala

t-bast

I finished reviewing the tests, they're really good!

eclair-core/src/test/scala/fr/acinq/eclair/channel/states/e/NormalSplicesStateSpec.scala

@t-bast

Implements suggestions from @t-bast - prevent races - do not re-send announcement sigs if already sent if we receive a redundant splice_locked - update tests to correctly handle receiving a redundant splice_locked - add missing comment about spec change

@t-bast

Implements suggestions from @t-bast - spliceLockedSent becomes a map - add code to trim spliceLockedSent to 10 entries

@t-bast

@t-bast version of this logic is easier to parse and decomposes the comments to make them easier to parse.

When alice receives splice_locked from bob, either before disconnect or after, sometimes alice does not send their announcement_signatures because announcementSigsSent contains the shortChannelId of fundingTx. Modified tests to prevent a race that caused these tests to fail. I suspect somehow after transitioning to the Normal state, the initial funding announcement could briefly be in announcementSigsSent and prevent sending the splice announcement when alice receives splice_locked.

@t-bast

It should not drop pending splices.. Great catch @t-bast !

- moved lastLocalLocked_opt and lastRemoteLocked_opt to be after other vals.

eclair-core/src/main/scala/fr/acinq/eclair/channel/fsm/Channel.scala

We only need to track the fundingTxIndex (not the msg) We should also add it everytime we send splice_locked.

t-bast

LGTM 🚀 🔥

remyers force-pushed the 2502-current-funding-locked branch from 34209f2 to 5cd1827 Compare February 17, 2025 10:45

remyers marked this pull request as ready for review February 17, 2025 10:51

remyers force-pushed the 2502-current-funding-locked branch from 2633d17 to c1ebbbc Compare February 17, 2025 21:20

t-bast reviewed Feb 18, 2025

View reviewed changes

remyers added 4 commits February 18, 2025 20:41

Fix accessors for last_funding_locked tlv

1726b49

Note: the special cases for the funding tx without locked remote commit will be simplified in another PR.

Add Lightning message codec tests for new tlvs

c2ad77d

remyers force-pushed the 2502-current-funding-locked branch from 4fc3cd2 to c2ad77d Compare February 25, 2025 10:36

remyers commented Feb 25, 2025

View reviewed changes

eclair-core/src/main/scala/fr/acinq/eclair/channel/fsm/Channel.scala Outdated Show resolved Hide resolved

t-bast reviewed Feb 25, 2025

View reviewed changes

remyers added 6 commits February 26, 2025 13:49

Change spliceLockedSent into a map

29c4a9c

Implements suggestions from @t-bast - spliceLockedSent becomes a map - add code to trim spliceLockedSent to 10 entries

Refactor logic/comments for sending splice_locked after reestablish

0779315

@t-bast version of this logic is easier to parse and decomposes the comments to make them easier to parse.

Fix locking remote funding status for initial commits

1e81787

It should not drop pending splices.. Great catch @t-bast !

Fix nits

6de15c4

- moved lastLocalLocked_opt and lastRemoteLocked_opt to be after other vals.

t-bast reviewed Feb 28, 2025

View reviewed changes

Fix to simplify spliceLockedSent

e4a9062

We only need to track the fundingTxIndex (not the msg) We should also add it everytime we send splice_locked.

t-bast approved these changes Mar 3, 2025

View reviewed changes

remyers merged commit 21917f5 into ACINQ:master Mar 3, 2025
1 check passed

t-bast mentioned this pull request Mar 4, 2025

Implement updated retransmission logic for splice_locked #2987

Closed

t-bast mentioned this pull request Mar 31, 2025

Lightning channel funded but remains in inactive status ACINQ/phoenix#689

Closed

This was referenced Apr 6, 2025

Socratic Seminar #30 Topics NashBitDevs/nashbitdevs.org#82

Closed

DC BitDevs 014 Topic Suggestion dcbitdevs/dcbitdevs.github.io#24

Closed

Add support for using last_funding_locked tlv in channel_reestablish #3007

Add support for using last_funding_locked tlv in channel_reestablish #3007

Uh oh!

Conversation

remyers commented Feb 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov-commenter commented Feb 14, 2025

Codecov Report

Uh oh!

remyers commented Feb 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

remyers commented Feb 17, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

t-bast left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

t-bast left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

remyers commented Feb 14, 2025 •

edited

Loading

remyers commented Feb 17, 2025 •

edited

Loading