Custom message handlers may need to set feature bits that are unknown to
LDK. Provide Features::set_required_custom_bit and
Features::set_optional_custom_bit to allow for this.
Each message handler provides which features it supports. A custom
message handler may support unknown features. Therefore, these features
should be checked against instead of the features known by LDK.
Additionally, fail the connection if the peer requires features unknown
to the handler. The peer should already fail the connection in the
latter case.
The purpose of this payload is to ensure we retry restored packages on a
`ChannelMonitor` that has upgraded from a version that previously did
not have such retry logic. We can verify this works by checking whether
a restored package has a `height_timer` of `None` upon deserializing the
monitor payload.
In the previous commit, we added a helper that constructs blocks
whenever tests demand blocks be connected. This helper moved towards
having all connected blocks have a version of 0x2000_0000 (also known as
NO_SOFT_FORK_SIGNALLING). However, previously, it was possible for some
blocks to be connected with a slighty different version: 0x0200_0000,
resulting in different block hashes.
This block hash divergence prompted a failure in this test when
`ConnectStyle::HighlyRedundantTransactionsFirstSkippingBlocks` is used
for `nodes[0]`, since this block connection style reconfirms
transactions redundantly and the serialized monitor payload kept a
reference to the hash of the block with version 0x0200_0000, when it
should be expecting one with version 0x2000_0000.
`rust-bitcoin v0.30.0` introduces concrete variants for data members of
block `Header`s. To avoid having to update these across every use, we
introduce new helpers to create dummy blocks and headers, such that the
update process is a bit more straight-forward.
This makes much clearer at sites generating such events that they
will be lost on restart, to reduce risk of bugs creeping in due to
lost monitor updates.
In d4810087c1 we added logic to apply `ChannelMonitorUpdate`s which
were a part of a channel closure async via a background queue to
address some startup issues. When we did that we persisted those
updates to ensure we replayed them when starting next time.
However, there was no reason to - if we persisted and then
restarted even without those monitor updates we'd find a monitor
without a channel, which we'd tell to broadcast the latest
commitment transaction to force-close.
Since adding that logic, we've used the same background queue for
several purposes.
This was previously broken and would result in an invalid HMAC error, because
we had a hardcoded assumption that OM hop data would always be of size 1300.
When checking features, rather than checking against which features LDK
knows about, it is more useful to check against a peer's features. Add
Features::requires_unknown_bits_from such that the given features are
used instead.
CustomMessageHandler implementations may need to advertise support for
features. Add methods to CustomMessageHandler to provide these and
combine them with features from other message handlers.
The `lightning-custom-message` crate will need access to Features::or in
order combine features of a composite handler. Expose this via a
core::ops::BitOr implementation.
This is the first of a set of PRs to enable the experimental dual-funded
channels feature using interactive transaction construction. This allows
both the channel initiator and channel acceptor to contribute funds
towards the channel.
The `payment_hash` field in `PaymentPathSuccessful` is always
`Some` as long as the pening payment tracker has a `payment_hash`,
which is true for all `Pending` payments as well as all `Fulfilled`
payments starting with the commit which added
`PaymentPathSuccessful` -
3b5c370b404e2f5a8f3c35093b97406f149a9340c177c05252574083d68df0da.
It's a bit confusing when we see only "Peer sent a garbage
channel_reestablish" when a peer uses lnd's SCB feature to ask us
to broadcast the latest state. This updates the error message to be
a bit clearer.
If we detected a spend for a channel onchain prior to handling its
`ChannelForceClosed` monitor update, we'd log a concerning error
message and return an error unnecessarily. The channel has already been
closed, so handling the `ChannelForceClosed` monitor update at this
point should be a no-op.
Minor changes in preparation for supporting route blinding in
PaymentParameters. In the next commit, we'll be moving more
unblinded-payee-specific fields from the top level parameters into the clear
enum variant.
A while back, in tests, we added a `AChannelManager` trait, which
is implemented for all `ChannelManager`s, and can be used as a
bound when we need a `ChannelManager`, rather than having to
duplicate all the bounds of `ChannelManager` everywhere.
Here we do the same thing for `PeerManager`, but make it public and
use it to clean up `lightning-net-tokio` and
`lightning-background-processor`.
We should likely do the same for `AChannelManager`, but that's left
as a followup.
The previous commits set up the ability for us to hold
`ChannelMonitorUpdate`s which are pending until we're ready to pass
them to users and have them be applied. However, if the
`ChannelManager` is persisted while we're waiting to give the user
a `ChannelMonitorUpdate` we'll be confused on restart - seeing our
latest `ChannelMonitor` state as stale compared to our
`ChannelManager` - a critical error.
Luckily the solution is trivial, we simply need to store the
pending `ChannelMonitorUpdate` state and load it with the
`ChannelManager` data, allowing stale monitors on load as long as
we have the missing pending updates between where we are and the
latest `ChannelMonitor` state.
