Archives/lnbook
2
0
Fork 0
mirror of https://github.com/lnbook/lnbook synced 2024-11-01 03:20:53 +00:00
Code Issues Projects Releases Wiki Activity

References update

Browse Source
This commit is contained in:
Andreas M. Antonopoulos 2021-09-21 12:59:51 +02:00
parent c43cca3d0d
commit 0f07196ef8
1 changed files with 19 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
appendix_protocol_messages.asciidoc
View File

@ -111,7 +111,7 @@ The structure of the `init` message is defined as follows:
** `tlv_stream_tlvs`
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
features a node either understands (optional features), or demands (required
features).
@ -143,7 +143,7 @@ connection as they're unable to open your new preferred channel type.
==== Error Communication Messages
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
feature bit incompatibility, or the intent to force close (unilaterally
broadcast the latest signed commitment)
@ -218,16 +218,16 @@ off of.
==== Channel Funding
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
only describe the fields used as we'll leave a in in-depth analysis of the
funding process to chapter XXX.
only describe the fields used as we leave a in in-depth analysis of the
funding process to <<payment_channels>>.
Messages that are sent during the channel funding flow belong to the following
set of 5 messages: `open_channel`, `accept_channel`, `funding_created`,
`funding_signed`, `funding_locked`. We'll leave a description of the precise
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.
`funding_signed`, `funding_locked`.
The detailed protocol flow using these messages is described in <<payment_channels>>.
[[apdx_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
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
to apply to their version of the commitment transaction. Later in Chapter XXX,
when we go into the funding process in details, we'll do a deep dive to explore
the implications of the various par maters that can be set when opening a new
peer. The message mostly echoes the set of parameters that the responder wishes
to apply to their version of the commitment transaction. In <<payment_channels>>,
when we go into the funding process in details, we do a deep dive to explore
the implications of the various parameters that can be set when opening a new
channel.
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
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,
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
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
are onion encrypted within the `onion_routing_packet` field. In Chapter XXX on
multi-hop HTLC forwarding, we details the onion routing protocol used in the
are onion encrypted within the `onion_routing_packet` field. In <<onion_routing>>, on
multi-hop HTLC forwarding, we detail the onion routing protocol used in the
Lighting Network in detail.
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
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
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
may allow the sender to either adjust their payment route, or terminate if the
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
_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
`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
greater Channel Graph.
@ -652,7 +651,7 @@ related to a series of short channel IDs.
** `len*byte` : `encoded_short_ids`
** `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
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
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
opened channels. In Chapter XXX, we'll go through the protocol peers use to
sync the channel graph in more detail.
opened channels.
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.