Merge pull request #1375 from jkczyz/2022-03-scorer-followup

ProbabilisticScorer optimizations

Merge pull request #1382 from TheBlueMatt/2022-03-gossip-queries-sucks

Fix gossip using `gossip_timestamp_filter` instead of queries

Merge pull request #1381 from shamardy/2022-03-set-inbound-user-chan-id

Add `user_channel_id` to `accept_inbound_channel` method

Fix gossip using `gossip_timestamp_filter` instead of queries

See large comment added for more details

Increase default liquidity_penalty_multiplier_msat

Using a larger multiplier gives more reasonable penalties for larger
success probabilities.

Move max penalty cap in ProbabilisticScorer

This reduce a branch in the 0 and u6::max_value cases.

Fix overflow in ProbabilisticScorer

When a routing hint is given in an invoice, the effective capacity of
the channel is assumed to be infinite (i.e., u64::max_value) if the hop
is private. Adding 1 to this in the success probability calculation will
cause an overflow and ultimately an `index out of bounds panic` in
log10_times_1024. This was not an issue with using log10 because the use
of f64 would give infinite which casts to 0 for u64.

Add a base penalty to ProbabilisticScorer

ProbabilisticScorer tends to prefer longer routes to shorter ones. Make
the default scoring behavior include a customizable base penalty to
avoid longer routes.

Don't serialize FixedPenaltyScorer parameters

Serializing scorer parameters makes it difficult to experiment with
different settings.

set user_channel_id in accept_inbound_channel fn

fix docs

edit user_channel_id docs for Event::ChannelClosed

review fixes

Merge pull request #1359 from tnull/2022-03-real-random-shuffle

Randomize candidate paths during route selection.

Merge pull request #1380 from TheBlueMatt/2022-03-skip-redundant-sig-checks

Skip `channel_update` signature checks if we have a newer state

Skip `channel_update` signature checks if we have a newer state

`channel_update` messages already have their signatures checked
with the network graph write lock held, so there's no reason to
check the signatures before doing other quicker checks first,
including checking if we're already aware of a newer update for the
channel.

This reduces common-case CPU usage as `channel_update`s are sent
rather liberally over the p2p network to gossip them.

Merge pull request #1058 from TheBlueMatt/2021-08-fail-claimed-dust-htlc

Add a further test of HTLC failure after a claim occurrs.

Minor refactor for sort / add, and some nits.

- `sort_by_key` to `sort_unstable_by_key`
- `checked_add() .. max_value()` to `saturating_add()`
- Some typos and nits

Randomize candidate paths during route selection.

Add a further test of HTLC failure after a claim occurrs.

This adds a further test of 7e78fa660cec8a73286c94c1073ee588140e7a01
which I had lying around in my TODO list for a while.

Merge pull request #1370 from TheBlueMatt/2022-03-pref-first-hop-chans

Avoid needless MPP on multiple channels to the same first-hop

Merge pull request #1360 from tnull/2022-03-loopless-random-walks

Avoid looping CLTV shadow routes.

Merge pull request #1326 from Psycho-Pirate/peers

Added option to send remote IP to peers

Avoid needless MPP on multiple channels to the same first-hop

When we have many channels to the same first-hop, many of which do
not have sufficient balance to make the requested payment, but when
some do, instead of simply using the available channel balance we
may switch to MPP, potentially with many, many paths.

Instead, we should seek to use the smallest channel which can
easily handle the requested payment, which we do here by sorting
the first_hops in our router before beginning the graph search.

Note that the "real" fix for this should be to instead decide which
channel to use at HTLC-send time, as most other nodes do during
relay, but this provides a minimal fix without needing to do the
rather-large work of refactoring our HTLC send+relay pipelines.

Issues with overly-aggressive MPP on many channels were reported by
Cash App.

Avoid looping CLTV shadow routes.

Merge pull request #1374 from TheBlueMatt/2022-03-bindings-cleanups

Trivial Bindings Cleanups

Argument added in lightning-net-tokio/src/lib.rs and comments updated

added network address in methods, filter_address function with tests and updated documentation

Merge pull request #1353 from dunxen/2022-03-mpp-receive-timeout

Add MPP receive timeout handling

Merge pull request #1373 from lightningdevkit/dependabot/github_actions/actions/cache-3

