The new `MonitorUpdatingPersister` has a few redundant type bounds
(re-specified on functions after having been specified on the
struct itself), which we remove here.
Further, it requires a `Deref<FeeEstimator>` which is `Clone`able.
This is generally fine in rust, but annoying in bindings, so we
simply elide it in favor if a `&Deref<FeeEstimator>`.
While removing the `balance_msat` field absolutely makes sense -
it is, at best, confusing - we really need a solid replacement for
it before we can do so. While one such replacement is in progress,
it is not complete and we'd like to not block our current release
on its completion.
This reverts commit ef5be580f5.
When a `ChannelMonitorUpdate` fails to apply, it generally means
we cannot reach our storage backend. This, in general, is a
critical issue, but is often only a transient issue.
Sadly, users see the failure variant and return it on any I/O
error, resulting in channel force-closures due to transient issues.
Users don't generally expect force-closes in most cases, and
luckily with async `ChannelMonitorUpdate`s supported we don't take
any risk by "delaying" the `ChannelMonitorUpdate` indefinitely.
Thus, here we drop the `PermanentFailure` variant entirely, making
all failures instead be "the update is in progress, but won't ever
complete", which is equivalent if we do not close the channel
automatically.
When sending preflight probes, we want to exclude last hops that are
possibly announced. To this end, we here include a new field in
`RouteHop` that will be `true` when we either def. know the hop to be
announced, or, if there exist public channels between the hop's
counterparties that this hop might refer to (i.e., be an alias for).
In the `chanmon_consistency` fuzz, we currently "persist" the
`ChannelManager` on each loop iteration. With the new logic in the
past few commits to reduce the frequency of `ChannelManager`
persistences, this behavior now leaves a gap in our test coverage -
missing persistence notifications.
In order to cath (common-case) persistence misses, we update the
`chanmon_consistency` fuzzer to no longer persist the
`ChannelManager` unless the waker was woken and signaled to
persist, possibly reloading with a previous `ChannelManager` if we
were not signaled.
When reloading nodes A or C, the chanmon_consistency fuzzer
currently calls `get_and_clear_pending_msg_events` on the node,
potentially causing additional `ChannelMonitor` or `ChannelManager`
updates, just to check that no unexpected messages are generated.
There's not much reason to do so, the fuzzer could always swap for
a different command to call the same method, and the additional
checking requires some weird monitor persistence introspection.
Here we simplify the fuzzer by simply removing this logic.
BOLT 12 messages need to be signed in the following scenarios:
- constructing an InvoiceRequest after scanning an Offer,
- constructing an Invoice after scanning a Refund, and
- constructing an Invoice when handling an InvoiceRequest.
Extend the NodeSigner trait to support signing BOLT 12 invoices such
that it can be used in the latter contexts. The method could be used
in an OffersMessageHandler.
The function used to sign BOLT 12 messages only takes a message digest.
This doesn't allow signers to independently verify the message before
signing nor does it allow them to derive the necessary signing keys, if
needed.
Introduce a TaggedHash wrapper for a message digest, which each unsigned
BOLT 12 message type constructs upon initialization. Change the signing
function to take AsRef<TaggedHash>, which each unsigned type implements.
This allows the signing function to take any unsigned message and obtain
its tagged hash.
The ChannelMonitor::get_claimable_balances method provides a more
straightforward approach to the balance of a channel, which satisfies
most use cases. The computation of AvailableBalances::balance_msat is
complex and originally had a different purpose that is not applicable
anymore.
To support route blinding, we want to split OnionHopData into two separate
structs, one for inbound onions and one for outbound onions. This is because
blinded payloads change the fields present in the onion hop data struct based
on whether we're sending vs receiving (outbound onions include encrypted blobs,
inbound onions can decrypt those blobs and contain the decrypted fields
themselves).
In upcoming commits, we'll add variants for blinded payloads to the new
InboundPayload enum.
Given we build `InFlightHtlcs` per route-fetch call, there's no
reason to pass them out by reference rather than simply giving the
user the full object. This also allows them to tweak the in-flight
set before fetching a route.
Now that we support channels with anchor outputs, we add a new
ConfirmationTarget variant that, for now, will only apply to such
channels. This new variant should target estimating the minimum feerate
required to be accepted into most node mempools across the network.
This commit makes use of the added enum to calculate the dust
exposure threshold based on the current fee rate. This also updates
tests to ensure it works as intended.
This ensures freshly initialized nodes can proceed to create unexpired
invoices without a call to `best_block_updated`, since an invoice's
expiration delta is applied to `highest_seen_timestamp`.
When generating onion message fuzz data, the same public key was used
for each node. However, the code now advances the blinded path if the
sender is the introduction node. Use different node secrets for each
node to avoid this. Note that the exercised handling code is for the
sender's immediate peer.
Add a trait for finding routes for onion messages and parameterize
OnionMessenger with it. This allows OnionMessenger to reply to messages
that it handles via one of its handlers (e.g., OffersMessageHandler).
Add a trait for handling BOLT 12 Offers messages to OnionMessenger and a
skeleton implementation of it for ChannelManager. This allows users to
either provide their own custom handling Offers messages or rely on a
version provided by LDK using stateless verification.
Now that the `get_available_balances` min/max bounds are exact, we
can stop doing all the explicit checks in `send_htlc` entirely,
instead comparing against the `get_available_balances` bounds and
failing if the amount is out of those bounds.
This breaks support for sending amounts below the dust limit if
there is some amount of dust exposure remaining before we hit our
cap, however we will no longer generate such routes anyway.
Now that the value available to send is expected to match the
success or failure of sending exactly, we should assert this in the
`chanmon_consistency` fuzzer.
In the next commit we'll actually rip the checks out of `send_htlc`
which will make this a somewhat less useful test, however fuzzing
on this specific commit can help to reveal bugs.
In the coming commits, in order to ensure all routes we generate
are usable, we'll start calculating the next-HTLC minimum for our
channels and using it in the router. Here we set this up by adding
an always-0 field for it in `ChannelDetails` and use it when
routing.
This was a fairly old introduction to the spec to allow nodes to indicate
to their peers what chains they are interested in (i.e. will open channels
and gossip for).
We don't do any of the handling of this message in this commit and leave
that to the very next commit, so the behaviour is effectively the same
(ignore networks preference).
