Module lightning::ln::msgs [−][src]
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
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
Enums
An error in decoding a message or struct.
Used to put an error message in a LightningError
The information we received from a peer along the route of a payment we originated. This is returned by ChannelMessageHandler::handle_update_fail_htlc to be passed into RoutingMessageHandler::handle_htlc_fail_channel_update to update our network map.
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.