In this commit, we carry out a new notion introduced during a recent
spec meeting to use a feature bit plus 100 before the feature has been
finalized in the spec.
We split into the Final and Staging bits.
Base 32 encoded bolt 11 invoices only allow 10 bits to express the
length of the feature vector in a tagged field, so there is a much
lower limit on the values invoice custom features can hold.
Other places in the protocol are theoretically limited by the maximum
message size, but since we express a feature bit as u16 we don't need
to be concerned about this.
The decision is made to track maximum per-set in the feature manager,
which is conceptually aware of sets and then validate in lnwire/features
against some arbitrary maximum value provided to the caller to keep
the base features package unaware of sets.
Disallow update of any features that are defined by LND (since
just updating the feature, but not the functionality will result in
strange behavior). All known feature bits should be toggled using
protocol config options.
In this commit, we add awareness of the option_shutdown_anysegwit that
permits both sides to send newer segwit based addresses. This'll
eventually enable us to send taproot addresses for co-op close.
This defines the zero-conf feature bit, the scid-alias feature bit,
the zero-conf channel type, and the scid-alias channel type. It also
defines the dependency "tree" that exists for the feature bits.
The scid-alias feature bit signals that the node requires an alias
short channel id to be sent in funding_locked. The scid-alias channel
type requires that the channel is private, in addition to some other
forwarding-related privacy measures.
This fixes an issue where if one tries to unset a feature like anchors,
and other feature depend on it, then `lnd` fails to start as it realizes
that its dependnacy set is inconsistent.
Fixes https://github.com/lightningnetwork/lnd/issues/6002
If these bits are present, then both sides can examine the new
CommitmentType TLV field that's present and use this in place of the
existing implicit commiment type negotiation. With this change, it's now
possible to actually deprecate old unsupported commitment types
properly.
AMP invoices need to signal:
- AMPRequired in order to avoid being paid by older clients that don't
support it.
- Can't advertised MPP optional, otherwise older clients will attempt
to pay the invoice with regular MPP payment.
Hence, the features advertised on AMP invoices are mutually exclusive
from those advertised on MPP. Create a new set to classify the two.
In this commit, we move to start requiring the payment addr feature bit
in the invoices we produce. With this change, if a user attempts to pay
one of our invoices (assuming they're also an lnd node), then they'll
receive an error when they attempt to pay. At this point, *most* lnd
nodes should be on v0.11 at this point, and this change will notify any
lagging wallet authors to update, as these payments are generally more
secure.
It's been sometime since we introduced this new safety enhancing feature
bit. At this point, we're now moving to require it as it makes our SCB
recovery system more robust, and it's also an implicit feature bit for
for anchor commitments as they're defined now.
This commit introduces a feature.Manager, which derives feature vectors
for various contexts within the daemon. The sets can be described via a
staticly compiled format, which makes any runtime adjustments to the
feature sets when the manager is initialized.
