Lightning Network Basics — Transport protocol
This article introduces the Lightning Network transport protocol.
BOLT defines transport protocol in BOLT#8.
It is a protocol based on the Noise Protocol framework and does not use TLS, etc.
Connection Handshake
The following information is required when connecting to the other node using a Lightning Network node.
- Connection destination node ID
- Destination IP address and port number
Since it is sufficient to have the information and node ID for socket connection with the other node by TCP, a domain name may be used depending on the implementation. By default, mainnet uses port number 9735 (this number is said to be because unicode number 9735 is “LIGHTNING”).
After the connection is established, there is a handshake that determines the key that encrypts the message. There is no such thing as a certificate authority, and exchanges are performed only between two points using the node ID (secp256k1 public key) that each node has and the private key that is the basis of it.
When the Act One , Act Two , and Act Three sequences are completed, the encoding key for the first transmission data and the decoding key for the reception data are determined for the Lightning Network protocol communication. From now on, ChaChaPoly-1305we will exchange Lightning messages in the protocol encoded in .
In addition, the transmission key and reception key do not continue to use the same key after the handshake, but the key is rotated when encoding or decoding is performed 1,000 times (the timing is different for the transmission key and the reception key). Since the header part and the body part are encrypted twice in one Lightning message, the number of messages will be rotated for 500 times.
Lightning message
The structure of a Lightning message is shown in the diagram above.
It is roughly divided into a header part and a body part, each of which consists of an encoding part and a MAC part.
Since the header length is a fixed size, when decoding, first confirm that the header part is correct, then decode the body part with the data length obtained from the header part. ChaCha20and Poly1305follow the general specification, so please refer to RFC8439 or other sources for details.
Thank you for your reading!