Bump actions/cache from 2 to 3

Merge pull request #1368 from TheBlueMatt/2022-03-fix-post-start-sync

Send a gossip_timestamp_filter on connect to enable gossip sync

Add MPP receive timeout handling

Merge pull request #1352 from TheBlueMatt/2022-03-debug-rwlock

Implement lockorder checking on RwLocks in debug_sync

Use `impl<bounds>` instead of a `where` clause to help bindings

Tag some type aliases with `(C-not exported)`

Type aliases are now more robustly being exported in the C bindings
generator, which requires ensuring we don't include some type
aliases which make no sense in bindings.

Bump actions/cache from 2 to 3

Bumps [actions/cache](https://github.com/actions/cache) from 2 to 3.
- [Release notes](https://github.com/actions/cache/releases)
- [Commits](https://github.com/actions/cache/compare/v2...v3)

---
updated-dependencies:
- dependency-name: actions/cache
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Merge pull request #1361 from luizParreira/rust-lightning/issues/1280

Create normal/phantom invoice with description hash

Use the term "lock" for `Mutex`/`RwLock` instead of "mutex"

Implement lockorder checking on RwLocks in debug_sync

Create normal/phantom invoice with description hash

Merge pull request #1363 from TheBlueMatt/2022-03-tx-conf-ordering-lock-delay

Generate a funding_locked on relevant transactions_confirmed calls

Send a `gossip_timestamp_filter` on connect to enable gossip sync

On connection, if our peer supports gossip queries, and we never
send a `gossip_timestamp_filter`, our peer is supposed to never
send us gossip outside of explicit queries. Thus, we'll end up
always having stale gossip information after the first few
connections we make to peers.

The solution is to send a dummy `gossip_timestamp_filter`
immediately after connecting to peers.

Rename `RoutingMessageHandler::sync_routing_table` `peer_connected`

Its somewhat strange to have a trait method which is named after
the intended action, rather than the action that occurred, leaving
it up to the implementor what action they want to take.

Merge pull request #1358 from TheBlueMatt/2022-03-max-cltv

Make `max_total_cltv_expiry_delta` include the final CLTV

Make `max_total_cltv_expiry_delta` include the final CLTV

This fixes an integer underflow found by the `router` fuzz target
in CI.

Make routing benchmark robust against path changes

If the scoring in the routing benchmark causes us to take a
different path from the original scan, we may end up deciding that
the only path to a node has a too-high total CLTV delta, causing us
to panic in the benchmarking phase.

Here we simply check for that possibility and remove paths that
fail post-scoring.

Merge pull request #1325 from ViktorTigerstrom/2022-02-filter-route-hints

Filter route hints when creating invoices

Add phantom invoice route hints filtering tests

Filter route hints for phantom invoices

Filter the route hints in `create_phantom_invoice` based on the
following criteria:

* Only one channel for every counterparty node per phantom
payment-receiving node in the invoice
* Always select the channel with the highest inbound capacity
* For each payment-receiving node, 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 channels exists for a payment-receiving node, push a
single RouteHintHop with the phantom route and let the sender find the
path to the payment-receiving node through the public channels.

Add tests for create invoice route hints filtering

Filter route hints for create invoice

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

Generate a funding_locked on relevant transactions_confirmed calls

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.

Merge pull request #1331 from TheBlueMatt/2022-02-no-copy-invoice-fields

Use &mut self in invoice updaters, not take-self-return-Self

Merge pull request #1311 from TheBlueMatt/2022-02-0conf-part-1

Support for SCID Aliases

Merge pull request #1341 from jkczyz/2022-03-expiry-time-panic

Correct docs about invoice_expiry_delta_secs panic

Merge pull request #1349 from TheBlueMatt/2022-03-listen-send-sync

Require `chain::Listen` impls in block sync be `Send + Sync`

Merge pull request #1348 from TheBlueMatt/2022-03-timer-tick-count

Reduce the number of timer ticks a peer is allowed to take

Merge pull request #1355 from lightningdevkit/dependabot/cargo/lightning/regex-0.2.11

Update regex requirement from 0.1.80 to 0.2.11 in /lightning

Correct docs about invoice_expiry_delta_secs panic

Support receiving multiple funding_locked messages

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.

Provide our peers with SCID aliases and forward payments with them

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.

Handle `short_to_id` state updates on channel closure via macros

This avoids needing to update channel closure code in many places
as we add multiple SCIDs for each channel and have to track them.

Track SCID aliases from our counterparty and use them in invoices

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.

Add support for deserializing the new SCID alias in funding_locked

Clean up the `handle_monitor_err!()` macro argument forms somewhat

`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.

Merge pull request #1286 from tnull/add_random_cltv_offsets

Add random 'shadow route' CLTV delta offsets to improve privacy

Make lightning-block-sync's init module slightly more generic

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`.

Update regex requirement from 0.1.80 to 0.2.11 in /lightning

Updates the requirements on [regex](https://github.com/rust-lang/regex) to permit the latest version.
- [Release notes](https://github.com/rust-lang/regex/releases)
- [Changelog](https://github.com/rust-lang/regex/blob/master/CHANGELOG.md)
- [Commits](https://github.com/rust-lang/regex/compare/0.1.80...0.2.11)

---
updated-dependencies:
- dependency-name: regex
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

Add a random per-path CLTV offset for privacy.

Merge pull request #1347 from jkczyz/2022-03-log-approximation

Use log approximation in ProbabilisticScorer

Refactor debug sync methods into helper functions

Check for no-std compatibility across dependencies

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/

Fix compilation warnings with --features=no-std

Use log approximation in ProbabilisticScorer

Since f64::log10 exists in std but not core, unconditionally use log
approximation so --feature=no-std will compile.

Move private channel and short-conf tests to new module

Add a new functional test utility to open an unannounced channel

Give `ChannelManager`s `channel_udpate`s for pub chans in test

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.

Reduce the number of timer ticks a peer is allowed to take

In 2d3a2108979adca6b7632e2d59c10e4b131e8bf4, 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.

Merge pull request #1317 from TheBlueMatt/2022-02-fix-bunk-test

Fix what `bolt2_open_channel_sending_node_checks_part1` tests

Clean up `TestKeysInterface` random bytes override interface

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.

Fix what `bolt2_open_channel_sending_node_checks_part1` tests

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).

Merge pull request #1343 from lightningdevkit/dependabot/github_actions/actions/checkout-3

Bump actions/checkout from 2 to 3

Merge pull request #1346 from TheBlueMatt/2022-03-clones

Add Clone to a few structs which contain only a few fields

Add Clone to a few structs which contain only a few fields

Specifically, `PhantomRouteHints`, `FixedPenaltyScorer`, and
`ScoringParamters`.

Merge pull request #1310 from TheBlueMatt/2022-02-bump-msrv

Bump MSRV to 1.41.1.

Bump actions/checkout from 2 to 3

Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 3.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v2...v3)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Merge pull request #1339 from TheBlueMatt/2022-02-0.0.105-sec

0.0.105 Security Fixes

Update CHANGELOG with security info for 0.0.105

Merge branch '2022-02-bal-panic' into 2022-02-0.0.105-sec

Merge branch '2022-02-fix-multi-hop-hint-panic' into 2022-02-0.0.105-sec

Merge pull request #1322 from TheBlueMatt/2022-02-0.0.105

Cut 0.0.105

Ensure `get_claimable_balances` never panicks in tests

... 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.

Fix HTLC tx balance calculation on local commitment transactions

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.

Bump crate versions to 0.0.105/invoice 0.13

Fill out CHANGELOG for 0.0.105

Correct default value for A* heuristic for non-public nodes

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.

Fix panic when routing through multiple private last-hops

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.

Merge pull request #1327 from TheBlueMatt/2022-02-log-before-panic

Merge pull request #1303 from jkczyz/2022-02-docs-with-features

Generate docs with features for docs.rs

Merge pull request #1335 from TheBlueMatt/2022-02-fix-honggfuzz-regression

Pin rustc in fuzzing to 1.58 due to honggfuzz-rs regression

Merge pull request #1324 from valentinewallace/2022-02-phantom-followup

#1199 Followup

Merge pull request #1332 from TheBlueMatt/2022-02-persister-ignore-tmp

Ignore .tmp files when loading ChannelMonitors in persister

Pin rustc in fuzzing to 1.58 due to honggfuzz-rs regression