Expand description
Wire messages, traits representing wire message handlers, and a few error types live here.
For a normal node you probably don’t need to use anything here, however, if you wish to split a node into an internet-facing route/message socket handling daemon and a separate daemon (or server entirely) which handles only channel-related messages you may wish to implement ChannelMessageHandler yourself and use it to re-serialize messages and pass them across daemons/servers.
Note that if you go with such an architecture (instead of passing raw socket events to a non-internet-facing system) you trust the frontend internet-facing system to not lie about the source node_id of the message, however this does allow you to significantly reduce bandwidth between the systems as routing messages can represent a significant chunk of bandwidth usage (especially for non-channel-publicly-announcing nodes). As an alternate design which avoids this issue, if you have sufficient bidirectional bandwidth between your systems, you may send raw socket events into your non-internet-facing system and then send routing events back to track the network on the less-secure system.
Structs
An accept_channel message to be sent or received from a peer
An announcement_signatures message to be sent or received from a peer
A channel_announcement message to be sent or received from a peer
A channel_reestablish message to be sent or received from a peer
A channel_update message to be sent or received from a peer
A closing_signed message to be sent or received from a peer
The minimum and maximum fees which the sender is willing to place on the closing transaction.
This is provided in ClosingSigned by both sides to indicate the fee range they are willing
to use.
A commitment_signed message to be sent or received from a peer
Struct used to return values from revoke_and_ack messages, containing a bunch of commitment transaction updates if they were pending.
Proof that the sender knows the per-commitment secret of the previous commitment transaction. This is used to convince the recipient that the channel is at a certain commitment number even if they lost that data due to a local failure. Of course, the peer may lie and even later commitments may have been revoked.
An error message to be sent or received from a peer
A funding_created message to be sent or received from a peer
A funding_locked message to be sent or received from a peer
A funding_signed message to be sent or received from a peer
A gossip_timestamp_filter message is used by a node to request gossip relay for messages in the requested time range when the gossip_queries feature has been negotiated.
An init message to be sent or received from a peer
An Err type for failure to process messages.
A node_announcement message to be sent or received from a peer
An open_channel message to be sent or received from a peer
A ping message to be sent or received from a peer
A pong message to be sent or received from a peer
A query_channel_range message is used to query a peer for channel UTXOs in a range of blocks. The recipient of a query makes a best effort to reply to the query using one or more reply_channel_range messages.
A query_short_channel_ids message is used to query a peer for routing gossip messages related to one or more short_channel_ids. The query recipient will reply with the latest, if available, channel_announcement, channel_update and node_announcement messages it maintains for the requested short_channel_ids followed by a reply_short_channel_ids_end message. The short_channel_ids sent in this query are encoded. We only support encoding_type=0 uncompressed serialization and do not support encoding_type=1 zlib serialization.
A reply_channel_range message is a reply to a query_channel_range message. Multiple reply_channel_range messages can be sent in reply to a single query_channel_range message. The query recipient makes a best effort to respond based on their local network view which may not be a perfect view of the network. The short_channel_ids in the reply are encoded. We only support encoding_type=0 uncompressed serialization and do not support encoding_type=1 zlib serialization.
A reply_short_channel_ids_end message is sent as a reply to a query_short_channel_ids message. The query recipient makes a best effort to respond based on their local network view which may not be a perfect view of the network.
A revoke_and_ack message to be sent or received from a peer
A shutdown message to be sent or received from a peer
The unsigned part of a channel_announcement
The unsigned part of a channel_update
The unsigned part of a node_announcement
An update_add_htlc message to be sent or received from a peer
An update_fail_htlc message to be sent or received from a peer
An update_fail_malformed_htlc message to be sent or received from a peer
An update_fee message to be sent or received from a peer
An update_fulfill_htlc message to be sent or received from a peer
A warning message to be sent or received from a peer
Enums
An error in decoding a message or struct.
Used to put an error message in a LightningError
An address which can be used to connect to a remote peer
Messages could have optional fields to use with extended features
As we wish to serialize these differently from Option
Traits
A trait to describe an object which can receive channel messages.
A trait to describe an object which can receive routing messages.