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

tapchannel: check for feature bits before opening chans #1041

Merged
merged 2 commits into from
Aug 1, 2024

Conversation

Roasbeef
Copy link
Member

With the way the protocol works as is, we signal the optional feature bit, so connections can be made with older peers. Rather than timeout after they don't recognize our custom message, we'll instead use the feature bits to detect early if they don't understand the new protocol.

Fixes #1038

Copy link
Member

@guggero guggero left a comment

Choose a reason for hiding this comment

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

tACK, once the feature bit verifier is updated this works as advertised.

}

// If we get to this point, we weren't able to find the peer.
return false, tapchannel.ErrNoPeer
Copy link
Member

Choose a reason for hiding this comment

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

Seems weird to be returning an error from a package using this code... I know it's probably unavoidable with the current way the packages are depending on each other. But we should likely move all the lnd client related code into its own package.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah not a bad idea to move them.

Re returning the error from another package: I think it can be a useful pattern (assuming we use a new type for the errors) to restrict the type of errors that an implementation can return.

tapchannel/aux_funding_controller.go Show resolved Hide resolved
feature_bit_verifier.go Outdated Show resolved Hide resolved
@guggero guggero added this to the v0.4.1 milestone Jul 24, 2024
@Roasbeef Roasbeef requested a review from jharveyb July 29, 2024 23:35
Roasbeef added 2 commits July 29, 2024 16:39
With the way the protocol works as is, we signal the optional feature
bit, so connections can be made with older peers. Rather than timeout
after they don't recognize our custom message, we'll instead use the
feature bits to detect early if they don't understand the new protocol.

Fixes #1038
@Roasbeef Roasbeef force-pushed the funding-fast-fail branch from e2c25e4 to cf34c65 Compare July 29, 2024 23:39
Copy link
Contributor

@jharveyb jharveyb left a comment

Choose a reason for hiding this comment

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

LGTM 👍🏽


peerBytes := route.NewVertex(&peerPub)

peers, err := l.lnd.Client.ListPeers(ctx)
Copy link
Contributor

Choose a reason for hiding this comment

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

Would GetNodeInfo also work here? IIUC the info returned from that call should be as up-to-date and what's returned from ListPeers, for connected nodes. But AFAICT it doesn't show if we're actually connected to that node.

Copy link
Member Author

Choose a reason for hiding this comment

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

So each time we connect to a peer, we'll get the fresh set of feature bits from the init message. Compared to waiting for the next node_announcement, this should be more up to date.

@Roasbeef Roasbeef merged commit 6d018c0 into main Aug 1, 2024
16 checks passed
@guggero guggero deleted the funding-fast-fail branch August 5, 2024 07:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

[bug]: FundChannel Ack Timeout Issue
3 participants