The messaging layer, which is detailed in this chapter, consists of "Message Framing and Format," "Type Length Value (TLV)" encoding, and "Feature Bits." These components are highlighted by a double outline in the protocol suite, shown in <<LN_protocol_wire_message_highlight>>.
The final bullet point allows for a degree of _backward_ compatibility because new nodes are able to provide information in the wire messages that older nodes
(which may not understand them) can safely ignore. As we see subsequently, this
| `node_alias` | A 32-byte fixed-length byte slice | When decoding, reject if contents are not a valid UTF-8 string
| `channel_id` | A 32-byte fixed-length byte slice that maps an outpoint to a 32-byte value | Given an outpoint, one can convert it to a `channel_id` by taking the TxID of the outpoint and XORing it with the index (interpreted as the lower 2 bytes)
| `short_chan_id` | An unsigned 64-bit integer (`uint64`) | Composed of the block height (24 bits), transaction index (24 bits), and output index (16 bits) packed into 8 bytes
| `milli_satoshi` | An unsigned 64-bit integer (`uint64`) | Represents 1000th of a satoshi
| `satoshi` | An unsigned 64-bit integer (`uint64`) | The base unit of bitcoin
| `pubkey` | An secp256k1 public key encoded in _compressed_ format, occupying 33 bytes | Occupies a fixed 33-byte length on the wire
Protobufs are extremely popular amongst developers because they have built in
support for both forward and backward compatibility. Most developers are
likely familiar with the concept of backward compatibility. In simple terms,
the principle states that any changes to a message format or API should be
done in a manner that doesn't break support for older clients. Within our preceding Protobuf extensibility examples, backward compatibility is achieved by
ensuring that new additions to the Protobuf format don't break the known portions
of older readers. Forward compatibility, on the other hand, is just as important
for desynchronized updates; however, it's less commonly known. For a change to
be forward compatible, clients are to simply ignore any information
they don't understand. The soft fork mechanism of upgrading the Bitcoin
consensus system can be said to be both forward and backward compatible: any
clients that don't update can still use Bitcoin, and if they encounter any
To be able to upgrade messages in a manner that is both forward and backward
compatible, in addition to feature bits (more on that later), the Lightning Network utilizes a custom message serialization format plainly called Type-Length-Value, or TLV for short. The format was inspired by the widely used Protobuf
Both the `type` and `length` are encoded using a variable sized integer that's inspired by the variable sized integer (varint) used in Bitcoin's P2P protocol, called `BigSize` for short.
1. If the value is less than `0xfd` (`253`): Then the discriminant isn't really used, and the encoding is simply the integer itself. This allows us to encode very small integers with no additional overhead.
2. If the value is less than or equal to `0xffff` (`65535`):The discriminant is encoded as `0xfd`, which indicates that the value that follows is larger than `0xfd`, but smaller than `0xffff`). The number is then encoded as a 16-bit integer. Including the discriminant, then we can encode a value that is greater than 253, but less than 65,535 using 3 bytes.
3. If the value is less than `0xffffffff` (`4294967295`): The discriminant is encoded as `0xfe`. The body is encoded using 32-bit integer, including the discriminant, then we can encode a value that's less than `4,294,967,295` using 5 bytes.
The `value` of a record depends on the `type`. In other words, it can take any form because parsers will attempt to interpret it depending on the context of the type itself.
* All records must minimally encode the `type` and `length` fields. In other words, the smallest `BigSize` representation for an integer must be used at all times.
However, unlike Bitcoin, overwhelming consensus _is not_ required to change a
subset of the Lightning Network. Lightning is able to evolve at will without a
strong requirement of coordination because, unlike Bitcoin, there is no global consensus required in the Lightning Network. Due to this fact and the several
upgrade mechanisms embedded in the Lightning Network, only the
participants that wish to use these new Lightning Network features need to
upgrade, and then they are able to interact with each other.
In this section, we explore the various ways that developers and users are
able to design and deploy new features to the Lightning Network. The
designers of the original Lightning Network knew that there were many possible future directions for the network and the underlying protocol. As a result, they made sure to implement several
extensibility mechanisms within the system, which can be used to upgrade it partially or fully in a decoupled, desynchronized, and decentralized
required features are signaled using an _even bit number_. As an example, if a peer signals that they known of a feature that uses bit +15+, then we know that
characterized by one that requires _every single node_ within a prospective payment path to understand the new feature. Such an upgrade is similar to any
_spontaneous_ payments deployed within the network. One early type of
spontaneous payments called _keysend_ worked by simply placing the preimage of a payment within the encrypted onion. Upon receipt, the destination would decrypt the
preimage, then use that to settle the payment. Because the entire packet is end-to-end encrypted, this payment type was safe, since none of the intermediate nodes
are able to fully unwrap the onion to uncover the payment preimage.
The final broad category of updates are those that happen at
the channel construction level, but which don't modify the structure of the HTLC used widely within the network. When we say channel construction, we mean
how the channel is funded or created. As an example, the eltoo channel type
Lightning's wire protocol is incredibly flexible and allows for rapid innovation and interoperability without strict consensus. It is one of the reasons that the Lightning Network is experiencing much faster development and is attractive to many developers, who might otherwise find Bitcoin's development style too conservative and slow.