Avoid querying the chain for outputs for channels we already have

If we receive a ChannelAnnouncement message but we already have the
channel, there's no reason to do a chain lookup. Instead of
immediately calling the user-provided `chain::Access` when handling
a ChannelAnnouncement, we first check if we have the corresponding
channel in the graph.

Note that if we do have the corresponding channel but it was not
previously checked against the blockchain, we should still check
with the `chain::Access` and update if necessary.

Merge pull request #1676 from arik-so/2022-08-gossip-error-message-fix

Fix script order in gossip key mismatch error.

Merge pull request #1575 from NicolaLS/hash-invoice

Fix script order in gossip key mismatch error.

derive Hash for Invoice

Merge pull request #1670 from TheBlueMatt/2022-08-mon-size-guidelines

Provide guidance on ChannelMonitorUpdate serialized size

Merge pull request #1495 from TheBlueMatt/2022-04-all-claimables

Expose counterparty-revoked-outputs in `get_claimable_balance`

Provide guidance on ChannelMonitorUpdate serialized size

Users need to make decisions about storage sizing and we need to
have advice on the maximum size of various things users need to
store. ChannelMonitorUpdates are likely the worst case of this,
they're usually at max a few KB, but can get up to a few hundred
KB for commitment transactions that have 400+ HTLCs pending.

We had one user report an update (likely) going over 400 KiB, which
isn't immediately obvious to me is practical, but its within a few
multiples of trivially-reachable sizes, so its likely that did
occur. To be on the safe side, we simply recommend users ensure
they can support "upwards of 1 MiB" here.

Merge pull request #1648 from valentinewallace/2022-08-fuzz-onion-msgs

Onion messages: add fuzz testing

Merge pull request #1666 from TheBlueMatt/2022-08-fix-script-check

Correct the on-chain script checked in gossip verification

Correct the on-chain script checked in gossip verification

The `bitcoin_key_1` and `bitcoin_key_2` fields in
`channel_announcement` messages are sorted according to node_ids
rather than the keys themselves, however the on-chain funding
script is sorted according to the bitcoin keys themselves. Thus,
with some probability, we end up checking that the on-chain script
matches the wrong script and rejecting the channel announcement.

The correct solution is to use our existing channel funding script
generation function which ensure we always match what we generate.

This was found in testing the Java bindings, where a test checks
that retunring the generated funding script in `chain::Access`
results in the constructed channel ending up in our network graph.

Fuzz test onion messages

Also update the fuzz ChaCha20Poly1305 to not mark as finished after a single
encrypt_in_place.  This is because more bytes may still need to be encrypted,
causing us to panic at the assertion that finished == false when we go to
encrypt more.

Also fix unused_mut warning in messenger + add log on OM forward for testing

Merge pull request #1660 from TheBlueMatt/2022-08-cleanup-ratelimits

Backfill gossip without buffering directly in LDK

Move per-HTLC logic out of get_claimable_balances into a helper

Val suggested this as an obvious cleanup to separate per_HTLC logic
from the total commitment transaction logic, separating the large
function into two.

Expose counterparty-revoked-outputs in `get_claimable_balance`

This uses the various new tracking added in the prior commits to
expose a new `Balance` type - `CounterpartyRevokedOutputClaimable`.

Some nontrivial work is required, however, as we now have to track
HTLC outputs as spendable in a transaction that comes *after* an
HTLC-Success/HTLC-Timeout transaction, which we previously didn't
need to do. Thus, we have to check if an
`onchain_events_awaiting_threshold_conf` event spends a commitment
transaction's HTLC output while walking events. Further, because
we now need to track HTLC outputs after the
HTLC-Success/HTLC-Timeout confirms, and because we have to track
the counterparty's `to_self` output as a contentious output which
could be claimed by either party, we have to examine the
`OnchainTxHandler`'s set of outputs to spend when determining if
certain outputs are still spendable.

Two new tests are added which test various different transaction
formats, and hopefully provide good test coverage of the various
revoked output paths.

