The structure of the `init` message is defined as follows:
[[apdx_init_message]]
===== The `init` message
===== The init message
* type: *16*
* fields:
@ -151,7 +151,7 @@ broadcast the latest signed commitment)
The sole message in this category is the `error` message:
[[apdx_error_message]]
===== The `error` message
===== The error message
* type: *17*
* fields:
@ -178,7 +178,7 @@ transport being used to transmit the messages, a set of protocol level `ping`
and `pong` messages are defined.
[[apdx_ping_message]]
===== The `ping` message
===== The ping message
* type: *18*
* fields:
@ -189,7 +189,7 @@ and `pong` messages are defined.
Next it's companion, the `pong` message.
[[apdx_pong_message]]
===== The `pong` message
===== The pong message
* type: *19*
* fields:
@ -230,7 +230,7 @@ set of 5 messages: `open_channel`, `accept_channel`, `funding_created`,
The detailed protocol flow using these messages is described in <<payment_channels>>.
[[apdx_open_channel_message]]
===== The `open_channel` message
===== The open_channel message
* type: *32*
* fields:
@ -282,7 +282,7 @@ commonly referred to as a "private" channel.
The `accept_channel` message is the response to the `open_channel` message:
[[apdx_accept_channel_message]]
===== The `accept_channel` message
===== The accept_channel message
* type: *33*
* fields:
@ -313,7 +313,7 @@ channel.
In response, the initiator will send the `funding_created` message.
[[apdx_funding_created_message]]
===== The `funding_created` message
===== The funding_created message
* type: *34*
* fields:
@ -333,7 +333,7 @@ initiator, only needs to send the funding outpoint of the channel.
To conclude the responder sends the `funding_signed` message.
[[apdx_funding_signed_message]]
===== The `funding_signed` message
===== The funding_signed message
* type: *34*
* fields:
@ -356,7 +356,7 @@ Once the funding transaction has received enough confirmations, the
`funding_locked` is sent.
[[apdx_funding_locked_message]]
===== The `funding_locked` message
===== The funding_locked message
* type: *36*
* fields:
@ -372,7 +372,7 @@ message has been received, and sent can the channel being to be used.
Channel closing is a multi-step process. One node initiates by sending the `shutdown` message. The two channel partners then exchange a series of `channel_closing` messages to negotiate mutually acceptable fees for the closing transaction. The channel funder sends the first `closing_signed` message and the other side can accept by sending a `closing_signed` message with the same fee values.
[[apdx_shutdown_message]]
===== The `shutdown` message
===== The shutdown message
* type: *38*
* fields:
@ -381,7 +381,7 @@ Channel closing is a multi-step process. One node initiates by sending the `shut
** `len*byte` : `scriptpubkey`
[[apdx_closing_signed_message]]
===== The `closing_signed` message
===== The closing_signed message
* type: *39*
* fields:
@ -402,7 +402,7 @@ The `update_add_htlc` message allows either side to add a new HTLC to the
opposite commitment transaction.
[[apdx_update_add_htlc_message]]
===== The `update_add_htlc` message
===== The update_add_htlc message
* type: *128*
* fields:
@ -428,7 +428,7 @@ unique manner scoped to the channel.
The `update_fulfill_hltc` allow redemption (receipt) of an active HTLC.
[[apdx_update_fulfill_hltc_message]]
===== The `update_fulfill_hltc` message
===== The update_fulfill_hltc message
* type: *130*
* fields:
@ -443,7 +443,7 @@ provides the pre-image (which unlocks the HLTC) as well.
The `update_fail_htlc` is sent to remove an HTLC from a commitment transaction.
[[apdx_update_fail_htlc_message]]
===== The `update_fail_htlc` message
===== The update_fail_htlc message
* type: *131*
* fields:
@ -463,7 +463,7 @@ failure itself is a terminal one.
The `commitment_signed` message is used to stamp the creation of a new commitment transaction
[[apdx_commitment_signed_message]]
===== The `commitment_signed` message
===== The commitment_signed message
* type: *132*
* fields:
@ -480,7 +480,7 @@ present on the commitment transaction. This is due to the existence of the
The `revoke_and_ack` is sent to revoke a dated commitment:
[[apdx_revoke_and_ack_message]]
===== The `revoke_and_ack` message
===== The revoke_and_ack message
* type: *133*
* fields:
@ -499,7 +499,7 @@ The `update_fee` is sent to update the fee on the current commitment
transactions.
[[apdx_update_fee_message]]
===== The `update_fee` message
===== The update_fee message
* type: *134*
* fields:
@ -513,7 +513,7 @@ The `update_fail_malformed_htlc` is sent to remove a corrupted HTLC:
[[apdx_update_fail_malformed_htlc_message]]
===== The `update_fail_malformed_htlc` message
===== The update_fail_malformed_htlc message
* type: *135*
* fields:
@ -544,7 +544,7 @@ The `channel_announcement` is used to announce a new channel to the wider
network.
[[apdx_channel_announcement_message]]
===== The `channel_announcement` message
===== The channel_announcement message
* type: *256*
* fields:
@ -571,7 +571,7 @@ The `node_announcement` allows a node to announce/update it's vertex within the
greater Channel Graph.
[[apdx_node_announcement_message]]
===== The `node_announcement` message
===== The node_announcemen` message
* type: *257*
* fields:
@ -597,7 +597,7 @@ The `channel_update` message is sent to update the properties and policies of
an active channel edge within the Channel graph.
[[apdx_channel_update_message]]
===== The `channel_update` message
===== The channel_update message
* type: *258*
* fields:
@ -622,7 +622,7 @@ assemble the set of signatures required to produce a `channel_announcement`
message.
[[apdx_announce_signatures_message]]
===== The `announce_signatures` message
===== The announce_signatures message
* type: *259*
* fields:
@ -642,7 +642,7 @@ The `query_short_chan_ids` allows a peer to obtain the channel information
related to a series of short channel IDs.
[[apdx_query_short_chan_ids_message]]
===== The `query_short_chan_ids` message
===== The query_short_chan_ids message
* type: *261*
* fields:
@ -659,7 +659,7 @@ The `reply_short_chan_ids_end` message is sent after a peer finishes responding
to a prior `query_short_chan_ids` message.
[[apdx_reply_short_chan_ids_end_message]]
===== The `reply_short_chan_ids_end` message
===== The reply_short_chan_ids_end message
* type: *262*
* fields:
@ -673,7 +673,7 @@ The `query_channel_range` message allows a node to query for the set of channel
opened within a block range.
[[apdx_query_channel_range_message]]
===== The `query_channel_range` message
===== The query_channel_range message
* type: *263*
* fields:
@ -692,7 +692,7 @@ 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.
[[apdx_reply_channel_range_message]]
===== The `reply_channel_range` message
===== The reply_channel_range message
* type: *264*
* fields:
@ -713,7 +713,7 @@ The `gossip_timestamp_range` message allows a peer to start receiving new
kristen@oreilly.com
3 years ago