Module msgs
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 to or received from a peer. - An accept_channel2 message to be sent by or received from the channel accepter.
- An
announcement_signatures
message to be sent to or received from a peer. - A
channel_announcement
message to be sent to or received from a peer. - A
channel_ready
message to be sent to or received from a peer. - A
channel_reestablish
message to be sent to or received from a peer. - A
channel_update
message to be sent to or received from a peer. - A
closing_signed
message to be sent to or received from a peer. - The minimum and maximum fees which the sender is willing to place on the closing transaction.
- A
commitment_signed
message to be sent to or received from a peer. - Struct used to return values from
RevokeAndACK
messages, containing a bunch of commitment transaction updates if they were pending. - An
error
message to be sent to or received from a peer. - A
funding_created
message to be sent to or received from a peer. - A
funding_signed
message to be sent to 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 thegossip_queries
feature has been negotiated. - An
init
message to be sent to or received from a peer. - An Err type for failure to process messages.
- A
node_announcement
message to be sent to or received from a peer. - An onion message to be sent to or received from a peer.
- An
open_channel
message to be sent to or received from a peer. - An open_channel2 message to be sent by or received from the channel initiator.
- A
ping
message to be sent to or received from a peer. - A
pong
message to be sent to 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 moreReplyChannelRange
messages. - A
query_short_channel_ids
message is used to query a peer for routing gossip messages related to one or moreshort_channel_id
s. - A
reply_channel_range
message is a reply to aQueryChannelRange
message. - A
reply_short_channel_ids_end
message is sent as a reply to a 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 to or received from a peer. - A
shutdown
message to be sent to or received from a peer. - A tx_abort message which signals the cancellation of an in-progress transaction negotiation.
- A tx_ack_rbf message which acknowledges replacement of the transaction after it’s been completed.
- A tx_add_input message for adding an input during interactive transaction construction
- A tx_add_output message for adding an output during interactive transaction construction.
- A tx_complete message signalling the conclusion of a peer’s transaction contributions during interactive transaction construction.
- A tx_init_rbf message which initiates a replacement of the transaction after it’s been completed.
- A tx_remove_input message for removing an input during interactive transaction construction.
- A tx_remove_output message for removing an output during interactive transaction construction.
- A tx_signatures message containing the sender’s signatures for a transaction constructed with interactive transaction construction.
- The unsigned part of a
channel_announcement
message. - The unsigned part of a
channel_update
message. - The unsigned part of a
node_announcement
message. - An
update_add_htlc
message to be sent to or received from a peer. - An
update_fail_htlc
message to be sent to or received from a peer. - An
update_fail_malformed_htlc
message to be sent to or received from a peer. - An
update_fee
message to be sent to or received from a peer - An
update_fulfill_htlc
message to be sent to or received from a peer. - A
warning
message to be sent to 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.
SocketAddress
error variants- Represents the set of gossip messages that require a signature from a node’s identity key.
Traits§
- A trait to describe an object which can receive channel messages.
- A handler for received
OnionMessage
s and for providing generated ones to send. - A trait to describe an object which can receive routing messages.
Functions§
- Parses an OnionV3 host and port into a
SocketAddress::OnionV3
.