Matt Corallo [Tue, 17 Jan 2023 00:16:48 +0000 (00:16 +0000)]
Make `background-processor` no-std-friendly (ish)
This makes `background-processor` build without `std` at all. This
isn't particularly useful in the general no-std case as
`background-processor` is only useful with the `futures` feature,
and async will generally need `std` in some way or another. Still,
it ensures we don't end up reintroducing a dependency on the
current time, which breaks `wasm` use-cases.
Matt Corallo [Tue, 17 Jan 2023 00:03:43 +0000 (00:03 +0000)]
Use the user-provided `SleepFuture` for interval checks in BP
`background-processor` does a number of jobs on various timers.
Instead of doing those by interrogating `std::time::Instant`, this
change swaps to using the existing user-provided sleep future.
Matt Corallo [Mon, 16 Jan 2023 23:47:11 +0000 (23:47 +0000)]
Use flexible timer types in background processor's regular jobs
`background-processor` does a number of jobs on various timers.
Currently, those are all done by checking the timers every 100ms
by interrogating `std::time::Instant`. This is fine for the
threaded version, but we'd like more flexibility in the `futures`-
based `background-processor`.
Here we swap the `std::time::Instant` interrogation for a lambda
which we will switch out to the user-provided sleeper in the next
commit.
Wilmer Paulino [Wed, 11 Jan 2023 18:21:29 +0000 (10:21 -0800)]
Use UserConfig to determine advertised InitFeatures by ChannelManager
This is purely a refactor that does not change the InitFeatures
advertised by a ChannelManager. This allows users to configure which
features should be advertised based on the values of `UserConfig`. While
there aren't any existing features currently leveraging this behavior,
it will be used by the upcoming anchors_zero_fee_htlc_tx feature.
The UserConfig dependency on provided_init_features caused most
callsites of the main test methods responsible for opening channels to
be updated. This commit foregos that completely by no longer requiring
the InitFeatures of each side to be provided to these methods. The
methods already require a reference to each node's ChannelManager to
open the channel, so we use that same reference to obtain their
InitFeatures. A way to override such features was required for some
tests, so a new `override_init_features` config option now exists on
the test harness.
Matt Corallo [Tue, 10 Jan 2023 06:37:39 +0000 (06:37 +0000)]
Make `debug_sync` regex more robust
On windows the symbol names appear to sometimes be truncated,
which causes the symbol name to not include the `::new` at the end.
This causes the regex to mis-match and track the wrong location
for the mutex construction, leading to bogus lockorder violations.
For example, in testing the following symbol name appeared on
Windows, without the function name itself:
Omer Yacine [Fri, 6 Jan 2023 08:18:26 +0000 (10:18 +0200)]
Expose `impl_writeable_tlv_based` macro
Every exported macro needed to have all the macros used inside it:
1- to be exported as well.
2- be called from the `$crate` namespace so it works in other crates.
Some structs in `lightning::util::ser` needed to be made public as they were used inside the exported macros.
Use the macros like this:
```Rust
lightning::impl_writeable_tlv_based!(...)
```
Jeffrey Czyz [Fri, 16 Dec 2022 20:06:33 +0000 (14:06 -0600)]
Define blinded hop features for use in BOLT 12
BOLT 12 invoices may contain blinded_payinfo for each hop in a blinded
path. Each blinded_payinfo contains features, whose length must be
encoded since there may be multiple hops.
Note these features are also needed in the BOLT 4 encrypted_data_tlv
stream. But since they are a single TLV record, the length must *not* be
encoded there.
Jeffrey Czyz [Fri, 16 Dec 2022 19:35:50 +0000 (13:35 -0600)]
Use explicit WithoutLength for BOLT 12 features
Most BOLT 12 features are used as the value of a TLV record and thus
don't use an explicit length. One exception is the features inside the
blinded payinfo subtype since the TLV record contains a list of them.
However, these features are also used in the BOLT 4 encrypted_data_tlv
TLV stream as a single record, where the length is implicit.
Implement Readable and Writeable for Features wrapped in WithoutLength
such that either serialization can be used where required.
Matt Corallo [Wed, 28 Dec 2022 18:12:29 +0000 (18:12 +0000)]
Ensure the per-channel key derivation counter doesn't role over
Previously, the `derive_channel_keys` derivation ID asserted that
the high bit of the per-channel key derivation counter doesn't
role over as it checked the 31st bit was zero. As we no longer do
that, we should ensure the assertion in `generate_channel_keys_id`
asserts that we don't role over.
Matt Corallo [Wed, 28 Dec 2022 17:44:33 +0000 (17:44 +0000)]
Ensure `derive_channel_keys` doesn't panic if per-run seed is high
b04d1b868fe28bea2e4c711e6e6d2470d2b98d77 changed the way we
calculate the `channel_keys_id` to include the 128-bit
`user_channel_id` as well, shifting the counter up four bytes and
the `starting_time_nanos` field up into the second four bytes.
In `derive_channel_keys` we hash the full `channel_keys_id` with an
HD-derived key from our master seed. Previously, that key was
derived with an index of the per-restart counter, re-calculated by
pulling the second four bytes out of the `user_channel_id`. Because
the `channel_keys_id` fields were shifted up four bytes, that is
now a reference to the `starting_time_nanos` value. This should be
fine, the derivation doesn't really add any value here, its all
being hashed anyway, except that derivation IDs must be below 2^31.
This implies that we panic if the user passes a
`starting_time_nanos` which has the high bit set. For those using
the nanosecond part of the current time this isn't an issue - the
value cannot exceed 1_000_000, which does not have the high bit
set, however, some users may use some other per-run seed.
Thus, here we simply drop the high bit from the seed, ensuring we
don't panic. Note that this is backwards compatible as it only
changes the key derivation in cases where we previously panicked.
Ideally we'd drop the derivation entirely, but that would break
backwards compatibility of key derivation.
Matt Corallo [Fri, 23 Dec 2022 20:44:24 +0000 (20:44 +0000)]
No-export `&self` methods on non-cloneable enum(s)
Specifically, `OnionMessageContents` is a non-cloneable enum, which
isn't stored opaque so we cannot call `&self` methods on it.
Because its methods aren't critical to the API for now, we simply
no-export them rather than trying to work out an alternative
approach.
Matt Corallo [Thu, 22 Dec 2022 21:58:53 +0000 (21:58 +0000)]
Store an owned `Score` in `ScorerAccountingForInFlightHtlcs`
`ScorerAccountingForInFlightHtlcs` generally stores a `Score`
reference generated by calling `LockableScore::lock`, which
actually returns an arbitrary `Score`. Given `Score` is implemented
directly on lock types, it makes sense to simply hold a fully owned
`Score` in `ScorerAccountingForInFlightHtlcs` rather than a mutable
reference to one.
9d7bb73b599a7a9d8468a2f0c54d28f0ce6cf543 broke some capitalization
in docs for `sign_invoice`, which we fix here as well as taking
this opportunity to clean up the `sign_invoice` docs more
generally.
Once ChannelManager supports payment retries, it will make more sense for its
current send_payment method to be named send_payment_with_route because
retrying should be the default. Here we get a head start on this by making the
rename in outbound_payment, but not changing the public interface yet.
Swap pending_outbound_payments for OutboundPayments struct
This allows us to move a lot of outbound payment logic out of ChannelManager
and into the new outbound_payment module, and helps avoid growing
ChannelManager when we add retry logic to it in upcoming work.
Move PendingOutboundPayment to new outbound_payment module
We want to move all outbound payment-related things to this new module, to help
break up ChannelManager so future payment retries work doesn't increase the
size of ChannelManager.
Wilmer Paulino [Tue, 13 Dec 2022 03:00:06 +0000 (19:00 -0800)]
Avoid redundant broadcast of local commitment transaction
This change follows the rationale of commit 62236c7 and addresses the
last remaining redundant local commitment broadcast.
There's no need to broadcast our local commitment transaction if we've
already seen a confirmed one as it'll be immediately rejected as a
duplicate/conflict.
This will also help prevent dispatching spurious events for bumping
commitment and HTLC transactions through anchor outputs since the
dispatch for said events follows the same flow as our usual commitment
broadcast.