Using compact blinded paths isn't always necessary or desirable. For
instance, reply paths are communicated via onion messages where space
isn't a premium unlike in QR codes. Additionally, long-lived paths could
become invalid if the channel associated with the SCID is closed.
Refactor MessageRouter::create_blinded_paths into two methods: one for
compact blinded paths and one for normal blinded paths.
Instead of passing Vec<PublicKey> to MessageRouter::crate_blinded_path,
pass Vec<ForwardNode>. This way callers can include a short_channel_id
for a more compact BlindedPath encoding.
When sending an onion message to a blinded path, the short channel id
between hops isn't need in each hop's encrypted_payload since it is not
a payment. However, using the short channel id instead of the node id
gives a more compact representation. Update BlindedPath::new_for_message
to allow for this.
When we added the additional deust exposure checks in
702196819e6445048b803574fcacef77d5ce8c9c we added several
additional feerate fetches which broke the `full_stack_target`
change-detection test.
This updates the hard-coded test to support the new feerate fetches
and also includes a comment on `FeeEstimator` to indicate that
users really need to be caching feerates as otherwise they'll slow
us down.
MonitorUpdateId was an opaque abstraction for id's generated by
UpdateOrigin:Offchain and UpdateOrigin::ChainSync monitor updates.
It was mainly needed to map calls made to
ChainMonitor::channel_monitor_updated. We no longer track
UpdateOrigin::ChainSync MonitorUpdates and can directly use
ChannelMonitor::get_latest_update_id() for tracking
UpdateOrigin::Offchain monitor updates.
In this commit i added additional parameter `error_message` to
`force_close_sending_error`. This parameter will allow users to
configure error message and send to peers during the force closing
of channel.I have also updated the tests for this updated function.
Archives fully resolved channel monitors by adding them to a backup
location and removing them from the primary storage & the monitor set.
This is useful for pruning fully resolved monitors from the monitor
set and primary storage so they are not reloaded on every new new
block connection.
We also add a new function, `archive_persisted_channel` to the
`Persist` trait that writes the monitor to an archive storage and
removes it from the primary storage.
When forwarding onion messages, the next node may be represented by a
short channel id instead of a node id. Parameterize OnionMessenger with
a NodeIdLookUp trait to find which node is the next hop. Implement the
trait for ChannelManager for forwarding to channel counterparties.
Also use this trait when advancing a blinded path one hop when the
sender is the introduction node.
Allow using either a node id or a directed short channel id in blinded
paths. This allows for a more compact representation of blinded paths,
which is advantageous for reducing offer QR code size.
Follow-up commits will implement handling the directed short channel id
case in OnionMessenger as it requires resolving the introduction node in
MessageRouter.
This would help distinguish different types of errors when deserialzing
a channel manager. InvalidValue was used previously but this could be
because it is an old serialization format, whereas DangerousValue is a
lot more clear on why the deserialization failed.
SignError allows implementors of SignFunction to return a custom error
type. Drop this as an unconstrained type causes problems with bindings
and isn't useful unless the caller can take some sort of action based on
different errors.
Replace the Fn trait bound on signing methods with a dedicated trait
since Fn is not supported in bindings. Implement the trait for Fn so
that closures can still be used in Rust.
.. returning `PeerDetails` rather than tuples of peer-associated values.
Previously, we wouldn't offer any way to retrieve the features a
peer provided in their `Init` message.
Here, we allow to retrieve them via a new `PeerDetails` struct,
side-by-side with `SocketAddress`es and a bool indicating the direction
of the peer connection.
https://github.com/tkaitchuck/aHash/pull/196 bumped the MSRV of
`ahash` in a patch release, which makes it rather difficult for us
to have it as a dependency.
Further, it seems that `ahash` hasn't been particularly robust in
the past, notably
https://github.com/tkaitchuck/aHash/issues/163 and
https://github.com/tkaitchuck/aHash/issues/166.
Luckily, `core` provides `SipHasher` even on no-std (sadly its
SipHash-2-4 unlike the SipHash-1-3 used by the `DefaultHasher` in
`std`). Thus, we drop the `ahash` dependency entirely here and
simply wrap `SipHasher` for our `no-std` HashMaps.
The whole point of full_stack_target is to just expose our entire
API to the fuzzer and see what happens. Sadly, we're really only
exposing a small subset of our API. This improves that by exposing
a handful of other assorted methods from ChannelManager and
PeerManager.
This exposes details around pending HTLCs in ChannelDetails. The state
of the HTLC in the state machine is also included, so it can be
determined which protocol message the HTLC is waiting for to advance.