Drop uneccessary `if {...; bool}` pattern in PeerManager

Replace manual iteration with for loops in outbound gossip sync

Simplify claimable balance trivially with consistent accessors

Scan `onchain_events_awaiting_threshold_conf` once in balance calc

Instead of a series of different
`onchain_events_awaiting_threshold_conf.iter()...` calls to scan
for HTLC status in balance calculation, pull them all out into one
`for ... { match ... }` to do it once and simplify the code
somewhat.

Track the txid that resolves HTLCs even after resolution completes

We need this information when we look up if we still need to spend
a revoked output from an HTLC-Success/HTLC-Timeout transaction for
balance calculation.

Track HTLC-Success/HTLC-Timeout claims of revoked outputs

When a counterparty broadcasts a revoked commitment transaction,
followed immediately by HTLC-Success/-Timeout spends thereof, we'd
like to have an `onchain_events_awaiting_threshold_conf` entry
for them.

This does so using the `HTLCSpendConfirmation` entry, giving it
(slightly) new meaning. Because all existing uses of
`HTLCSpendConfirmation` already check if the relevant commitment
transaction is revoked first, this should be trivially backwards
compatible.

We will ultimately figure out if something is being spent via the
`OnchainTxHandler`, but to do so we need to look up the output via
the HTLC transaction txid, which this allows us to do.

Fix off-by-one in test_onchain_htlc_claim_reorg_remote_commitment

The test intended to disconnect a transaction previously connected
but didn't disconnect enough blocks to do so, leading to it
confirming two conflicting transactions.

In the next few commits this will become an assertion failure.

Clean up nesting in `get_counterparty_output_claim_info`

Track counterparty payout info in counterparty commitment txn

When handling a revoked counterparty commitment transaction which
was broadcast on-chain, we occasionally need to look up which
output (and its value) was to the counterparty (the `to_self`
output). This will allow us to generate `Balance`s for the user for
the revoked output.

Store the full event transaction in `OnchainEvent` structs

When we see a transaction which generates some `OnchainEvent`, its
useful to have the full transaction around for later analysis.
Specifically, it lets us check the list of outputs which were spent
in the transaction, allowing us to look up, e.g. which HTLC
outpoint was spent in a transaction.

This will be used in a few commits to do exactly that - figure out
which HTLC a given `OnchainEvent` corresponds with.

Merge pull request #1663 from tnull/2022-08-drop-register-output-return

Drop return value from `Filter::register_output`

Backfill gossip without buffering directly in LDK

Instead of backfilling gossip by buffering (up to) ten messages at
a time, only buffer one message at a time, as the peers' outbound
socket buffer drains. This moves the outbound backfill messages out
of `PeerHandler` and into the operating system buffer, where it
arguably belongs.

Not buffering causes us to walk the gossip B-Trees somewhat more
often, but avoids allocating vecs for the responses. While its
probably (without having benchmarked it) a net performance loss, it
simplifies buffer tracking and leaves us with more room to play
with the buffer sizing constants as we add onion message forwarding
which is an important win.

Note that because we change how often we check if we're out of
messages to send before pinging, we slightly change how many
messages are exchanged at once, impacting the
`test_do_attempt_write_data` constants.

Clarify 'should' vs 'will' in `get_relevant_txids`

Drop return value from `Filter::register_output`

This commit removes the return value from `Filter::register_output` as
creating a suitable value almost always entails blocking operations
(e.g., lookups via network request), which however conflicts with the
requirement that user calls should avoid blocking calls at all cost.

Removing the return value also rendered quite a bit of test code for
dependent transaction handling superfluous, which is therefore also
removed with this commit.

Merge pull request #1659 from valentinewallace/2022-08-fix-payload-decode

Fix payment onion payload decode

Fix fuzzer-found underflow

Rename HighZeroBytesDroppedVarInt to HighZeroBytesDroppedBigSize

