Filter the route hints in `create_invoice_from_channelmanager` based on
the following criteria:
* Only one channel per counterparty node
* Always select the channel with the highest inbound capacity
* Filter out channels with a lower inbound capacity than the invoice
amount, if any channel exists with enough capacity to cover the invoice
amount
* If any public channel exists, the invoice route_hints should be empty,
and the sender will need to find the path to the payment-receiving node
by looking at the public channels instead
Previously, if we were offline when a funding transaction was
locked in, and then we came back online, calling
`best_block_updated` once followed by `transactions_confirmed`,
we'd not generate a funding_locked until the next
`best_block_updated`.
We address this by re-calling `best_block_updated` in
`transactions_confirmed`, similar to how `ChannelMonitor` works.
As a part of adding SCID aliases to channels, we now have to accept
otherwise-redundant funding_locked messages which serve only to
update the SCID alias. Previously, we'd failt he channel as such
an update used to be bogus.
This creates an SCID alias for all of our outbound channels, which
we send to our counterparties as a part of the `funding_locked`
message and then recognize in any HTLC forwarding instructions.
Note that we generate an SCID alias for all channels, including
already open ones, even though we currently have no way of
communicating to our peers the SCID alias for already-open
channels.
New `funding_locked` messages can include SCID aliases which our
counterparty will recognize as "ours" for the purposes of relaying
transactions to us. This avoids telling the world about our
on-chain transactions every time we want to receive a payment, and
will allow for receiving payments before the funding transaction
appears on-chain.
Here we store the new SCID aliases and use them in invoices instead
of he "standard" SCIDs.
`handle_monitor_err!()` has a number of different forms depending
on which messages and actions were outstanding when the monitor
updating first failed. Instead of matching by argument count, its
much more readable to put an explicit string in the arguments to
make it easy to scan for the called form.
Users who want to use lightning-block-sync's init module would
be reasonable in wanting to use it in a multithreaded environment,
however because it takes a list of listeners as dyn chain::Listen
without any Send or Sync bound they fail in doing so.
Here we make the type bounds on `chain::Listen` generic across
`chain::Listen + ?Sized`, which the existing bound of `&dyn
chain::Listen` satisfies. Thus, this is strictly less restrictive
and allows for the use of `&dyn chain::Listen + Send + Sync`.
To ensure no-std is honored across dependencies, add a crate depending
on lightning crates supporting no-std. This should ensure any
regressions are caught. Otherwise, cargo doesn't seem to catch some
incompatibilities (e.g., f64::log10 unavailable in core) and seemingly
across other dependencies as describe here:
https://blog.dbrgn.ch/2019/12/24/testing-for-no-std-compatibility/
This makes tests slightly more realistic by delivering
`channel_update`s to `ChannelManager`s, ensuring we have
forwarding data stored locally for all channels, including public
ones.
In 2d3a210897, we increased the
default ping timer in `lightning-background-processor` to ten
seconds from five. However, we didn't change the timer count at
which we disconnect peers if they're not responding, which we
likely should have done. We do so here, as well as update the
documentation for `PeerManager::timer_tick_occurred` to suggest
always ticking the timer every ten seconds instead of five.
Its very confusing to have multiple fields that do the same thing,
one of which isn't even used for its stated purpose anymore after
the previous few commits.
There are currently two issues with
`bolt2_open_channel_sending_node_checks_part1` which counteract
each other and hide that the test isn't testing what it should be.
First of all, the final `create_channel` call actually fails
because we try to open a channel with ourselves, instead of
panicing as the test is supposed to check for.
However, when we fix the create_channel call to panic, when we
drop `nodes[1]` after `create_channel` panics, we fail the
no-pending-messages test as it as an expeted `accept_channel` in
its outbound buffer. This causes a double-panic.
Previously, these two offset each other - instead of panicing in
`create_channel` we'd panic in the Node drop checks.
This fixes both by fetching the `accept_channel` before we go into
the panic'ing `create_channel` call (who's arguments were
corrected).
... by calling it both before and after every chain event in
testing and fuzzing.
This requires fixing some blockchain inconsistencies in
`do_test_onchain_htlc_reorg`, `do_retry_with_no_persist`, and
`do_test_dup_htlc_onchain_fails_on_reload` where we'd connect
conflicting transactions in the same chain.
When handling the broadcast of a local commitment transactions
(with associated CSV delays prior to spendability), we incorrectly
handled the CSV delays on HTLC transactions. This caused us to miss
spendable outputs for HTLCs which were awaiting a CSV delay.
Further, because of this, we could hit an assertion as
`get_claimable_balances` asserted that HTLCs were resolved after
the funding spend was resolved, which was not true if the HTLC did
not have a CSV delay attached (due to the above bug or due to it
being an HTLC claim by our counterparty).
This fixes both bugs, also converting some assertions to
`debug_assert`s to avoid future issues as balance mis-calculation
is not currently an indication of potential funds loss.
Thanks to Cash App for reporting this bug.
This doesn't (appear) to change behavior, however if we have a
non-public node, we assign an A* heuristic of max-u32 fees, which
may result in us de-prioritizing the path in some rare cases around
multi-hop route hints which compete with public nodes.
When we added support for routing through a multi-hop invoice hint
we failed to remove an assertion that we always are able to fill
in features for each hop except the last one. However, when a
multi-hop invoice hint is used, we will not have features for any
of the hinted hops, causing us to panic.
