This commit changes outbound routing table sync to use gossip_queries
instead of the effectively deprecated initial_routing_sync feature.
This change removes setting of initial_routing_sync in our outbound Init
message. Instead we now call sync_routing_table after receiving an Init
message from a peer. If the peer supports gossip_queries and
should_request_full_sync returns true, we initiate a full gossip_queries
sync.
This change modifies gossip_queries methods in RoutingMessageHandler to
move the message instead of passing a reference. This allows the message
handler to be more efficient by not requiring a full copy of SCIDs
passed in messages.
Defines message handlers for gossip_queries messages in the RoutingMessageHandler
trait. The MessageSendEventsProvider supertrait is added to RoutingMessageHandler
so that the implementor can use SendMessageEvents to send messages to a
peer at the appropriate time.
The trait methods are stubbed in NetGraphMsgHandler which implements
RoutingMessageHandler and return a "not implemented" error.
This change enables initiating gossip queries with a peer using the
SendMessageEvent enum. Specifically we add an event for sending
query_channel_range to discover the existance of channels and an event
for sending query_short_channel_ids to request routing gossip messages
for a set of channels. These events are handled inside the process_events
method of PeerManager which sends the serialized message to the peer.
To enable gossip_queries message decoding, this commit implements the
wire module's Encoding trait for each message type. It also adds these
messages to the wire module's Message enum and the read function to
enable decoding of a buffer.
Support for the gossip_queries feature flag (bits 6/7) is added to the
Features struct. This feature is available in the Init and Node
contexts. The gossip_queries feature is not fully implemented so this
feature is disabled when sent to peers in the Init message.
This changes the LICENSE file and adds license headers to most files
to relicense under dual Apache-2.0 and MIT. This is helpful in that
we retain the patent grant issued under Apache-2.0-licensed work,
avoiding some sticky patent issues, while still allowing users who
are more comfortable with the simpler MIT license to use that.
See https://github.com/rust-bitcoin/rust-lightning/issues/659 for
relicensing statements from code authors.
Tests use sources of randomness to produce seeds, preimages, secrets,
and ephemeral data. However, this makes comparing logs between different
test runs difficult. Remove uses of random number generators and the
current time in favor of fixed values in order to make the test output
deterministic.
This is a response to splitting #585 into smaller components. This extraction should allow the subsequent creation of a trait for all message handling, thereby enabling more flexibility in the state machine, particularly for bindings.
We also update to use single idents when referencing the Deref=*
types since the automated code generator is pretty braindead.
This also moves some test utils out of peer_handler.rs and into
util::test_utils to standardize things a little bit, which we need
to concretize the PeerHandler types used in testing.
This is a response to splitting #585 into smaller components. This extraction will permit a future extraction of all message handling into a separate method, and then later even into a separate trait that will be accessible through language bindings.
This caused a bunch of cascading changes, including
passing loggers down to Channels in function calls
rather than having each Channel have a pointer to the
ChannelManager's Logger (which was a circular reference).
Other structs that the Channel had passed its Logger to also
had their loggers removed. Other newly unused Loggers were
also removed, especially when keeping them would've caused
a bunch of extra test changes to be necessary, e.g. with
the ChainWatchInterfaceUtil's Logger.
This simplifies channelmonitor quite nicely (as expected) as we
never have to be concerned with learning data in a DataLossProtect
which is require for us to claim our funds from the latest remote
commitment transaction.
This adds the ability to check for static_remotekey in appropriate
feature contexts and prints it at connect time. It is still
considered unknown for the purposes of requires_unknown_bits() as
we don't yet implement it.
Features for a given context are duplicated throughout the features
module. Use a macro for defining a Context and the applicable features
such that features only need to be defined for a Context in one place.
The Context provides bitmasks for selecting known and unknown feature
flags.
BOLT 1 and BOLT 9 refer to features as "known" if a peer understands
them. They also use the term "supported" to mean either optional or
required.
Update the features module to use similar terminology.
- Define contexts in terms of required and optional features rather than
just supported features
- Define known features as those that are optional or required
- Rename supported() constructor to known()
For completeness, clear_optional_bit for each feature is now called
clear_bits and clears both optional and required bits.
The initial_routing_sync feature is set by peer_handler whenever a full
sync of the network graph is desired. It is not explicitly set when
creating features with InitFeatures::supported().
An upcoming refactor will change supported() to known(), which will
return all features known by the implementation. Thus, the
initial_routing_sync flag will need to be set by default. This commit
makes the behavior change ahead of the refactor.
This is a somewhat-obvious oversight in the capabilities of
rust-lightning, though not a particularly interesting one until we
start relying on node_features (eg for variable-length-onions and
Base AMP).
Sadly its not fully automated as we don't really want to store the
list of available addresses from the user. However, with a simple
call to ChannelManager::broadcast_node_announcement and a sensible
peer_handler, the announcement is made.
In testing, due to other patches, I managed to flood the send queue
with messages and cause us not to be able to send pings, thus
getting a peer disconnected for ping timeout. To my surprise, this
also force-closed all of my channels with that peeer.
Obviously a ping timeout does not indicate that no future connection
with said peer will be possible, and we shouldn't be force-closing
channels as a result.
This also logs when a peer is disconnected to ping timeout to make
debug easier.
The way PeerHandler was written, it was supposed to remove from
self.peers iff the API docs indicate that disconnect_event should
NOT be called (and otherwise rely on disconnect_event to do so).
Sadly, the implementation was way out of whack with reality - in
the implementation, essentially anywhere where PeerHandler
originated the disconnection, the peer was removed and no
disconnect_event was expected. The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.
We opt to change the docs, mostly, as well as clean up the
ping/pong handling somewhat and rename a few functions to clarify
what they actually do.
PeerManager determines whether the initial_routing_sync feature bit
should be set when sending Init messages to peers. Move this to the
Router as it is better able to determine if a full sync is needed.
Create a MessageType abstraction and use it throughout the wire module's
external interfaces. Include an is_even method for clients to determine
how to handle unknown messages.
Lightning messages are identified by a 2-byte type when encoded on the
wire. Rather than expecting callers to know message types when sending
messages to peers, have each message implement a trait defining the
message type. Provide an interface for reading and writing messages
as well as a Message enum for matching the decoded message, including
unknown messages.
Additional changes:
* Update fuzz crate to match ChannelManager's new API
* Update lightning-net-tokio library to match ChannelManager's new ChannelMonitor Deref API
* Update tests to match ChannelManager's new ChannelMonitor Deref API
Accessing a struct through an std::syn::MutexGuard using implicit
dereferencing can confuse the borrow checker. This situation arises when
obtaining mutable references to more than one field of the struct, which
is normally allowed.
https://doc.rust-lang.org/nomicon/borrow-splitting.html
However, when using implicit dereferencing, a mutable reference to the
the entire struct is taken. Thus, attempting to access another field in
this manner will lead to a compilation error.
https://doc.rust-lang.org/error-index.html#E0499
A simple way to avoid this is to first obtain a mutable reference to the
struct using explicit dereferencing.
