TestRouter checks route and scoring expectations before delegating to
the standalone find_route function. Refactor it to wrap DefaultRouter
and delegate to it instead. This allows TestRouter to implement
create_blinded_payment_paths by delegating to DefaultRouter.
OnionMessenger is needed to write functional tests for ChannelManager's
OffersMessageHandler implementation. Also adds a TestMessageRouter,
which simply wraps DefaultMessageRouter for now.
The ChaCha20-based EntropySource implementation is duplicated within the
sign module. Refactor those into a RandomBytes implementation so that it
may be reused both there. Also useful as a standalone EntropySource
implementation for tests where an independent EntropySource is needed to
ensure that backwards-compatibility testing is not broken.
When testing OnionMessenger in functional tests, it would be useful to
examine the contents of an OnionMessage response. Expose the standalone
peel_onion_message on OnionMessenger to facilitate this.
Previously, we were setting the final blinded hop's CLTV expiry height to
best_block_height + total_blinded_path_cltv_delta + shadow_cltv_offset. This is
incorrect, it should instead be set to best_block_height + shadow_cltv_offset
only -- it doesn't make sense to include the delta for the other blinded hops
in the final hop's expiry.
The reason this too-high final cltv value didn't cause test failures previously
is because of a 2nd bug that is fixed in an upcoming commit where the sender
adds the shadow offset twice to the total path CLTV expiry. This 2nd offset
meant that intermediate nodes had some buffer CLTV to subtract their delta from
while still (usually) have enough leftover to meet the expiry in the final hop's
onion.
When we originally added the `onion_message` module, there weren't
a lot of public items in it, and it didn't make a lot of sense to
export the whole sub-module structure publicly. So, instead, we
exported the public items via re-exports directly in the
`onion_message` top-level module. However, as time went on, more
and more things entered the module, which left the top-level module
rather cluttered.
Worse, in 0.0.119, we exposed
`onion_message::messenger::SendSuccess` via the return type of
`send_message`, but forgot to re-export the enum itself, making
it impossible to actually use from external code.
Here we address both issues and simply replace the re-export with
the underlying sub-module structure.
In 67659677d4 we relaxed the bounds
set on `UtxoLookup` to enable those using `RoutingMessageHandler`
other than `P2PGossipSync` to use `UtxoLookup`. Sadly, because this
requires having a concrete `PeerManager` type which does *not* use
`UtxoLookup` in the `RoutingMessageHandler` type, this broke users
who were directly using `P2PGossipSync`.
We could split `UtxoLookup` into two, with different bounds, for
the two use-cases, but instead here we simply switch to storing a
reference to the `PeerManager` via a `dyn Fn` which allows us to
wake the `PeerManager` when we need to.
Fixes#2813
The prior name seems to reference onion decode errors specifically, when in
fact the error contents are generic failure codes for any error that occurs
during HTLC receipt.
935a716cc6 added new wrappers for the
various channel keys, including a payment_key. However, the
`payment_key` has been unused in lightning since the introduction
(and broad requiring) of the `static_remotekey` feature.
Thus, we simply remove it (and an incredibly stale TODO) here.
