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

Use channel_reestablish tlv when sending channel_ready #3025

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

remyers
Copy link
Contributor

@remyers remyers commented Mar 4, 2025

When the remote node supports the your_last_funding_locked tlv we do not need to always resend channel_ready when there are no channel updates. The tlv removes the ambiguity about whether our last channel_ready was received.

When the remote node supports the 'your_last_funding_locked' tlv we do not need to always resend channel_ready when there are no channel updates. The tlv removes the ambiguity about whether our last channel_ready was received.
@remyers
Copy link
Contributor Author

remyers commented Mar 4, 2025

I refactored the reestablish logic a bit so that sending channel_ready and splice_locked can be compared more easily.

I added two tests for the legacy (pre-splice) behavior and updated any other tests that expected the old behavior.

@remyers remyers marked this pull request as ready for review March 4, 2025 15:11
@remyers remyers requested a review from t-bast March 4, 2025 15:11
Copy link
Member

@t-bast t-bast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, only nits

remyers added 2 commits March 5, 2025 10:00
For consistency, "re-sending" log messages should use the spec name, not the internal type.
@remyers
Copy link
Contributor Author

remyers commented Mar 5, 2025

Thanks for the feedback! I think it should all good now.

Comment on lines 916 to 925
val aliceInit = Init(alice.stateData match {
case d: ChannelDataWithoutCommitments => d.channelParams.localParams.initFeatures
case d: ChannelDataWithCommitments => d.commitments.params.localParams.initFeatures
case _ => Alice.nodeParams.initFeaturesFor(Bob.nodeParams.nodeId)
})
val bobInit = Init(bob.stateData match {
case d: ChannelDataWithoutCommitments => d.channelParams.localParams.initFeatures
case d: ChannelDataWithCommitments => d.commitments.params.localParams.initFeatures
case _ => Bob.nodeParams.initFeaturesFor(Alice.nodeParams.nodeId)
})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need this pattern matching? Can't you simply do:

Suggested change
val aliceInit = Init(alice.stateData match {
case d: ChannelDataWithoutCommitments => d.channelParams.localParams.initFeatures
case d: ChannelDataWithCommitments => d.commitments.params.localParams.initFeatures
case _ => Alice.nodeParams.initFeaturesFor(Bob.nodeParams.nodeId)
})
val bobInit = Init(bob.stateData match {
case d: ChannelDataWithoutCommitments => d.channelParams.localParams.initFeatures
case d: ChannelDataWithCommitments => d.commitments.params.localParams.initFeatures
case _ => Bob.nodeParams.initFeaturesFor(Alice.nodeParams.nodeId)
})
val aliceInit = Init(alice.nodeParams.initFeaturesFor(bob.nodeParams.nodeId))
val bobInit = Init(bob.nodeParams.initFeaturesFor(alice.nodeParams.nodeId))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It turns out that NodeParams used by init to create alice and bob was not using the computed init features. This should be fixed in 317d875.

The `nodeParams` used when creating `alice` and `bob` during `init` did not use the init features set by `computeFeatures`.
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

Successfully merging this pull request may close these issues.

2 participants