As observed by @wpaulino, this struct encodes its bytes as big-endian,
therefore it's a BigSize, not a VarInt.

Fix bug in onion payment payload decode

Prior to this change, we could have failed to decode a valid payload of size
>253. This is because we were decoding the length (a BigSize, big-endian) as a
VarInt (little-endian).

Found in #1652.

Merge pull request #1658 from lightning-signer/2022-08-bitcoin-0-29

Update bitcoin crate to 0.29.0

Modify ecdh to take Scalar

Update bitcoin crate to 0.29.0

Clarify comment on BUFFER_DRAIN_MSGS_PER_TICK.

Use util methods in `Peer` to decide when to forward

This consolidates our various checks on peer buffer space into the
`Peer` impl itself, making the thresholds at which we stop taking
various actions on a peer more readable as a whole.

This commit was primarily authored by `Valentine Wallace
<vwallace@protonmail.com>` with some amendments by `Matt Corallo
<git@bluematt.me>`.

Merge pull request #1655 from valentinewallace/2022-08-fix-ci-doc-links-check

Fix CI to error on doc links to private items

Merge pull request #1651 from TheBlueMatt/2022-08-export-chan-list

[C Bindings] Expose channel and nodes list in `ReadOnlyNetworkGraph`

Merge pull request #1654 from TheBlueMatt/2022-08-update-libfuzzer

Update libfuzzer-sys to new upstream inclusion method

Update libfuzzer-sys to new upstream inclusion method

Dunno why they changed it, but the old "depend directly on git"
thing that cargo-fuzz used forever is now deprecated that that
repo is archived, they've now moved to another repo and publish
properly on crates.io.

Fix CI to error on doc links to private items

Somehow we weren't doing this.

Minor msgs::OnionHopData cleanups

[C Bindings] Expose channel and nodes list in `ReadOnlyNetworkGraph`

Merge pull request #1638 from ViktorTigerstrom/2022-07-update-decode-update-add-htlc-onion-return-parameters

Don't return `channel_state` from `decode_update_add_htlc_onion`

Merge pull request #1619 from G8XSU/main

