You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
lnbook/p2p.asciidoc

78 lines
4.7 KiB
Plaintext

Chapter overview:
* high level description of p2p interaction for the LN
Relevant questions to answer:
* Encrypted P2P Transport:
- What is the noise protocol? How does it differ from TLS? Who created it
- and what are some of primary design principles?
- What is an authenticated key exchange?
- Why does Noise offer various handshakes? What are some of unique properties certain handshakes offer?
- What is key rotation in the context of a complete handshake? Why is it important?
- What is "brontide"? How is it used in LN today? How can it be upgraded in the future?
* LN Message Format:
- What kind of framing is used in the LN message format? What's the max message size and why is it in place?
- What is a varint? Why is it used in the protocol?
- What are the message types of some of the popular messages in the protocol?
- How can new messages be added in the future?
* Feature bits:
- What are feature bits in the network, and how+where are they advertised?
- How can feature bits be used to phase in new features to the protocol?
- Today, what are some of the major feature bits used in the system?
- 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?
* TLV Message Extensions:
- What does TLV stand for?
- How is this related to the existing protobuf message format?
- Where are TLV fields used in the protocol today?
- 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?
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
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.
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".
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_
BOLT #9 contains the full list of which digits stand for which features
footnote:[https://github.com/lightningnetwork/lightning-rfc/blob/master/09-features.md].
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.
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.