-
Notifications
You must be signed in to change notification settings - Fork 123
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,54 @@ | ||
package taprootassets | ||
|
||
import ( | ||
"context" | ||
|
||
"github.com/btcsuite/btcd/btcec/v2" | ||
"github.com/lightninglabs/lndclient" | ||
"github.com/lightninglabs/taproot-assets/tapchannel" | ||
"github.com/lightningnetwork/lnd/lnwire" | ||
"github.com/lightningnetwork/lnd/routing/route" | ||
) | ||
|
||
// LndFeatureBitVerifier is a struct that verifies that the feature bits of a | ||
// target connected peer, using our registered lnd node. | ||
type LndFeatureBitVerifier struct { | ||
lnd *lndclient.LndServices | ||
} | ||
|
||
// NewLndFeatureBitVerifier creates a new LndFeatureBitVerifier instance. | ||
func NewLndFeatureBitVerifier( | ||
lnd *lndclient.LndServices) *LndFeatureBitVerifier { | ||
|
||
return &LndFeatureBitVerifier{ | ||
lnd: lnd, | ||
} | ||
} | ||
|
||
// HasFeature returns true if the peer has the given feature bit set. If the | ||
// peer can't be found, then ErrNoPeer is returned. | ||
func (l *LndFeatureBitVerifier) HasFeature(ctx context.Context, | ||
peerPub btcec.PublicKey, bit lnwire.FeatureBit) (bool, error) { | ||
|
||
peerBytes := route.NewVertex(&peerPub) | ||
|
||
peers, err := l.lnd.Client.ListPeers(ctx) | ||
if err != nil { | ||
return false, err | ||
} | ||
|
||
for _, peer := range peers { | ||
if peer.Pubkey != peerBytes { | ||
continue | ||
} | ||
|
||
return peer.Features.HasFeature(bit), nil | ||
} | ||
|
||
// If we get to this point, we weren't able to find the peer. | ||
return false, tapchannel.ErrNoPeer | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
} | ||
|
||
// A compile-time check to ensure that LndFeatureBitVerifier implements the | ||
// FeatureBitVerifier interface. | ||
var _ tapchannel.FeatureBitVerifer = (*LndFeatureBitVerifier)(nil) |
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
GetNodeInfo
also work here? IIUC the info returned from that call should be as up-to-date and what's returned fromListPeers
, for connected nodes. But AFAICT it doesn't show if we're actually connected to that node.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.
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 nextnode_announcement
, this should be more up to date.