Merge pull request #2065 from TheBlueMatt/2023-02-0.0.114

Cut 0.0.114

Update crate versions to 0.0.114/invoice 0.22

Add release notes for 0.0.114

Merge pull request #2072 from jkczyz/2023-01-fix-scoring-div-by-zero

Fix division by zero in `ProbabilisticScorer`

Merge pull request #2071 from TheBlueMatt/2023-01-fix-fast-extra-ready-panic

Fix panic on receiving `channel_ready` after 1st commitment update

Use ProbabilisticScorer in router fuzzing, to cover overflows there

Guard against division by zero in scorer

Since a node may announce that the htlc_maximum_msat of a channel is
zero, adding one to the denominator in the bucket formulas will prevent
the panic from ever happening. While the routing algorithm may never
select such a channel to score, this precaution may still be useful in
case the algorithm changes or if the scorer is used with a different
routing algorithm.

Update scoring history buckets when no change

Even when there is no change in min/max liquidity knowledge, tracking
should still be updated to include the additional data point.

Merge pull request #2068 from jkczyz/2023-03-doc-fixes

Doc and build warning fixes

Merge pull request #2069 from TheBlueMatt/2023-03-no-tx-sync-auto-std

Do not auto-select the lightning `std` feature from tx-sync crate

Merge pull request #2070 from TheBlueMatt/2023-03-get-key

Expose the node secret key in `{Phantom,}KeysManager`

Fix build warnings

Add more documentation about BlockSourceError

Some BlockSource implementations provide more error details. Document
this in case users want to examine it further.

Expose the node secret key in `{Phantom,}KeysManager`

When we removed the private keys from the signing interface we
forgot to re-add them in the public interface of our own
implementations, which users may need.

Merge pull request #2067 from benthecarman/fix-typos

Fix typos in lightning-transaction-sync

Merge pull request #2066 from TheBlueMatt/2023-02-no-enum-refs

Pass `FailureCode` to `fail_htlc_backwards` by ownership

Merge pull request #2048 from TheBlueMatt/2023-02-send-persist-order-a

Track claimed outbound HTLCs in ChannelMonitors

Do not auto-select the lightning `std` feature from tx-sync crate

We have some downstream folks who are using LDK in wasm compiled
via the normal rust wasm path. To ensure nothing breaks they want
to use `no-std` on the lightning crate, disabling time calls as
those panic. However, the HTTP logic in
`lightning-transaction-sync` gets automatically stubbed out by the
HTTP client crates when targeting wasm via `wasm_bindgen`, so it
works fine despite the std restrictions.

In order to make both work, `lightning-transaction-sync` can remain
`std`, but needs to not automatically enable the `std` flag on the
`lightning` crate, ie by setting `default-features = false`. We do
so here.

Pass `FailureCode` to `fail_htlc_backwards` by ownership

`FaliureCode` is a trivial enum with no body, so we shouldn't be
passing it by reference. Its sufficiently strange that the Java
bindings aren't happy with it, which is fine, we should just fix it
here.

Remove unused compat block in `provide_latest_holder_commitment_tx`

Track claimed outbound HTLCs in ChannelMonitors

When we receive an update_fulfill_htlc message, we immediately try
to "claim" the HTLC against the HTLCSource. If there is one, this
works great, we immediately generate a `ChannelMonitorUpdate` for
the corresponding inbound HTLC and persist that before we ever get
to processing our counterparty's `commitment_signed` and persisting
the corresponding `ChannelMonitorUpdate`.

However, if there isn't one (and this is the first successful HTLC
for a payment we sent), we immediately generate a `PaymentSent`
event and queue it up for the user. Then, a millisecond later, we
receive the `commitment_signed` from our peer, removing the HTLC
from the latest local commitment transaction as a side-effect of
the `ChannelMonitorUpdate` applied.

If the user has processed the `PaymentSent` event by that point,
great, we're done. However, if they have not, and we crash prior to
persisting the `ChannelManager`, on startup we get confused about
the state of the payment. We'll force-close the channel for being
stale, and see an HTLC which was removed and is no longer present
in the latest commitment transaction (which we're broadcasting).
Because we claim corresponding inbound HTLCs before updating a
`ChannelMonitor`, we assume such HTLCs have failed - attempting to
fail after having claimed should be a noop. However, in the
sent-payment case we now generate a `PaymentFailed` event for the
user, allowing an HTLC to complete without giving the user a
preimage.

Here we address this issue by storing the payment preimages for
claimed outbound HTLCs in the `ChannelMonitor`, in addition to the
existing inbound HTLC preimages already stored there. This allows
us to fix the specific issue described by checking for a preimage
and switching the type of event generated in response. In addition,
it reduces the risk of future confusion by ensuring we don't fail
HTLCs which were claimed but not fully committed to before a crash.

It does not, however, full fix the issue here - because the
preimages are removed after the HTLC has been fully removed from
available commitment transactions if we are substantially delayed
in persisting the `ChannelManager` from the time we receive the
`update_fulfill_htlc` until after a full commitment signed dance
completes we may still hit this issue. The full fix for this issue
is to delay the persistence of the `ChannelMonitorUpdate` until
after the `PaymentSent` event has been processed. This avoids the
issue entirely, ensuring we process the event before updating the
`ChannelMonitor`, the same as we ensure the upstream HTLC has been
claimed before updating the `ChannelMonitor` for forwarded
payments.

The full solution will be implemented in a later work, however this
change still makes sense at that point as well - if we were to
delay the initial `commitment_signed` `ChannelMonitorUpdate` util
after the `PaymentSent` event has been processed (which likely
requires a database update on the users' end), we'd hold our
`commitment_signed` + `revoke_and_ack` response for two DB writes
(i.e. `fsync()` calls), making our commitment transaction
processing a full `fsync` slower. By making this change first, we
can instead delay the `ChannelMonitorUpdate` from the
counterparty's final `revoke_and_ack` message until the event has
been processed, giving us a full network roundtrip to do so and
avoiding delaying our response as long as an `fsync` is faster than
a network roundtrip.

Reference `Router` in `ChannelManager` docs

DRY up historical bucket_idx calculation

Fix scorer panic when available capacity is zero

ProbabilisticScorer takes a ChannelUsage when computing a penalty for a
channel. The formula for calculating the liquidity penalty reduces the
maximum capacity by the amount of in-flight HTLCs (available capacity)
and adds one to prevent division by zero.

However, since the available capacity is passed to
DirectedChannelLiquidity as the capacity, other penalty formulas may use
the available (i.e., reduced) capacity inadvertently. In practice, this
has two ramifications for the historical liquidity penalty computation:

1. The bucket formula doesn't have a consistent denominator for a given
   channel.
2. The bucket formula may divide by zero when the in-flight HTLC amount
   equals or exceeds the effective capacity.

Fixing this involves only using the available capacity when appropriate.

Fix typos in lightning-transaction-sync

Merge pull request #2060 from TheBlueMatt/2023-02-peers-disconnect-consistency

Remove peers from the node_id_to_descriptor even without init

Avoid removing stale preimages when hashes collide in fuzzing

Fuzz rapid peer connection/disconnections in threads

This test fails on the bug fixed two commits ago with the
additional assertions in the previous commit.

Improve `PeerHandler` debug_assertions and checks

This removes two panics from `PeerHandler` which can trivially be
`debug_assert!(false); return Err;`s, and adds another
`debug_assertion` on internal state consistency during disconnect.

Merge pull request #2064 from TheBlueMatt/2023-03-debug-futures

Make waking after a future completes propagates to the next future

Merge pull request #2057 from johncantrell97/rpc-error-code

Surface bitcoind rpc error information

Make waking after a future completes propagates to the next future

In our `wakers`, if we first `notify` a future, which is then
`poll`ed complete, and then `notify` the same waker again before a
new future is fetched, that new future will be marked as
non-complete initially and wait for a third `notify`.

The fix is luckily rather trivial, when we `notify` a future, if it
is completed immediately, simply wipe the future state so that we
look at the pending-notify flag when we generate the next future.

Merge pull request #2061 from TheBlueMatt/2023-02-114-upstream-bindings

`C-not exported` tags for 0.0.114

Tag types used for the TLV macros with `(C-not exported)`

Obviously bindings users can't use the Rust TLV-implementation
macros, so there's no reason to export typsed used exclusively by
them.

Mark `IndexedMap` types as `(C-not exported)`

While we could try to expose the type explicitly, we already have
alternative accessors for bindings, and mapping `Hash`, `Ord` and
the other requirements for `IndexedMap` would be a good chunk of
additional work.

Remove peers from the `node_id_to_descriptor` even without init

When a peer has finished the noise handshake, but has not yet
completed the lightning `Init`-based handshake, they will be
present in the `node_id_to_descriptor` set, even though
`Peer::handshake_complete()` returns false. Thus, when we go to
disconnect such a peer, we must ensure that we remove it from the
descriptor set as well.

Failing to do so caused an `Inconsistent peers set state!` panic in
the C bindings network handler.

Merge pull request #2046 from TheBlueMatt/2023-02-rgs-robust-and-log

Do not fail to apply RGS updates for removed channels

Surface bitcoind rpc error code

Users of the RpcClient had no way to access the error code
returned by bitcoind's rpc.  We embed a new RpcError struct
as the inner error for the returned io::Error. Users can access
both the code and the message using this inner struct.

Add some basic logging to Rapid Gossip Sync processing

Make log macros more usable outside of the `lightning` crate

... by using explicit paths rather than requiring imports.

Do not fail to apply RGS updates for removed channels

If we receive a Rapid Gossip Sync update for channels where we are
missing the existing channel data, we should ignore the missing
channel. This can happen in a number of cases, whether because we
received updated channel information via an onion error from an
HTLC failure or because we've partially synced the graph from a
peer over the standard lightning P2P protocol.

Merge pull request #2006 from TheBlueMatt/2023-02-no-recursive-read-locks

Refuse recursive read locks

Merge pull request #2015 from TheBlueMatt/2023-02-no-dumb-redundant-fields

Make sure individual mutexes are constructed on different lines

Our lockdep logic (on Windows) identifies a mutex based on which
line it was constructed on. Thus, if we have two mutexes
constructed on the same line it will generate false positives.

Export RUST_BACKTRACE=1 in `--feature backtrace` CI test

as this test often fails on windows which is hard to debug locally
for most contributors.

Disallow taking two instances of the same mutex at the same time

Taking two instances of the same mutex may be totally fine, but it
requires a total lockorder that we cannot (trivially) check. Thus,
its generally unsafe to do if we can avoid it.

To discourage doing this, here we default to panicing on such locks
in our lockorder tests, with a separate lock function added that is
clearly labeled "unsafe" to allow doing so when we can guarantee a
total lockorder.

This requires adapting a number of sites to the new API, including
fixing a bug this turned up in `ChannelMonitor`'s `PartialEq` where
no lockorder was guaranteed.

Refuse recursive read locks in lockorder testing

Our existing lockorder tests assume that a read lock on a thread
that is already holding the same read lock is totally fine. This
isn't at all true. The `std` `RwLock` behavior is
platform-dependent - on most platforms readers can starve writers
as readers will never block for a pending writer. However, on
platforms where this is not the case, one thread trying to take a
write lock may deadlock with another thread that both already has,
and is attempting to take again, a read lock.

Worse, our in-tree `FairRwLock` exhibits this behavior explicitly
on all platforms to avoid the starvation issue.

Thus, we shouldn't have any special handling for allowing recursive
read locks, so we simply remove it here.

Don't `per_peer_state` read locks recursively in monitor updating

When handling a `ChannelMonitor` update via the new
`handle_new_monitor_update` macro, we always call the macro with
the `per_peer_state` read lock held and have the macro drop the
per-peer state lock. Then, when handling the resulting updates, we
may take the `per_peer_state` read lock again in another function.

In a coming commit, recursive read locks will be disallowed, so we
have to drop the `per_peer_state` read lock before calling
additional functions in `handle_new_monitor_update`, which we do
here.

Expect callers to hold read locks before `channel_monitor_updated`

Our existing lockorder tests assume that a read lock on a thread
that is already holding the same read lock is totally fine. This
isn't at all true. The `std` `RwLock` behavior is
platform-dependent - on most platforms readers can starve writers
as readers will never block for a pending writer. However, on
platforms where this is not the case, one thread trying to take a
write lock may deadlock with another thread that both already has,
and is attempting to take again, a read lock.

Worse, our in-tree `FairRwLock` exhibits this behavior explicitly
on all platforms to avoid the starvation issue.

Sadly, a user ended up hitting this deadlock in production in the
form of a call to `get_and_clear_pending_msg_events` which holds
the `ChannelManager::total_consistency_lock` before calling
`process_pending_monitor_events` and eventually
`channel_monitor_updated`, which tries to take the same read lock
again.

Luckily, the fix is trivial, simply remove the redundand read lock
in `channel_monitor_updated`.

Fixes #2000

Hold the `total_consistency_lock` while in `outbound_payment` fns

We previously avoided holding the `total_consistency_lock` while
doing crypto operations to build onions. However, now that we've
abstracted out the outbound payment logic into a utility module,
ensuring the state is consistent at all times is now abstracted
away from code authors and reviewers, making it likely to break.

Further, because we now call `send_payment_along_path` both with,
and without, the `total_consistency_lock`, and because recursive
read locks may deadlock, it would now be quite difficult to figure
out which paths through `outbound_payment` need the lock and which
don't.

While it may slow writes somewhat, it's not really worth trying to
figure out this mess, instead we just hold the
`total_consistency_lock` before going into `outbound_payment`
functions.

Remove the `final_cltv_expiry_delta` in `RouteParameters` entirely

fbc08477e8dcdd8f3f2ada8ca77388b6185febe2 purported to "move" the
`final_cltv_expiry_delta` field to `PaymentParamters` from
`RouteParameters`. However, for naive backwards-compatibility
reasons it left the existing on in place and only added a new,
redundant field in `PaymentParameters`.

It turns out there's really no reason for this - if we take a more
critical eye towards backwards compatibility we can figure out the
correct value in every `PaymentParameters` while deserializing.

We do this here - making `PaymentParameters` a `ReadableArgs`
taking a "default" `cltv_expiry_delta` when it goes to read. This
allows existing `RouteParameters` objects to pass the read
`final_cltv_expiry_delta` field in to be used if the new field
wasn't present.

Support `ReadableArgs` types across in the TLV struct serialization

This adds `required` support for trait-wrapped reading (e.g. for
objects read via `ReadableArgs`) as well as support for the
trait-wrapped reading syntax across the TLV struct/enum
serialization macros.

Require a non-0 number of non-empty paths when deserializing routes

When we read a `Route` (or a list of `RouteHop`s), we should never
have zero paths or zero `RouteHop`s in a path. As such, its fine to
simply reject these at deserialization-time. Technically this could
lead to something which we can generate not round-trip'ing
serialization, but that seems okay here.

Merge pull request #2055 from TheBlueMatt/2023-02-fning-msrv

Remove the lightning-transaction-sync MSRV

Move `lightning-transaction-sync` out of the main workspace

Because `lightning-transaction-sync` does not have an MSRV (and
because its dev-dependencies are huge), we can't build it by
default when devs run `cargo test`, so it is moved out of the
top-level workspace.

Remove the `lightning-transaction-sync` MSRV

Apparently it has dependencies that don't track an MSRV at all, so
we can't practically enforce one in CI.

Fix silent rebase conflict in previous PR

Merge pull request #2043 from valentinewallace/2023-02-initial-send-path-fails

`PaymentPathFailed`: add initial send error details

Merge pull request #2033 from tnull/2023-02-make-esplora-sync-test-more-robust

Make `test_esplora_syncs` more robust

Merge pull request #2025 from TheBlueMatt/2023-02-no-pub-genesis-hashes

Remove genesis block hash from public API

Fix PaymentPathFailed generation and scid on initial send

Change PaymentPathFailed's optional network update to a Failure enum

This let us capture the errors when we fail without committing to an HTLC vs
failing via update_fail.

Implement writeable for APIError

ser_macros: Document behavior of upgradable_* variants

Fix upgradable_required fields to actually be required in lower level macros

When using lower level macros such as read_tlv_stream, upgradable_required
fields have been treated as regular options. This is incorrect, they should
either be upgradable_options or treated as required fields.

Merge pull request #1977 from jkczyz/2023-01-offers-fuzz

BOLT 12 deserialization fuzzers

Rename OptionDeserWrapper->RequiredWrapper

Makes more sense and sets us up for the UpgradableRequired version of it

Disambiguate ignorable and ignorable_option

Would rather not rename ignorable to ignorable_required, so rename both of them
to upgradable_*

Support deserializing an Option-al MaybeReadable

Prior to this change, our impl_writeable_tlv_based macros only supported
deserializing a MaybeReadable if it's non-Optional.

Remove all_paths_failed from PaymentPathFailed

This field was previous useful in manual retries for users to know when all
paths of a payment have failed and it is safe to retry. Now that we support
automatic retries in ChannelManager and no longer support manual retries, the
field is no longer useful.

For backwards compat, we now always write false for this field. If we didn't do
this, previous versions would default this field's value to true, which can be
problematic because some clients have relied on the field to indicate when a
full payment retry is safe.

Merge pull request #2050 from douglaz/import-lightning-io-futures

Only import lightning::io if futures are enabled

Only import lightning::io if futures are enabled

Make `test_esplora_syncs` more robust

The test generally works and the parts in question *should* never fail.
However, they did, so we give the test server instances some leeway.

Fix amount overflow in Invoice building

An overflow can occur when multiplying the offer amount by the requested
quantity when no amount is given in the request. Return an error instead
of overflowing.

Fix amount overflow in Offer parsing and building

An overflow can occur when multiplying the offer amount by the requested
quantity when checking if the given amount is enough. Return an error
instead of overflowing.

Fuzz test for bech32 decoding

Fuzz testing bech32 decoding along with deserializing the underlying
message can result in overly exhaustive searches. Instead, the message
deserializations are now fuzzed separately. Add fuzzing for bech32
decoding.

Expose Bech32Encode trait for fuzzing

In order to fuzz test Bech32Encode parsing independent of the underlying
message deserialization, the trait needs to be exposed. Conditionally
expose it only for fuzzing.

Fuzz test for parsing Invoice

An invoice is serialized as a TLV stream and encoded as bytes. Add a
fuzz test that parses the TLV stream and deserializes the underlying
Invoice. Then compare the original bytes with those obtained by
re-serializing the Invoice.

Fuzz test for parsing InvoiceRequest

An invoice request is serialized as a TLV stream and encoded as bytes.
Add a fuzz test that parses the TLV stream and deserializes the
underlying InvoiceRequest. Then compare the original bytes with those
obtained by re-serializing the InvoiceRequest.

Rename `BestBlock::from_genesis` to `from_network` for clarity

Remove genesis block hash from public API

Forcing users to pass a genesis block hash has ended up being
error-prone largely due to byte-swapping questions for bindings
users. Further, our API is currently inconsistent - in
`ChannelManager` we take a `Bitcoin::Network` but in `NetworkGraph`
we take the genesis block hash.

Luckily `NetworkGraph` is the only remaining place where we require
users pass the genesis block hash, so swapping it for a `Network`
is a simple change.

Add missing import path in ser macro

Merge pull request #2014 from valentinewallace/2023-02-rework-partial-pmt-fail

Rework auto-retry send errors

Clarify Retry::Timeout vs PaymentParams::expiry_time in docs

Fix outdated PendingOutboundPayment::Abandoned docs

On initial send retries, avoid previously failed scids

Previously, we could have tried the same failed channels over and over until
retries are exhausted.

In-line retry_with_route method

Since it's only used one place now

Rework auto retry send errors

Prior to this, we returned PaymentSendFailure from auto retry send payment
methods. This implied that we might return a PartialFailure from them, which
has never been the case. So it makes sense to rework the errors to be a better
fit for the methods.

We're taking error handling in a totally different direction now to make it
more asynchronous, see send_payment_internal for more information.

Fix InvalidRoute error to be ChannelUnavailable

InvalidRoute is reserved for malformed routes, not routes where a channel or
its peer is unavailable

Merge pull request #1897 from TheBlueMatt/2022-11-monitor-updates-always-async

Always process `ChannelMonitorUpdate`s asynchronously

Don't generate a `ChannelMonitorUpdate` for closed chans on shutdown

The `Channel::get_shutdown` docs are very clear - if the channel
jumps to `Shutdown` as a result of not being funded when we go to
initiate shutdown we should not generate a `ChannelMonitorUpdate`
as there's no need to bother with the shutdown script - we're
force-closing anyway.

However, this wasn't actually implemented, potentially causing a
spurious monitor update for no reason.

Use the new monitor persistence flow for `funding_created` handling

Building on the previous commits, this finishes our transition to
doing all message-sending in the monitor update completion
pipeline, unifying our immediate- and async- `ChannelMonitor`
update and persistence flows.

Use new monitor persistence flow in funding_signed handling

In the previous commit, we moved all our `ChannelMonitorUpdate`
pipelines to use a new async path via the
`handle_new_monitor_update` macro. This avoids having two message
sending pathways and simply sends messages in the "monitor update
completed" flow, which is shared between sync and async monitor
updates.

Here we reuse the new macro for handling `funding_signed` messages
when doing an initial `ChannelMonitor` persistence. This provides
a similar benefit, simplifying the code a trivial amount, but
importantly allows us to fully remove the original
`handle_monitor_update_res` macro.

Always process `ChannelMonitorUpdate`s asynchronously

We currently have two codepaths on most channel update functions -
most methods return a set of messages to send a peer iff the
`ChannelMonitorUpdate` succeeds, but if it does not we push the
messages back into the `Channel` and then pull them back out when
the `ChannelMonitorUpdate` completes and send them then. This adds
a substantial amount of complexity in very critical codepaths.

Instead, here we swap all our channel update codepaths to
immediately set the channel-update-required flag and only return a
`ChannelMonitorUpdate` to the `ChannelManager`. Internally in the
`Channel` we store a queue of `ChannelMonitorUpdate`s, which will
become critical in future work to surface pending
`ChannelMonitorUpdate`s to users at startup so they can complete.

This leaves some redundant work in `Channel` to be cleaned up
later. Specifically, we still generate the messages which we will
now ignore and regenerate later.

This commit updates the `ChannelMonitorUpdate` pipeline across all
the places we generate them.

Move TODO from `handle_monitor_update_res` into `Channel`

The TODO mentioned in `handle_monitor_update_res` about how we
might forget about HTLCs in case of permanent monitor update
failure still applies in spite of all our changes. If a channel is
drop'd in general, monitor-pending updates may be lost if the
monitor update failed to persist.

This was always the case, and is ultimately the general form of the
the specific TODO, so we simply leave comments there

Handle `MonitorUpdateCompletionAction`s after monitor update sync

In a previous PR, we added a `MonitorUpdateCompletionAction` enum
which described actions to take after a `ChannelMonitorUpdate`
persistence completes. At the time, it was only used to execute
actions in-line, however in the next commit we'll start (correctly)
leaving the existing actions until after monitor updates complete.

Merge pull request #1988 from TheBlueMatt/2023-01-limited-chans

Limit the number of pending un-funded inbound channel

Limit the number of pending un-funded inbound channel

Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes #1889

Add an `inbound` flag to the `peer_connected` message handlers

Its useful for the message handlers to know if a peer is inbound
for DoS decision-making reasons.

Merge pull request #2035 from TheBlueMatt/2023-02-fix-no-con-discon

Fix (and DRY) the conditionals before calling peer_disconnected