Modify NetGraphMsgHandler::handle_query_channel_range to always use
first_blocknum=0 in replies. This is spec compliant after changes to
make sequence completion explicity using sync_complete.
Modifies NetGraphMsgHandler::handle_query_channel_range to use a constant
max value in replies. Modifies tests to generate 8000 channels instead
of making this value configurable.
Initial implementation of handling query_channel_range messages in
NetGraphMsgHandler. Enqueues a sequence of reply message in the pending
message events buffer.
Creates a MessageSendEvent for sending a reply_channel_range message.
This event will be fired when handling inbound query_channel_range
messages in the NetGraphMessageHandler.
We could have possibly constructed a slightly inconsistent
path: since we reduce value being transferred all the way, we
could have violated htlc_minimum_msat on some channels
we already passed (assuming dest->source direction). Here,
we recompute the fees again, so that if that's the case, we
match the currently underpaid htlc_minimum_msat with fees.
If the ChannelManager never receives any blocks, it'll return a default blockhash
on deserialization. It's preferable for this to be an Option instead.
Refactor synchronize_listeners by pulling out a function returning the
validated block header of a BlockSource's best chain tip. This is needed
when a node is started from scratch and has no listeners to sync.
The implementation of chain::Listen for ChannelMonitor required using a
RefCell since its block_connected method required a mutable borrow. This
is no longer the case since ChannelMonitor now uses interior mutability
via a Mutex. So the RefCell is no longer needed.
Now that ChannelMonitor uses an internal Mutex to support interior
mutability, ChainMonitor can use a RwLock to manage its ChannelMonitor
map. This allows parallelization of update_channel operations since an
exclusive lock only needs to be held when adding to the map in
watch_channel.
ChainMonitor accesses a set of ChannelMonitors behind a single Mutex.
As a result, update_channel operations cannot be parallelized. It also
requires using a RefCell around a ChannelMonitor when implementing
chain::Listen.
Moving the Mutex into ChannelMonitor avoids these problems and aligns it
better with other interfaces. Note, however, that get_funding_txo and
get_outputs_to_watch now clone the underlying data rather than returning
references.
We currently "support" not having a router or channel in memory by
forcing users to implement the same, but its trivial to provide our
own dummy implementations.
This will switch to use the clang/C WASM ABI instead of the
wasm_bindgen WASM ABI as of rustc 1.51 (or nightly since [1]),
allowing us to link C and Rust code in a single wasm binary.
[1] https://github.com/rust-lang/rust/pull/79998
For ChannelManager, at least, we have two separate functions called
block_connected, one in the Listen trait, one in the struct, we
need to be explicit with which one we're trying to call.
