-
Notifications
You must be signed in to change notification settings - Fork 132
Feature bits #1748
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
base: main
Are you sure you want to change the base?
Feature bits #1748
Conversation
eb267a6
to
77f9420
Compare
Pull Request Test Coverage Report for Build 17382758755Details
💛 - Coveralls |
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.
A few initial questions and comments, mostly about the AuxChanNegotiator handling in the RFQ system.
77f9420
to
74d98bf
Compare
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.
Made another pass, with some additional questions and suggestions. I think everything on my end should be resolved after this.
@@ -125,13 +127,23 @@ type AssetSalePolicy struct { | |||
// wants us to produce NoOp HTLCs. | |||
NoOpHTLCs bool |
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.
Can anything pathological happen if we register an AssetSalePolicy with NoOpHTLCs enabled/disabled, but then restart with NoOpHTLCs disabled/enabled before the policy expires?
@@ -125,13 +127,23 @@ type AssetSalePolicy struct { | |||
// wants us to produce NoOp HTLCs. | |||
NoOpHTLCs bool | |||
|
|||
// auxChannelNegotiator is used to query the supported feature bits that | |||
// are supported by a peer, or a channel. | |||
auxChanNegotiator *tapfeatures.AuxChannelNegotiator |
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.
Revisiting: see my PR to this branch for a potential alternative way to handle this.
func NewAssetSalePolicy(quote rfqmsg.BuyAccept, noop bool) *AssetSalePolicy { | ||
func NewAssetSalePolicy(quote rfqmsg.BuyAccept, noop bool, | ||
chanNegotiator *tapfeatures.AuxChannelNegotiator, | ||
peer route.Vertex) *AssetSalePolicy { |
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.
I think the 'peer' argument here is unnecessary, as it can be gotten from quote.Peer?
Description
Adds the necessary subsystem to handle custom feature bit negotiation for tap channels. This allows us to introduce new channel features that would otherwise break backwards compatibility. We piggy-back on the existing LND messages (init & reestablish) to nest the
tlv.Blob
that encodes theCustomChannelType
(uint64) type.The set of active features over a channel is the intersection of the locally supported features and the features that the peer provided.
Currently we follow a "global" approach on the feature bits that we support. We don't make any distinctions between peers or channels. The locally supported feature bits is a static set.
We also don't allow reading/writing feature bits per channel, but per peer. For now the funding outpoint / funding blob arguments are ignored. When we establish a feature-set with a peer, that applies to all of our channels with that peer.
An older tapd node (i.e a node that does not contain the contents of this PR) will be treated as if they provided an empty feature set (
uint64
with0
's)Dependencies
LND lightningnetwork/lnd#10182
Lndclient lightninglabs/lndclient#239
LiT itest: lightninglabs/lightning-terminal#1138