Expanded and rewrote large parts of this submission. I thought it would be more straightforward to break down a practical example and show readers exactly how a string of bits would be interpreted by another node.
I corrected an error from yesterday because I mistakenly did not realize that despite bit 2 not being used, bits 2 and 3 still form a "pair", so my count was off. One part I'm not 100% sure of is if I've read the string correctly. From right to left, I read bits 8 and 9 as "01", which is enabled and odd, so 'var_onion_optin' is enabled and backwards-compatible. Is this correct?
- How can TLV fields be used to extend the protocol, existing messages, and the onion itself?
- Sidenote that TLV can be used by upcoming Instant Messaging chat apps like `Whatsat`, `Sphinx Chat` or `Juggernaut`
### What is are Feature Bits and why do they matter?
### Feature Bits
#### What is are Feature Bits and why do we need them?
The Bitcoin protocol requires all nodes on the network to be in consensus on a common ruleset and list of features.
This means that 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, on the Lightning Network there is no such requirement.
If a new feature is introduced into the Lightning Network, 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 beta, as long as they can find other users willing to implement the feature along with them
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].
For example, multi-part payments, discussed in the chapter on Path-Finding, is an early-stage feature already deployed by some nodes at the time of writing.
Given the freedom inherent in the Lightning Network's design there will not be a global consensus on the Lightning Network as to which features are supported and which aren't.
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.
Some nodes may support multi-part payments, some may not, and some may never decide to support them.
As such, nodes need of a way of signalling to each other which features they support and which they do not.
They do so using pairs of 1s and 0s called "Feature Flags" or "Feature Bits".
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:
Whenever nodes communicate with each other, whether through channel announcements, invoices, or other methods, a part of that message is reserved to signal which features the node has enabled.
This message will take the form of a string of paired bits that will look something like this:
_00101000001000000000_
[feature_bits_example]
----
00101000001000000000
----
Flags are numbered from the least-significant bit (i.e. from right from left), starting from 0.
Flags are also paired, so that bits 0 and 1 form a pair, 2 and 3 form a pair, and so on.
BOLT #9 contains the full list of which digits stand for which features
Flags are numbered from the least-significant bit i.e. the right-most bit.
An odd-numbered bit communicates that the feature is backwards-compatible so the other node can accept it even if they don't have the feature enabled.
An even-numbered bit communicates that the feature is mandatory.
An odd-numbered bit pair (01) communicates that the feature is backwards-compatible.
An even-numbered bit pair (10) communicates that the feature is mandatory.
The rule of thumb is: "it's ok to be odd".
The other node needs to have the feature enabled in order for them to pay the invoice, open a channel etc.
For example, bit numbers 10 and 11 are reserved for the `gossip_queries_ex` feature, which allows additional information to be included in a gossip query.
In the above string, bit numbers 10 and 11 are "01", an odd number, which means that 'gossip_queries_ex' is enabled and is backwards compatible.
If both nodes have this feature enabled then they can make use of it, while other users who connect to them can simply ignore it.
Using BOLT #9 we can break down the above string as follows:
| 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.
Imran
4 years ago
committed by
GitHub