In the coming commits we'll move to storing in-flight
`ChannelMonitorUpdate`s in the `ChannelManager` rather in the
`Channel` (which will then only retain `ChannelMonitorUpdate`s
which have not yet been released/are blocked.
This will simplify handling of pending `ChannelMonitorUpdate` after
a channel has closed by not having to move them into the
`ChannelManager`.
Downstream crates building fur fuzzing will usually set
`--cfg=fuzzing` as a side-effect of the Rust fuzzing tooling. Thus,
we should ensure we build without failure in such cases.
We do this here by simply relying on the `_test_utils` feature,
rather than conditionally-compiling in modules based on the
`fuzzing` flag.
Make sure the penultimate hop took the amount of fee that they claimed to take.
Without checking this TLV, we're heavily relying on the receiving wallet code
to correctly implement logic to calculate that that the fee is as expected.
Useful for penultimate hops in routes to take an extra fee, if for example they
opened a JIT channel to the payee and want them to help bear the channel open
cost.
We need the channel lock for constructing a pending HTLC's status because we
need to know if the channel accepts underpaying HTLCs in upcoming commits.
This allows users to bump their commitments and HTLC transactions
without having to worry about all the little details to do so. Instead,
we'll just require that they implement the `CoinSelectionSource` trait
over their wallet/UTXO source, granting the event handler permission to
spend confirmed UTXOs for the transactions it'll produce.
While the event handler should in most cases produce valid transactions,
assuming the provided confirmed UTXOs are valid, it may not produce
relayable transactions due to not satisfying certain Replace-By-Fee
(RBF) mempool policy requirements. Some of these require that the
replacement transactions have a higher feerate and absolute fee than the
conflicting transactions it aims to replace. To make sure we adhere to
these requirements, we'd have to persist some state for all transactions
the event handler has produced, greatly increasing its complexity. While
we may consider implementing so in the future, we choose to go with a
simple initial version that relies on the OnchainTxHandler's bumping
frequency. For each new bumping attempt, the OnchainTxHandler proposes a
25% feerate increase to ensure transactions can propagate under
constrained mempool circumstances.
This commit also adds two new maps to `PeerState` for keeping track
of `OutboundV1Channel`s and `InboundV1Channel`s so that further
commits are a bit easier to review.
To reduce interleaving in commits, we introduce a `context` variable
in methods to be moved in upcoming commits so there is minimal change
with the moves.
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields to be updated for things to
compile, but these should be quite clear.
This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.
f s/tarcontext.get_/target_/
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This commit also uses these methods through the `context` field where
needed for compilation and tests to pass due to the above change.
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This is a first step for simplifying the channel state and introducing
new unfunded channel types that hold similar state before being promoted
to funded channels.
Essentially, we want the outer `Channel` type (and upcoming channel types)
to wrap the context so we can apply typestate patterns to the that wrapper
while also deduplicating code for common state and other internal fields.
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.
0.0.103 is now downright ancient, and certainly shouldn't exist in
production anywhere today. Thus, it seems fine to remove the
ability to create legacy stateful inbound payment entries.
Users downgrading to 0.0.103 will thus not be able to claim any
payments created on modern LDK, though we still retain the ability
to claim such payments at least for one more release.
The logic has been changed around duplicate keysend payments such that
it's no longer explicitly clear that we reject duplicate keysend
payments now that we handle receiving multi-part keysends. This test
catches that. Note that this also tests that we reject MPP keysends when
our config states we should, and that we reject MPP keysends without
payemnt secrets when our config states we support MPP keysends.
This commit refactors a significant portion of the receive validation in
`ChannelManager::process_pending_htlc_forwards` now that we repurpose
previous MPP validation logic to accomodate keysends. This also removes
a previous restriction on claiming, as well as tests sending and
receiving MPP keysends.
This commit adds the field `payment_data: FinalOnionHopData` to
`ReceiveKeysend` which will allow us to check for payment secrets and
total amounts which is needed to support receiving MPP keysends. This
field is non-backwards compatible since we wouldn't be able to handle
an MPP keysend properly if we were to downgrade to a prior version.
We also no longer reject keysends with payment secrets if we support MPP
keysend.
