|
|
@ -111,7 +111,7 @@ The structure of the `init` message is defined as follows:
|
|
|
|
** `tlv_stream_tlvs`
|
|
|
|
** `tlv_stream_tlvs`
|
|
|
|
|
|
|
|
|
|
|
|
Structurally, the `init` message is composed of two variable size bytes slices
|
|
|
|
Structurally, the `init` message is composed of two variable size bytes slices
|
|
|
|
that each store a set of _feature bits_. As we'll see later, feature bits are a
|
|
|
|
that each store a set of _feature bits_. As we see in <<feature_bits>>, feature bits are a
|
|
|
|
primitive used within the protocol in order to advertise the set of protocol
|
|
|
|
primitive used within the protocol in order to advertise the set of protocol
|
|
|
|
features a node either understands (optional features), or demands (required
|
|
|
|
features a node either understands (optional features), or demands (required
|
|
|
|
features).
|
|
|
|
features).
|
|
|
@ -143,7 +143,7 @@ connection as they're unable to open your new preferred channel type.
|
|
|
|
==== Error Communication Messages
|
|
|
|
==== Error Communication Messages
|
|
|
|
|
|
|
|
|
|
|
|
Messages in this category are used to send connection level errors between two
|
|
|
|
Messages in this category are used to send connection level errors between two
|
|
|
|
peers. As we'll see later, another type of error exists in the protocol: an
|
|
|
|
peers. Another type of error exists in the protocol: an
|
|
|
|
HTLC forwarding level error. Connection level errors may signal things like
|
|
|
|
HTLC forwarding level error. Connection level errors may signal things like
|
|
|
|
feature bit incompatibility, or the intent to force close (unilaterally
|
|
|
|
feature bit incompatibility, or the intent to force close (unilaterally
|
|
|
|
broadcast the latest signed commitment)
|
|
|
|
broadcast the latest signed commitment)
|
|
|
@ -218,16 +218,16 @@ off of.
|
|
|
|
==== Channel Funding
|
|
|
|
==== Channel Funding
|
|
|
|
|
|
|
|
|
|
|
|
As we go on, we enter into the territory of the core messages that govern the
|
|
|
|
As we go on, we enter into the territory of the core messages that govern the
|
|
|
|
functionality and semantics of the Lightning Protocol. In this section, we'll
|
|
|
|
functionality and semantics of the Lightning Protocol. In this section, we
|
|
|
|
explore the messages sent during the process of creating a new channel. We'll
|
|
|
|
explore the messages sent during the process of creating a new channel. We'll
|
|
|
|
only describe the fields used as we'll leave a in in-depth analysis of the
|
|
|
|
only describe the fields used as we leave a in in-depth analysis of the
|
|
|
|
funding process to chapter XXX.
|
|
|
|
funding process to <<payment_channels>>.
|
|
|
|
|
|
|
|
|
|
|
|
Messages that are sent during the channel funding flow belong to the following
|
|
|
|
Messages that are sent during the channel funding flow belong to the following
|
|
|
|
set of 5 messages: `open_channel`, `accept_channel`, `funding_created`,
|
|
|
|
set of 5 messages: `open_channel`, `accept_channel`, `funding_created`,
|
|
|
|
`funding_signed`, `funding_locked`. We'll leave a description of the precise
|
|
|
|
`funding_signed`, `funding_locked`.
|
|
|
|
protocol flow involving these messages for a chapter XXX. In this section,
|
|
|
|
|
|
|
|
we'll simply enumerate the set of fields and briefly describe each one.
|
|
|
|
The detailed protocol flow using these messages is described in <<payment_channels>>.
|
|
|
|
|
|
|
|
|
|
|
|
[[apdx_open_channel_message]]
|
|
|
|
[[apdx_open_channel_message]]
|
|
|
|
===== The `open_channel` message
|
|
|
|
===== The `open_channel` message
|
|
|
@ -304,10 +304,10 @@ The `accept_channel` message is the response to the `open_channel` message:
|
|
|
|
|
|
|
|
|
|
|
|
The `accept_channel` message is the second message sent during the funding flow
|
|
|
|
The `accept_channel` message is the second message sent during the funding flow
|
|
|
|
process. It serves to acknowledge an intent to open a channel with a new remote
|
|
|
|
process. It serves to acknowledge an intent to open a channel with a new remote
|
|
|
|
peer. The message mostly echos the set of parameters that the responder wishes
|
|
|
|
peer. The message mostly echoes the set of parameters that the responder wishes
|
|
|
|
to apply to their version of the commitment transaction. Later in Chapter XXX,
|
|
|
|
to apply to their version of the commitment transaction. In <<payment_channels>>,
|
|
|
|
when we go into the funding process in details, we'll do a deep dive to explore
|
|
|
|
when we go into the funding process in details, we do a deep dive to explore
|
|
|
|
the implications of the various par maters that can be set when opening a new
|
|
|
|
the implications of the various parameters that can be set when opening a new
|
|
|
|
channel.
|
|
|
|
channel.
|
|
|
|
|
|
|
|
|
|
|
|
In response, the initiator will send the `funding_created` message.
|
|
|
|
In response, the initiator will send the `funding_created` message.
|
|
|
@ -391,7 +391,7 @@ Channel closing is a multi-step process. One node initiates by sending the `shut
|
|
|
|
|
|
|
|
|
|
|
|
==== Channel Operation
|
|
|
|
==== Channel Operation
|
|
|
|
|
|
|
|
|
|
|
|
In this section, we'll briefly describe the set of messages used to allow
|
|
|
|
In this section, we briefly describe the set of messages used to allow
|
|
|
|
nodes to operate a channel. By operation, we mean being able to send receive,
|
|
|
|
nodes to operate a channel. By operation, we mean being able to send receive,
|
|
|
|
and forward payments for a given channel.
|
|
|
|
and forward payments for a given channel.
|
|
|
|
|
|
|
|
|
|
|
@ -417,8 +417,8 @@ Sending this message allows one party to initiate either sending a new payment,
|
|
|
|
or forwarding an existing payment that arrived via in incoming channel. The
|
|
|
|
or forwarding an existing payment that arrived via in incoming channel. The
|
|
|
|
message specifies the amount (`amount_msat`) along with the payment hash that
|
|
|
|
message specifies the amount (`amount_msat`) along with the payment hash that
|
|
|
|
unlocks the payment itself. The set of forwarding instructions of the next hop
|
|
|
|
unlocks the payment itself. The set of forwarding instructions of the next hop
|
|
|
|
are onion encrypted within the `onion_routing_packet` field. In Chapter XXX on
|
|
|
|
are onion encrypted within the `onion_routing_packet` field. In <<onion_routing>>, on
|
|
|
|
multi-hop HTLC forwarding, we details the onion routing protocol used in the
|
|
|
|
multi-hop HTLC forwarding, we detail the onion routing protocol used in the
|
|
|
|
Lighting Network in detail.
|
|
|
|
Lighting Network in detail.
|
|
|
|
|
|
|
|
|
|
|
|
Note that each HTLC sent uses an auto incrementing ID which is used by any
|
|
|
|
Note that each HTLC sent uses an auto incrementing ID which is used by any
|
|
|
@ -455,7 +455,7 @@ The `update_fail_htlc` is sent to remove an HTLC from a commitment transaction.
|
|
|
|
The `update_fail_htlc` is the opposite of the `update_fulfill_hltc` message as
|
|
|
|
The `update_fail_htlc` is the opposite of the `update_fulfill_hltc` message as
|
|
|
|
it allows the receiver of an HTLC to remove the very same HTLC. This message is
|
|
|
|
it allows the receiver of an HTLC to remove the very same HTLC. This message is
|
|
|
|
typically sent when an HTLC cannot be properly routed upstream, and needs to be
|
|
|
|
typically sent when an HTLC cannot be properly routed upstream, and needs to be
|
|
|
|
sent back to the sender in order to unravel the HTLC chain. As we'll explore in
|
|
|
|
sent back to the sender in order to unravel the HTLC chain. As we explore in
|
|
|
|
Chapter XX, the message contains an _encrypted_ failure reason (`reason`) which
|
|
|
|
Chapter XX, the message contains an _encrypted_ failure reason (`reason`) which
|
|
|
|
may allow the sender to either adjust their payment route, or terminate if the
|
|
|
|
may allow the sender to either adjust their payment route, or terminate if the
|
|
|
|
failure itself is a terminal one.
|
|
|
|
failure itself is a terminal one.
|
|
|
@ -563,11 +563,10 @@ network.
|
|
|
|
|
|
|
|
|
|
|
|
The series of signatures and public keys in the message serves to create a
|
|
|
|
The series of signatures and public keys in the message serves to create a
|
|
|
|
_proof_ that the channel actually exists within the base Bitcoin blockchain. As
|
|
|
|
_proof_ that the channel actually exists within the base Bitcoin blockchain. As
|
|
|
|
we'll detail in Chapter XXX, each channel is uniquely identified by a locator
|
|
|
|
we detail in <<sid>>, each channel is uniquely identified by a locator
|
|
|
|
that encodes it's _location_ within the blockchain. This locator is called this
|
|
|
|
that encodes it's _location_ within the blockchain. This locator is called this
|
|
|
|
`short_channel_id` and can fit into a 64-bit integer.
|
|
|
|
`short_channel_id` and can fit into a 64-bit integer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The `node_announcement` allows a node to announce/update it's vertex within the
|
|
|
|
The `node_announcement` allows a node to announce/update it's vertex within the
|
|
|
|
greater Channel Graph.
|
|
|
|
greater Channel Graph.
|
|
|
|
|
|
|
|
|
|
|
@ -652,7 +651,7 @@ related to a series of short channel IDs.
|
|
|
|
** `len*byte` : `encoded_short_ids`
|
|
|
|
** `len*byte` : `encoded_short_ids`
|
|
|
|
** `query_short_channel_ids_tlvs` : `tlvs`
|
|
|
|
** `query_short_channel_ids_tlvs` : `tlvs`
|
|
|
|
|
|
|
|
|
|
|
|
As we'll learn in Chapter XXX, these channel IDs may be a series of channels
|
|
|
|
As we learn in <<gosssip>>, these channel IDs may be a series of channels
|
|
|
|
that were new to the sender, or were out of date which allows the sender to
|
|
|
|
that were new to the sender, or were out of date which allows the sender to
|
|
|
|
obtain the latest set of information for a set of channels.
|
|
|
|
obtain the latest set of information for a set of channels.
|
|
|
|
|
|
|
|
|
|
|
@ -687,8 +686,7 @@ opened within a block range.
|
|
|
|
As channels are represented using a short channel ID that encodes the location
|
|
|
|
As channels are represented using a short channel ID that encodes the location
|
|
|
|
of a channel in the chain, a node on the network can use a block height as a
|
|
|
|
of a channel in the chain, a node on the network can use a block height as a
|
|
|
|
sort of _cursor_ to seek through the chain in order to discover a set of newly
|
|
|
|
sort of _cursor_ to seek through the chain in order to discover a set of newly
|
|
|
|
opened channels. In Chapter XXX, we'll go through the protocol peers use to
|
|
|
|
opened channels.
|
|
|
|
sync the channel graph in more detail.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The `reply_channel_range` message is the response to `query_channel_range` and
|
|
|
|
The `reply_channel_range` message is the response to `query_channel_range` and
|
|
|
|
includes the set of short channel IDs for known channels within that range.
|
|
|
|
includes the set of short channel IDs for known channels within that range.
|
|
|
|