- What's the difference between and end-to-end network upgrade and an internal network upgrade? How's the analogous to the evolution of routers and protocols in the existing internet?
Feature bits, or feature flags, are a string of 1s and 0s that Lightning nodes use to communicate to each other which features and upgrades they have enabled.
But why would they need to do this?
As discussed in earlier chapters, the Lightning Network protocol does not require all nodes to be in agreement on a common ruleset and list of features, which is quite different to the Bitcoin protocol.
If someone wants to introduce a new feature into Bitcoin (such as Replace-by-Fee) then either all nodes will need to accept this feature or the feature needs to be backwards-compatible.
However, if a new feature is introduced into the Lightning Network, Lightning users don't need to wait for the rest of the network to upgrade.
They can start using the new feature immedietely.
Even if that feature is still in development, they can implement it as long as they can find other users willing to implement the feature along with them
footnote:[The Lightning Network itself was famously put into use before it's official "launch". Despite LN developers warning users that the software was still in beta and had bugs, users around the world set up their own nodes and used the software recklessly].
One example of a feature would be multi-part payments, discussed in the chapter on Path-Finding.
Despite being an early-stage feature that is still in development at the time of writing, it is already deployed by some nodes.
Given the inherent freedom in the Lightning Network's design there will never be a global consensus on the Lightning Network as to which features are supported and which aren't.
They do so using pairs of 1s and 0s called Feature Bits.
#### How do Feature Bits work?
Whenever nodes communicate with each other, whether through invoices or other methods, a part of that message is reserved to signal which features the node has enabled.
For example, the `channel_announcement` and `node_announcement` messages described in BOLT #7 have a predefined `features` field reserved for this information.
The `features` field will take the form of a string of paired bits that will look something like this:
| 18/19 | `option_support_large_channel` | 00 | Not enabled |
If Alice sees this string in a node announcement message from Bob's node, then it knows from bits 16 and 17 that Bob's node supports multi-part payments.
And because the pair is odd, Alice's node knows that the feature is backwards-compatible.
If Alice also has multi-part payments enabled, then Alice and Bob can make use of this feature.
If Alice does not have multi-part payments enabled, she can simply ignore this and get on with her life.
She could still open a channel with Bob without having the feature enabled herself.
However, if the feature bits were even then the feature would be mandatory.
If Alice did not also have this feature enabled, she would have to find another node to open a channel with.
Alice also knows from bits 18 and 19 that Bob does not have large channels enabled.
If she has would like to open a large channel, then she would have to find someone else to open it with.
In this way, upgrades and new features can be rolled out on the Lightning Network in an asynchronous bottom-up way.
Users can enable the features they want when they are ready to do so.
Power users can use and test features without waiting for them to be formally released, and more conservative users are not pressured into using a new feature before they are comfortable to do so.
Users can simply signal to each other which features they support, and even if they do not agree on the feature set, they can still connect and transact as long they agree on all mandatory features.