Add config support for 'their_channel_reserve_proportional_millionths' [#1498]

Merge pull request #1503 from valentinewallace/2022-05-onion-msgs

Onion messages v1

Fix possible incomplete read bug on onion packet decode

Pre-existing to this PR, we were reading next packet bytes with io::Read::read,
which is not guaranteed to read all the bytes we need, only guaranteed to read
*some* bytes.

We fix this to be read_exact, which is guaranteed to read all the next hop
packet bytes.

Error when attempting to send an OM to a blinded route with 0 hops

Add SendError enum for onion messages and error on too-big packets

Add test utilities and integration tests for onion messages

Significantly expand onion message documentation

Implement receiving and forwarding onion messages

This required adapting `onion_utils::decode_next_hop` to work for both payments
and onion messages.

Currently we just print out the path_id of any onion messages we receive. In
the future, these received onion messages will be redirected to their
respective handlers: i.e. an invoice_request will go to an InvoiceHandler,
custom onion messages will go to a custom handler, etc.

Support sending onion messages

This adds several utilities in service of then adding
OnionMessenger::send_onion_message, which can send to either an unblinded
pubkey or a blinded route. Sending custom TLVs and sending an onion message
containing a reply path are not yet supported.

We also need to split the construct_keys_callback macro into two macros to
avoid an unused assignment warning.

Add baseline OnionMessenger and msgs::OnionMessage and its serialization

OnionMessenger will be hooked up to the PeerManager to send and receive OMs in
a follow-up PR.

KeysInterface: add new ecdh method

This method will help us avoid retrieving our node secret, something we want to
get rid of entirely.  It will be used in upcoming commits when decoding the
onion message packet, and in future PRs to help us get rid of
KeysInterface::get_node_secret usages across the codebase

Add onion_message::Packet and adapt construct_onion_packet_with_init_noise for it

We need to add a new Packet struct because onion message packet hop_data fields
can be of variable length, whereas regular payment packets are always 1366
bytes.

Co-authored-by: Valentine Wallace <vwallace@protonmail.com>
Co-authored-by: Jeffrey Czyz <jkczyz@gmail.com>

Add config support for 'their_channel_reserve_proportional_millionths' [#1498]

It is proportion of the channel value to configure as the
`their_channel_reserve_satoshis` for both outbound and inbound channels.
It decides the minimum balance that the other node has to maintain on their
side, at all times.

Don't return `channel_state` from `decode_update_add_htlc_onion`

Currently `decode_update_add_htlc_onion` returns the `channel_state`
lock to ensure that `internal_update_add_htlc` holds a single
`channel_state` lock in when the entire function execution. This is
unnecessary, and since we are moving the channel storage to the
`per_peer_state`, this no longer achieves the goal it was intended for.

We therefore avoid returning the `channel_state` from
`decode_update_add_htlc_onion`, and just retake the lock in
`internal_update_add_htlc` instead.

Merge pull request #1637 from tnull/2022-07-contrib-remove-slack

Remove Slack and update `CONTRIBUTING`

Remove Slack and update `CONTRIBUTING`

Add onion messages module + enable the construction of blinded routes

Blinded routes can be provided as destinations for onion messages, when the
recipient prefers to remain anonymous.

We also add supporting utilities for constructing blinded path keys, and
control TLVs structs representing blinded payloads prior to being
encoded/encrypted. These utilities and struct will be re-used in upcoming
commits for sending and receiving/forwarding onion messages.

Finally, add utilities for reading the padding from an onion message's
encrypted TLVs without an intermediate Vec.

Merge pull request #1628 from tnull/2022-07-readme-remove-slack

Remove Slack link and other updates to `README`

Merge pull request #1635 from TheBlueMatt/2022-07-accessor-pub

Expose `ChannelMonitor::get_counterparty_node_id`

Merge pull request #1633 from TheBlueMatt/2022-07-110

Set release date on 0.0.110 release

Merge pull request #1632 from TheBlueMatt/2022-07-warnings

Fix compilation warnings

Remove 'slack' (and other things)

Expose `ChannelMonitor::get_counterparty_node_id`

This fixes an oversight in ac842ed9dd7a36a4a26eb6b856d80ab04eecf750
namely that it left users unable to implement their own
`ChainMonitor` from outside of the `rust-lightning` crate.

Set release date on 0.0.110 release

Merge pull request #1629 from TheBlueMatt/2022-07-110

Cut 0.0.110

Bump crate versions to 0.0.110/invoice 0.18

Add CHANGELOG entry for 0.0.110

Drop unused test code in `lightning-invoice::payment`

Fix new compilation warnings in `debug_sync` module

Merge pull request #1631 from dunxen/2022-07-disabledflags

Specify why flags for `channel_disabled` error are zero

Specify why flags for `channel_disabled` error are zero

We can remove the TODO for this and specify why the flags are zero
as it's now fully specified in BOLT 4.

See https://github.com/lightning/bolts/blob/341ec84/04-onion-routing.md?plain=1#L1008

Merge pull request #1403 from jurvis/jurvis/add-paymentforwardingfailed-event

Add HTLCHandlingFailed event

Merge pull request #1617 from TheBlueMatt/2022-07-base-ppm

Add a per-amount base penalty in the ProbabilisticScorer

Merge pull request #1626 from TheBlueMatt/2022-07-fix-pm-docs

Remove scary disconenct warnings on PeerManager new connection fns

Merge pull request #1611 from TheBlueMatt/2022-07-lower-bounded-estimator-nit

Use a separate (non-trait) fee-estimation fn in LowerBoundedEstimator

Merge pull request #1519 from tnull/2022-06-require-htlc-max

Make `htlc_maximum_msat` a required field.

Rename amount penalty to `liquidity_penalty_amount_multiplier_msat`

This makes our `ProbabilisticScorer` field names more consistent,
as we add more types of penalties, referring to a penalty as only
the "amount penalty" no longer makes sense - we not have several
amount multiplier penalties.

Add a per-amount base penalty in the `ProbabilisticScorer`

There's not much reason to not have a per-hop-per-amount penalty in
the `ProbabilisticScorer` to go along with the per-hop penalty to
let it scale up to larger amounts, so we add one here.

Notably, we use a divisor of 2^30 instead of 2^20 (like the
equivalent liquidity penalty) as it allows for more flexibility,
and there's not really any reason to worry about us not being able
to create high enough penalties.

Closes #1616

Test serialization of `ChannelInfo` and `NodeInfo`

Don't fail read `NodeInfo` for inv. `NetAddress`

Fixes a deserialization incompatibility introduced with #1553.

Make `htlc_maximum_msat` a required field.

Change `LowerBoundedFeeEstimator` fn name to make it hard to swap

This change the method name on `LowerBoundedFeeEstimator` to
further differentiate it from the generic `FeeEstimator` trait.

Avoid blanket implementing FeeEstimator for Deref<FeeEstimator>

This simplifies things for bindings (and, to some extent,
downstream users) by exploiting the fact that we can always "clone"
a reference to a struct by dereferencing and then creating a new
reference.

Use a separate (non-trait) fee-estimation fn in LowerBoundedEstimator

This should make it somewhat more difficult to accidentally use a
straight fee estimator when we actually want a
LowerBoundedFeeEstimator by not having the types be exchangeable at
all.

Send failure event if we fail to handle a HTLC

In `ChannelManager::fail_htlc_backwards_internal`, we push a `HTLCHandlingFailed`
containing some information about the HTLC

Remove scary disconenct warnings on PeerManager new connection fns

In 4703d4e72565ddfd150b9368ea036f4973fd7590 we changed
PeerManager::socket_disconnected to no longer require that sockets
which the PeerManager decided to disconnect not be disconnected.
However, we forgot to remove the scary warnings on the
`new_{inbound,outbound}_connection` functions which warned of the
old behavior.

We do so here.

Add utils to handle HTLC handling failure reason

We add `HTLCHandlingFailedConditions` to express the failure parameters,
that will be enforced by a new macro, `expect_pending_htlcs_forwardable_conditions`.

Add HTLCHandlingFailed event

Adds a HTLCHandlingFailed that expresses failure by our node to process
a specific HTLC. A HTLCDestination enum is defined to express the
possible cases that causes the handling to fail.

Merge pull request #1627 from dunxen/2022-07-reusevalidatepowblockhash

Reuse `BlockHash` from `validate_pow()`

Reuse `BlockHash` from `validate_pow()`

The `validate_pow()` method now returns the BlockHash since rust-bitcoin
v0.26.2 thanks to jkczyz's PR (rust-bitcoin/rust-bitcoin/pull/572).

Merge pull request #1420 from TheBlueMatt/2022-04-moar-lockorder

Expand lockorder testing to look at mutexes, not specific instances

Swap `HashSet`s with custom `Hash` in debug_sync for `HashMap`s

Expand lockorder testing to look at mutexes, not specific instances

Our existing lockorder inversion checks look at specific instances
of mutexes rather than the general mutex itself. This changes that
behavior to look at the instruction pointer at which a mutex was
created and treat all mutexes which were created at the same
location as equivalent.

This allows us to detect lockorder inversions which occur across
tests, though it does substantially reduce parallelism during test
runs.

Construct all ChannelMonitor mutexes in the same function

When we add lockorder detection based on mutex construction site
rather than mutex instance in the next commit, ChannelMonitor's
PartialEq implementation causes spurious failures. This is caused
by the lockorder detection logic considering the ChannelMonitor
inner mutex to be two distinct mutexes - one when monitors are
deserialized and one when monitors are created fresh. Instead, we
attempt to tell the lockorder detection logic that they are the
same by ensuring they're constructed in the same place - in this
case a util method.