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.
The bindings generator struggles a bit with the references in enum
variant fields in `CandidateRouteHop`. While we could probably fix
this, its much eaiser (and less risky) to inline the enum variant
fields from `CandidateRouteHop` into structs. This also lets us
make some of the fields non-public, which seems better at least for
the opaque `hint_idx` in the blinded paths.
The Router trait is used to find a Route for paying a node. Expand the
interface with a create_blinded_payment paths method for creating such
paths to a recipient node.
Provide an implementation for DefaultRouter that creates two-hop
blinded paths where the recipient's peers serve as the introduction
nodes.
ChannelManager is parameterized by a Router in order to find routes when
sending and retrying payments. For the offers flow, it needs to be able
to construct blinded paths (e.g., in the offer and in reply paths).
Instead of adding yet another parameter to ChannelManager, require that
any Router also implements MessageRouter. Implement this for
DefaultRouter by delegating to a DefaultMessageRouter.
Previously, we used to cleanup monitor updates at both consolidation
threshold and new block connects. With this change we will only
cleanup when our consolidation criteria is met. Also, we remove
monitor read from cleanup logic, in case of update consolidation.
Note: In case of channel-closing monitor update, we still need to
read the old monitor before persisting the new one in order to
determine the cleanup range.
Rather than relying on fetching the current time during
routefinding, here we introduce a new trait method to `ScoreUpdate`
to do so. This largely mirrors what we do with the `NetworkGraph`,
and allows us to take on much more expensive operations (floating
point exponentiation) in our decaying.
In the coming commits, we'll stop relying on fetching the time
during routefetching, preferring to decay score data in the
background instead.
The first step towards this - passing the current time through into
the scorer when updating.
This avoids bloating `CandidateRouteHop` with a full 33-byte
node_id (and avoids repeated public key serialization when we do
multiple pathfinding passes).
`TestRouter` tries to make scoring calls that mimic what an actual
router would do, but the changes in f0ecc3ec73
failed to make scoring calls for private hints or if we take a
public hop for the last hop.
This fixes those regressions, though no tests currently depend on
this behavior.
Rather than calling `CandidateRouteHop::FirstHop::node_id` just
`node_id`, we should call it `payer_node_id` to provide more
context.
We also take this opportunity to make it a reference, avoiding
bloating `CandidateRouteHop`.
Short channel "ID"s are not globally unique when they come from a
BOLT 11 route hint or a first hop (which can be an outbound SCID
alias). In those cases, its rather confusing that we have a
`short_channel_id` method which mixes them all together, and even
more confusing that we have a `CandidateHopId` which is not, in
fact returning a unique identifier.
In our routing logic this is mostly fine - the cost of a collision
isn't super high and we should still do just fine finding a route,
however the same can't be true for downstream users, as they may or
may not rely on the apparent guarantees.
Thus, here, we privatise the SCID and id accessors.
The VLS signer has a desire to see preimages for resolved forwarded
HTLCs when they are first claimed by us, even if that claim was for
the inbound edge (where claiming strictly increases our balance).
Luckily, providing that information is rather trivial, which we do
here.
Fixes#2356
There are various place where we log something related to a channel
but fail to fill in the channel's counterparty information. This is
somewhat surprising, given channel counterparty information is
always known, but simply is sometimes not readily accessible to LDK
when a log is printed.
973636bd2a introduced a new `HashMap`
in the `TestLogger` but then did lookups by iterating the entire
map. This fixes that, and also takes this opportunity to stop
allocating new `String`s for the module to store each log entry in
the `TestLogger`
Include optional peer and channel ids to logger::Record. This will be
used by wrappers around Logger in order to provide more context (e.g.,
the peer that sent a message, the channel an operation is pertaining to,
etc.). Implementations of Logger can include this as metadata to aid in
searching logs.
While its all constant arithmetic to calculate the shift, which
LLVM likely optimizes out for us, there's no reason to do it four
times, which just makes the code harder to read.
To separate out the logic in the `sign` module, which will start to be
convoluted with multiple signer types, we're splitting out each signer
type into its own submodule, following the taproot.rs example from a
previous commit.
Previously, SignerProvider was not laid out to support multiple signer
types. However, with the distinction between ECDSA and Taproot signers,
we now need to account for SignerProviders needing to support both.
This approach does mean that if ever we introduced another signer type
in the future, all implementers of SignerProvider would need to add it
as an associated type, and would also need to write a set of dummy
implementations for any Signer trait they do not wish to support.
For the time being, the TaprootSigner associated type is cfg-gated.
Currently all channel keys and their basepoints exist uniformly as
`PublicKey` type, which not only makes in harder for a developer to
distinguish those entities, but also does not engage the language
type system to check if the correct key is being used in any
particular function.
Having struct wrappers around keys also enables more nuanced
semantics allowing to express Lightning Protocol rules in language.
For example, the code allows to derive `HtlcKey` from
`HtlcBasepoint` and not from `PaymentBasepoint`.
This change is transparent for channel monitors that will use the
internal public key of a wrapper.
Payment, DelayedPayment, HTLC and Revocation basepoints and their
derived keys are now wrapped into a specific struct that make it
distinguishable for the Rust type system. Functions that require a
specific key or basepoint should not use generic Public Key, but
require a specific key wrapper struct to engage Rust type
verification system and make it more clear for developers which
key is used.
In other languages (Java and C#, notably), overriding `Eq` without
overriding `Hash` can lead to surprising or broken behavior. Even
in Rust, its usually the case that you actually want both. Here we
add missing `Hash` derivations for P2P messages, to at least
address the first pile of warnings the C# compiler dumps.
Quite a while ago we added checks for the total current dust
exposure on a channel to explicitly limit dust inflation attacks.
When we did this, we kept the existing upper bound on the channel's
feerate in place. However, these two things are redundant - the
point of the feerate upper bound is to prevent dust inflation, and
it does so in a crude way that can cause spurious force-closures.
Here we simply drop the upper bound entirely, relying on the dust
inflation limit to prevent dust inflation instead.
