From 561e1bc23394cbbc9d4002cbb397025eebad2a10 Mon Sep 17 00:00:00 2001 From: "kristen@oreilly.com" Date: Fri, 15 Oct 2021 06:48:26 -0700 Subject: [PATCH] Edited appendix_protocol_messages.asciidoc with Atlas code editor --- appendix_protocol_messages.asciidoc | 54 ++++++++++++++--------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/appendix_protocol_messages.asciidoc b/appendix_protocol_messages.asciidoc index 8b8d9a5..b5c4bf7 100644 --- a/appendix_protocol_messages.asciidoc +++ b/appendix_protocol_messages.asciidoc @@ -100,7 +100,7 @@ has been sent by both parties. 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 <>. [[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 incoming gossip messages on the network. [[apdx_gossip_timestamp_range_message]] -===== The `gossip_timestamp_range` message +===== The gossip_timestamp_range message * type: *265* * fields: