Merge pull request #841 from valentinewallace/207-replacement

Expose counterparty forwarding info in ChannelDetails

Expose counterparty forwarding info in ChannelDetails.

Useful for constructing route hints for private channels in invoices.

Co-authored-by: Valentine Wallace <vwallace@protonmail.com>
Co-authored-by: Antoine Riard <ariard@student.42.fr>

Pass channel updates to ChannelManager and Channel.

This will be used to expose forwarding info for route hints in the next commit.

Co-authored-by: Valentine Wallace <vwallace@protonmail.com>
Co-authored-by: Antoine Riard <ariard@student.42.fr>

Add CounterpartyForwardingInfo field to channel.

This will be filled in in upcoming commits, then exposed in ChannelDetails
to allow constructing route hints for invoices.

Also update the cltv_expiry_deta comment in msgs::ChannelUpdate

Co-authored-by: Valentine Wallace <vwallace@protonmail.com>
Co-authored-by: Antoine Riard <ariard@student.42.fr>

Merge pull request #828 from bmancini55/reply_channel_range

Handle query_channel_range gossip queries

Simplify sequencing of handle_query_channel_range

Modify NetGraphMsgHandler::handle_query_channel_range to always use
first_blocknum=0 in replies. This is spec compliant after changes to
make sequence completion explicity using sync_complete.

Comment cleanup for handling query_channel_range

Cleans up NetGraphMsgHandler::handle_query_channel_range

Use constant MAX_REPLY_SCID

Modifies NetGraphMsgHandler::handle_query_channel_range to use a constant
max value in replies. Modifies tests to generate 8000 channels instead
of making this value configurable.

Merge pull request #836 from valentinewallace/invoice-features-methods

Add methods to set invoice features in Features objects.

Add methods to set features in Features objects.

Merge pull request #837 from TheBlueMatt/2021-03-0.0.13

Use constant in QueryChannelRange::end_blocknum

Clarifies u32 max value used as the default.

Merge pull request #834 from TheBlueMatt/2021-03-no-pub-internals

Make `util::logger::macro_logger` pub(crate) not pub.

Update licenses and add missing fields in Cargo.toml files

Add missing feature to background-processor dev-dependencies

Clean up iteration in handle_query_channel_range

Refactor to use an enumerator in NetGraphMsgHandler::handle_query_channel_range

Merge pull request #835 from TheBlueMatt/2021-03-0.0.13

Bump Version to 0.0.13

Use scid_from_parts in Channel::block_connected

Refactors validation and short_channel_id construction to use
the new scid_from_parts function.

Improve short_channel_id utils

Modifies scid_from_parts to use u64 inputs allowing untruncated
validation. Adds public constants for limits.

Bump versions to 0.0.13 across the board

We also skip having different versions for different subcrates,
since that is confusing.

Rename `background-processor` to `lightning-background-processor`

This matches our naming scheme better and fits better on crates.io.
Also drop the version to 0.0.1 to match our versioning scheme
better.

Merge pull request #827 from TheBlueMatt/2021-03-invoice-features

Disable MPP routing when the payee does not support it

Merge pull request #826 from valentinewallace/raise-max-to-self-delay

Raise max to_self_delay.

Raise max to_self_delay.

lnd requires this to_self_delay for the max channel size
(excluding wumbo).

Split router benchmark into an MPP and a non-MPP route benchmark

Disable MPP routing when the payee does not support it

Add an Option<>al InvoiceFeatures object for the payee in get_route

We currently only use it to override the graph-specific features
returned in the route, though we should also use it to enable or
disable MPP.

Note that tests which relied on MPP behavior have had all of their
get_route calls upgraded to provide the MPP flag.

Merge pull request #833 from TheBlueMatt/2021-03-no-xs

Drop C bindings (which are now in a separate repo)

Merge pull request #830 from TheBlueMatt/2021-03-chanmon-deser-utils

Make chain::Filter slightly easier with some ChannelMonitor utilities.

Make `util::logger::macro_logger` pub(crate) not pub.

There is no reason for it to be pub, its a largely-internal
implementation detail of how we format our own objects for logging.

Drop C bindings (which are now in a separate repo)

This allows us to drop the usually-failing C bindings CI check, and
makes Github code search more useful by dropping redundant things.

Create new `InvoiceFeatures` object for Invoice-specific features

In the past we skipped doing this since invoice parsing occurs in a
different crate. However, we need to accept InvoiceFeatures in routing
now that we support MPP route collection, to detect if we can select
multiple paths or not. Further, we should probably take
rust-lightning-invoice as either a module or a subcrate in this repo.

Add codecov.yml allowing coverage to drop slightly before "failing"

This should remove one big red X in our builds, making it harder
to miss other failing tests.

Merge pull request #832 from jkczyz/2021-03-typo-fix

Fix misspelling of 'occurred' in public interface

Use the new `load_outputs_to_watch` util in `ChainMonitor`

This is slightly more effecient as it avoids a clone, but its also
nice to use our own code more.

Make `get_outputs_to_watch` return a `Vec` instead of a `HashMap`

`get_outputs_to_watch` returned a reference to an existing
`HashMap` avoiding extra clones, but there isn't a huge reason to
do so now that we have to clone to copy it out of the
`ChannelMonitor` mutex. Instead, return a `Vec` since it may be
less memory and it allows us to have a bindings C mapping for the
function.

Co-authored-by: Jeffrey Czyz <jkczyz@gmail.com>
Co-authored-by: Matt Corallo <git@bluematt.me>

Fix misspelling of 'occurred' in public interface

Merge pull request #829 from TheBlueMatt/2021-03-0.0.13-bindings

0.0.13 Bindings Updates

Auto-generated bindings updates

[bindings] Check for a wasm32 target before compiling in genbindings

[bindings] Update demos for new upstream API

Make IgnoringMessageHandler and ErroringMessageHandler pub

This is largely useful for bindings, and the off-github discussion
around #814 concluded these should be pub, but the PR was not
updated to capture this. Now that the bindings support generation
for the structs, expose them.

[bindings] Handle ::-containing paths in generics

Specifically, this is required for some paths which use
`Option<msgs::Message>`.

[bindings] Be explicit when calling pointer.is_null()

When the (somewhat anti-pattern)
`impl Deref for X { type Target = X; .. }` is used, this avoids an
infinite dereference exception trying to figure out what type to
resolve `is_null` against.

[bindings] Avoid double-use'ing traits by writing out the path

Change ChannelManager::wait to be more descriptive

`wait` doesn't capture enough of what's going on, but also Java
Java doesn't accpet methods just called `wait`, as it conflicts
with existing sync primitives on all Objects.

Add utility in `ChannelMonitor` to reload `chain::Filter` data

The deserialization process for `ChannelManager`/`ChannelMonitor`
data includes reloading any relevant `chain::Filter` with data
provided from the `ChannelMonitor`, but its nice if we adapt the
data to `chain::Filter` calls for users.

[bindings] Support converting Network to rust, update variants

Merge pull request #823 from jkczyz/2021-03-birthday-hash

Replace default hash with birthday hash

Correctly update the last block hash on disconnect

When a block is disconnected, the hash of the disconnected block was
used to update the last connected block. However, this amounts to a
no-op because these hashes should be equal. Successive disconnections
would update the hash but leave it one block off.

Normally, this not a problem because the last block_disconnected should
be followed by block_connected since the former is triggered by a chain
re-org. However, this assumes the user calls the API correctly and that
no failure occurs that would prevent block_connected from being called
(e.g., if fetching the connected block fails).

Instead, update the last block hash with the disconnected block's
previous block hash.

Hold ChannelManager locks independently

ChannelManager reads channel_state and last_block_hash while processing
funding_created and funding_signed messages. It writes these while
processing block_connected and block_disconnected events. To avoid any
potential deadlocks, have each site hold these locks independent of one
another and in a consistent order.

Additionally, use a RwLock instead of Mutex for last_block_hash since
exclusive access is not needed in funding_created / funding_signed and
cannot be guaranteed in block_connected / block_disconnected because of
the reads in the former.

Rename header_hash to block_hash

Pass along ChannelManager's last_block_hash

ChannelMonitor keeps track of the last block connected. However, it is
initialized with the default block hash, which is a problem if the
ChannelMonitor is serialized before a block is connected. Instead, pass
ChannelManager's last_block_hash, which is initialized with a "birthday"
hash, when creating a new ChannelMonitor.

Remove last_block_connected from Channel

Tracking the last block was only used to de-duplicate block_connected
calls, but this is no longer required as of the previous commit.
Further, the ChannelManager can pass the latest block hash when needing
to create a ChannelMonitor rather than have each Channel maintain an
up-to-date copy. This is implemented in the next commit.

Remove block_connected de-duplication logic

Calling block_connected for the same block was necessary when clients
were expected to re-fetch filtered blocks with relevant transactions. At
the time, all listeners were notified of the connected block again for
re-scanning. Thus, de-duplication logic was put in place.

However, this requirement is no longer applicable for ChannelManager as
of commit bd39b20f642e042981e4fdd5f3600a357be51931, so remove this
logic.

Parameterize ChannelManager::new with a block hash

When ChannelMonitors are persisted, they need to store the most recent
block hash seen. However, for newly created channels the default block
hash is used. If persisted before a block is connected, the funding
output may be missed when syncing after a restart. Instead, initialize
ChannelManager with a "birthday" hash so it can be used later when
creating channels.

Handle query_channel_range message from peer

Initial implementation of handling query_channel_range messages in
NetGraphMsgHandler.  Enqueues a sequence of reply message in the pending
message events buffer.

Update docs with correct hash type

Co-authored-by: Matt Corallo <git@bluematt.me>
Co-authored-by: Jeffrey Czyz <jkczyz@gmail.com>

Revert "Merge pull request #819 from TheBlueMatt/2021-03-810-rebased"

This reverts commit 793de5fe6944bb6ab414934e53a7ae80bb5a9a31, reversing
changes made to 03a518965100b6852f36e4f95ead4c1d93f5c4b0.

Merge pull request #808 from TheBlueMatt/2021-02-791-order-fix

Process monitor update events in block_[dis]connected asynchronously

Create short_channel_id utils

Util converts parts into u64 SCID
Util extracts block height from u64 SCID

Both will be used when processing gossip_query messages.

Add end_blocknum method to query_channel_range

Overflow safe calculation of the ending block number for a query. Can
be used when processing the query.

Add SendReplyChannelRange message event

Creates a MessageSendEvent for sending a reply_channel_range message.
This event will be fired when handling inbound query_channel_range
messages in the NetGraphMessageHandler.

Clarify ChannelManager docs somewhat around full blocks

As suggested by Val.

Expand tests to cover serialization with pending background events

Process monitor update events in block_[dis]connected asynchronously

The instructions for `ChannelManagerReadArgs` indicate that you need
to connect blocks on a newly-deserialized `ChannelManager` in a
separate pass from the newly-deserialized `ChannelMontiors` as the
`ChannelManager` assumes the ability to update the monitors during
block [dis]connected events, saying that users need to:
```
4) Reconnect blocks on your ChannelMonitors
5) Move the ChannelMonitors into your local chain::Watch.
6) Disconnect/connect blocks on the ChannelManager.
```

This is fine for `ChannelManager`'s purpose, but is very awkward
for users. Notably, our new `lightning-block-sync` implemented
on-load reconnection in the most obvious (and performant) way -
connecting the blocks all at once, violating the
`ChannelManagerReadArgs` API.

Luckily, the events in question really don't need to be processed
with the same urgency as most channel monitor updates. The only two
monitor updates which can occur in block_[dis]connected is either
a) in block_connected, we identify a now-confirmed commitment
   transaction, closing one of our channels, or
b) in block_disconnected, the funding transaction is reorganized
   out of the chain, making our channel no longer funded.
In the case of (a), sending a monitor update which broadcasts a
conflicting holder commitment transaction is far from
time-critical, though we should still ensure we do it. In the case
of (b), we should try to broadcast our holder commitment transaction
when we can, but within a few minutes is fine on the scale of
block mining anyway.

Note that in both cases cannot simply move the logic to
ChannelMonitor::block[dis]_connected, as this could result in us
broadcasting a commitment transaction from ChannelMonitor, then
revoking the now-broadcasted state, and only then receiving the
block_[dis]connected event in the ChannelManager.

Thus, we move both events into an internal invent queue and process
them in timer_chan_freshness_every_min().

Merge pull request #825 from jkczyz/2021-03-client-visibility

Expose RpcClient and RestClient interfaces as pub

Merge pull request #821 from jkczyz/2021-03-fix-build-warnings

Fix build warnings

Expose RpcClient and RestClient interfaces as pub

Useful for use outside of the BlockSource context, e.g., when
implementing fee estimation or transaction broadcasting.

Fix build warnings

Change ShutdownResult type to better capture the possibilites

The return value from Channel::force_shutdown previously always
returned a `ChannelMonitorUpdate`, but expected it to only be
applied in the case that it *also* returned a Some for the funding
transaction output.

This is confusing, instead we move the `ChannelMontiorUpdate`
inside the Option, making it hold a tuple instead.

Add a few notes about deserializing stale ChannelManagers

See diff for more details

Fix indentation in test_htlc_no_detection

Move functional tests involving reorgs to reorg_test

functional_tests.rs is huge, so anything we can do to split it up
some is helpful. This also exposes a somewhat glaring lack of
reorgs in our existing tests.

Merge pull request #646 from naumenkogs/2020-06-router-mpp

MPP on the router side

Merge pull request #819 from TheBlueMatt/2021-03-810-rebased

Change ChannelManager deserialization to return an optional blockhash

Merge pull request #818 from jkczyz/2021-03-validate-best-block-header

Add validate_best_block_header utility

Merge pull request #816 from valentinewallace/remove-simple-outer-arcs

Remove simple outer arcs

Don't underpay htlc_min due to path contribution

We could have possibly constructed a slightly inconsistent
path: since we reduce value being transferred all the way, we
could have violated htlc_minimum_msat on some channels
we already passed (assuming dest->source direction). Here,
we recompute the fees again, so that if that's the case, we
match the currently underpaid htlc_minimum_msat with fees.

Update docs to use the new deserialization  requirements

Change ChannelMonitor deserialization to return an optional blockhash.

See previous commit msg for details.

Change ChannelManager deserialization to return an optional blockhash

If the ChannelManager never receives any blocks, it'll return a default blockhash
on deserialization. It's preferable for this to be an Option instead.

Mind htlc_minimum_msat when truncating overpaid value

At truncating the overpaid value, if we fall below
htlc_minimum_msat, reach it by increasing fees.

Use outbound_capacity_msat from first_hops for routing

Implement finding paths for MPP

Add validate_best_block_header utility

Refactor synchronize_listeners by pulling out a function returning the
validated block header of a BlockSource's best chain tip. This is needed
when a node is started from scratch and has no listeners to sync.

Merge pull request #814 from TheBlueMatt/2021-03-optional-handlers

Provide Dummy routing and channel message handlers for users

Merge pull request #813 from jkczyz/2021-02-channel-monitor-mutex

Use interior mutability in ChannelMonitor

Implement chain::Listen without using RefCell

The implementation of chain::Listen for ChannelMonitor required using a
RefCell since its block_connected method required a mutable borrow. This
is no longer the case since ChannelMonitor now uses interior mutability
via a Mutex. So the RefCell is no longer needed.

Change Mutex to RwLock in ChainMonitor

Now that ChannelMonitor uses an internal Mutex to support interior
mutability, ChainMonitor can use a RwLock to manage its ChannelMonitor
map. This allows parallelization of update_channel operations since an
exclusive lock only needs to be held when adding to the map in
watch_channel.

Use consistent variable naming in ChainMonitor

Move ChannelMonitor state behind a Mutex

ChainMonitor accesses a set of ChannelMonitors behind a single Mutex.
As a result, update_channel operations cannot be parallelized. It also
requires using a RefCell around a ChannelMonitor when implementing
chain::Listen.

Moving the Mutex into ChannelMonitor avoids these problems and aligns it
better with other interfaces. Note, however, that get_funding_txo and
get_outputs_to_watch now clone the underlying data rather than returning
references.

Add utility constructors to PeerHandler to use a dummy handler

Provide Dummy routing and channel message handlers for users

We currently "support" not having a router or channel in memory by
forcing users to implement the same, but its trivial to provide our
own dummy implementations.

Merge pull request #811 from TheBlueMatt/2021-02-bindings-rust-bump

Update bindings for new Listen interface

Add simple README about our C bindings generation stuff

[bindings] Build a wasm32-wasi library in genbindings.sh

This will switch to use the clang/C WASM ABI instead of the
wasm_bindgen WASM ABI as of rustc 1.51 (or nightly since [1]),
allowing us to link C and Rust code in a single wasm binary.

[1] https://github.com/rust-lang/rust/pull/79998

Update auto-generated bindings

[bindings] Be explicit when calling trait methods in generated code

For ChannelManager, at least, we have two separate functions called
block_connected, one in the Listen trait, one in the struct, we
need to be explicit with which one we're trying to call.

Fix doc typo introduced in the ChannelKeys->Sign renaming