Sanitize outgoing HTLC cltv_value

Document exactly our CLTV sanitization policy for final incoming HTLCs

We want to avoid a third-party channel closure, where a random node
by sending us a payment expiring at current height, would trigger our
onchain logic to close the channel due to a near-expiration.

PaymentReceived and unknown HTLC cancellation must happen before
LATENCY_GRACE_PERIOD_BLOCKS.

Document exactly our CLTV sanitization policy for incoming HTLCs

Merge pull request #441 from TheBlueMatt/2020-01-mpp

Multi-Path Payments

Pass Route to send_payment as a reference, not move

ChannelManager::send_payment stopped utilizing its ownership of the
Route with MPP (which, for readability, now clone()s the individual
paths when creating HTLCSource::OutboundRoute objects). While this
isn't ideal, it likely also makes sense to ensure that the user has
access to the Route after sending to correlate individual path
failures with the paths in the route or, in the future, retry
individual paths.

Thus, the easiest solution is to just take the Route by reference,
allowing the user to retain ownership.

panic!() when serializing OnionHopDatas with value > 21m BTC

Add documentation to the struct fields noting this to avoid missing
docs when various msg structs become public.

Test basic AMP payments in chanmon_consistency

Refactor test utils and add a simple MPP send/claim test.

Implement multipath sends using payment_secret.

This rather dramatically changes the return type of send_payment
making it much clearer when resending is safe and allowing us to
return a list of Results since different paths may have different
return values.

Refactor payment-claim logic to ensure MPP-claim atomicity

Previously if we claimed an MPP where a previous-hop channel was
closed while we were waitng for the user to provide us the preimage
we'd simply skip claiming that HTLC without letting the user know.

This refactors the claim logic to first check that all the channels
are still available (which is actually all we need - we really
mostly care about updating the channel monitors, not the channels
themselves) and then claim the HTLCs in the same lock, ensuring
atomicity.

Expand the Route object to include multiple paths.

Rather big diff, but its all mechanical and doesn't introduce any
new features.

Add/announce features for payment_secret and basic_mpp

Impl Base AMP in the receive pipeline and expose payment_secret

Base AMP is centered around the concept of a 'payment_secret` - an
opaque 32-byte random string which is used to authenticate the
sender to the recipient as well as tie the various HTLCs which
make up one payment together. This new field gets exposed in a
number of places, though sadly only as an Option for backwards
compatibility when sending to a receiver/receiving from a sender
which does not support Base AMP.

Sadly a huge diff here, but almost all of it is changing the method
signatures for sending/receiving/failing HTLCs and the
PaymentReceived event, which all now need to expose an
Option<[u8; 32]> for the payment_secret.

It doesn't yet properly fail back pending HTLCs when the full AMP
payment is never received (which should result in accidental
channel force-closures). Further, as sending AMP payments is not
yet supported, the only test here is a simple single-path payment
with a payment_secret in it.

Refuse to deserialize OnionHopDatas with values > 21 million

We should probably do this for all values (and define a newtype
for msat values), but this will do for now.

Support (de)serializing payment_data in onion TLVs and track them

This is the first step in Base AMP support, just tracking the
relevant data in internal datastructures.

Split only-receive/forward data out of PendingHTLCInfo into an enum

This should avoid blowing up the size of the struct when we add
additional data that is only relevant for receive.

Merge pull request #582 from arik-so/trailing_newline_config

Mandate new line at end of file in editorconfig.

Mandate new line at end of file in editorconfig.

Merge pull request #570 from naumenkogs/2020_04_routing_message_handler_tests

Add tests for routing message handler

Add tests for getting node announcements

Add tests for getting next channel announcements

Add tests for handling htlc fail channel updates

Add tests for handling channel updates

Add tests for handling channel announcements

Allow relaying of only one direction in a channel, log on recv

Add tests for handling node announcements

Merge pull request #581 from arik-so/fuzz_docs

Create docs for fuzzing

Update documentation to reflect target-dependent local reproduction steps.

Add details on asserting latest version in the dependencies and listing targets.

Create docs for fuzzing

Merge pull request #571 from ariard/2020-04-fix-minimalif

Enforce MINIMALIF-compliant witnesses

Enforce MINIMALIF-compliant witness for spending revokable redeemscript

Enforce MINIMALIF-compliant witness for timeout tx

Merge pull request #568 from jkczyz/2020-03-handle-error-deadlock

Fix deadlock in ChannelManager's handle_error!()

Test failing backward any pending HTLCs

Upon channel failure, any pending HTLCs in a channel's holding cell must
be failed backward. The added test exercises this behavior and
demonstrates a deadlock triggered within the handle_error!() macro. The
deadlock occurs when the channel_state lock is already held and then
reacquired when finish_force_close_channel() is called.

Fix deadlock in handle_error!() when we have HTLCs to fail-back.

This partially reverts 933ae3470309f21ef7537ffbcdc42070d60e1e74,
though note that 933ae3470309f21ef7537ffbcdc42070d60e1e74 fixed a
similar deadlock while introducing this one.

If we have HTLCs to fail backwards, handle_error!() will call
finish_force_close_channel() which will attempt to lock channel_state
while it is locked at the original caller. Instead, hold the lock for
shorter scopes such that it is not held upon entering handle_error!().

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

Merge pull request #556 from valentinewallace/add-PR550-test

Test that do_attempt_write_data does not infinitely loop

Test that do_attempt_write_data does not infinitely loop
when all the channel messages can't fit into the buffer.

Adds a test for PR #550.

Fix initial outbound sync infinite loop

Merge pull request #555 from ariard/2020-03-begin-dryup-chanmon-keys

Begin dry-up ChannelMonitor key access

Remove useless local commitment txn signatures

check_spend_local_transaction is tasked with detection of
onchain local commitment transaction and generate HTLC transaction.
Signing an already onchain tx isn't necessary.

Dryup SecretKey from ChannelMonitor::OnchainDetection

Key access is provided through ChanSigner.

Add ChanSigner in OnchainTxHandler

Rename ChannelMonitor::Storage to OnchainDetection,
holder of channel state (base_key+per_commitment_point)
to detect onchain transactions accordingly.

Going further between splitting detection and transaction
generation, we endow OnchainTxHandler with keys access.
That way, in latter commits, we may remove secret keys entirely
from ChannelMonitor.

Merge pull request #557 from ariard/2020-03-link-arch-md

Link ARCH.md in README.md

Link ARCH.md in README.md

Merge pull request #516 from TheBlueMatt/2020-02-checkin-arch

Add some basic arch diagrams/descriptions.

Add some basic arch diagrams/descriptions.

Merge pull request #554 from TheBlueMatt/2020-03-stale-mon-fail-man-deser

Fail to deserialize ChannelManager if it is ahead of any monitor(s)

Remove Watchtower mode from Storage enum and make it a struct

Watchtower will be supported through external signer interface
where a watchtower implementation may differ from a local one
by the scope of key access and pre-signed datas.

Merge pull request #552 from ariard/2020-03-ismine-spendable

Introduce IsMine logic in ChannelMonitor for SpendableOutputDescriptor detection

Add test_static_spendable_outputs_timeout_tx

Cover previously missing SpendableOuputDescriptor for
timeout tx on non-revoked remote commitment tx.

Fix #338

Test that ChannelManager fails to deserialize if monitors are stale

Fail to deserialize ChannelManager if it is ahead of any monitor(s)

If any monitors are out of sync with the Channel, we previously
closed the channel, but we should really only do that if the
monitor is ahead of the channel, opting to call the whole thing
invalid if the channel is ahead of the monitor.

Implement reorg-safety for SpendableOutputDescriptor detection

We delay SpendableOutputDescriptor until reaching ANTI_REORG_DELAY
to avoid misleading user wallet in case of reorg and alternative
settlement on a channel output.

Fix tests in consequence.

Move SpendableOutputDescriptor for closing tx in
is_paying_spendable_output

Add ChannelMonitor::shutdown_script to detect onchain tx
paying back to us

Move SpendableOutputDescriptor::DynamicOutputP2WPKH in
is_paying_spendable_output

Add ChannelMonitor::broadcasted_remote_payment_script to detect
onchain remote txn paying back to us.

Move SpendableOutputDescirptor::DynamicOutputP2WSH in
is_paying_spendable_output

Add ChannelMonitor::broadcasted_local_revokable_script to detect
onchain local txn paying back to us.

Fix tests in consequence

Introduce ChannelMonitor::is_paying_spendable_output

Previously, we would generate SpendableOutputDescriptor::StaticOutput
in OnchainTxHandler even if our claiming transaction wouldn't confirm
onchain, misbehaving user wallet to think it receives more funds than
in reality.

Fix tests in consequence

Add logger for SpendableOutputDescriptor

Merge pull request #551 from TheBlueMatt/2020-03-no-chan-mon

Generate latest local commitment transactions via monitor avoiding Channel's copy

Fetch latest commitment txn via monitor, not channel in test

Eventually, we want to remove the Channel's copy of its own
ChannelMonitor, reducing memory footprint and complexity of
ChannelManager greatly.

This removes the last uses of said ChannelMonitor for latest
local commitment transactions (though it is still used for
would_broadcast_at_height(), which is the last remaining use).

Fetch latest local commitment txn via a macro in tests

This makes it easier to swap out how we fetch the latest local
commitment txn in testing (which we use to check or broadcast old
states).

Broadcast final local txn via ChannelMonitorUpdate

Deduplicate HTLC preimage events from channelmonitor.

This avoids calling get_update_fulfill_htlc_and_commit twice for
the same HTLC if we have to rescan a block.

Remove bogus mon_update_id += 1 fulfilling already-fulfilled HTLCs

If we call get_update_fulfill_htlc (in this case via
ChannelManager::claim_funds_internal ->
Channel::get_update_fulfill_htlc_and_commit) and it finds that we
already have a holding-cell pending HTLC claim, it will return no
monitor update but leave latest_monitor_update_id incremented.

If we later go and add a new monitor update we'll panic as the
updates appear to have been applied out-of-order.

Merge pull request #547 from valentinewallace/add-PR539-test

Verify commitment point on ChannelReestablish (no updates case).

Verify commitment point on ChannelReestablish (no updates case).

Adds a test for PR #537.

Merge pull request #537 from TheBlueMatt/2020-03-data-loss-spec-550

Update pre-HTLC DataLossProtect to match new spec changes

Merge pull request #546 from TheBlueMatt/2020-03-519-nits

Watch revoked HTLC-Success/Timeout outputs

Add more logs in OnchainTxHandler

Watch outputs of revoked HTLC-transactions

Bumping of justice txn on revoked HTLC-Success/HTLC-timeout is triggered
until our claim is confirmed onchain with at least
ANTI_REORG_DELAY_SAFE. Before this patch, we weren't tracking them in
check_spend_remote_htlc, leading us to infinite bumps.

Fix #411

Small fixes by Matt Corallo <git@bluematt.me>

Fix duplicata of adjusted justice tx generation in OnchainTxHandler

Adjusted tx occurs when a previous aggregated claim tx has
seen one of its outpoint being partially claimed by a remote tx.
To pursue claiming of the remaining outpoint a adjusted claim tx
is generated  with leftover of claimable outpoints.

Previously, in case of block-rescan where a partial claim occurs,
we would generate duplicated adjusted tx, wrongly inflating feerate
for next bumps. At rescan, if input has already been dropped from
outpoints map from a claiming request, don't regenerate again
a adjuste tx.

Merge pull request #545 from TheBlueMatt/2020-03-fuzz-0-fee

Don't return a feerate of 0 in full_stack_target fuzz on EOF

Merge pull request #544 from TheBlueMatt/2020-03-fix-mon-ser

Fix ChannelMonitor round-trip introduced by 3d640da5c343111f538f006

Don't return a feerate of 0 in full_stack_target fuzz on EOF

This triggered a (legitimate) panic in OnChainTxHandler that the
feerate in use was non-0, which is required by the feerate API.

Fix ChannelMonitor round-trip introduced by 3d640da5c343111f538f006

3d640da5c343111f538f006996c13c9a98e0d9e6 changed the indexes for
some enums in ChannelMonitor deserialization but not serialization.
Thus, the chanmon_deser_target fuzz target failed on travis on at
least one PR.

Merge pull request #543 from TheBlueMatt/2020-03-513-warning

Add missing unwrap() in tests introduced in 4abfd515e554bef90c25dbe

Add missing unwrap() in tests introduced in 4abfd515e554bef90c25dbe

Merge pull request #513 from ariard/2020-02-fix-zero-msat-htlc

BOLT2: Check we don't send and accept 0-msat HTLC

Add test_override_0msat_htlc_minimum

Make htlc_minimum_msat configurable

Enforce a minimum htlc_minimum_msat of 1.

Instead of computing dynamically htlc_minimum_msat based on feerate,
relies on user-provided configuration value. This let user compute
an economical-driven channel parameter according to network dynamics.

Merge pull request #472 from TheBlueMatt/2020-01-net-async-await

Rewrite lightning-net-tokio using async/await and tokio 0.2

Merge pull request #541 from valentinewallace/fix-node-features

Fix node `with_relevant_init_flags`

Add test cases for feature messages from other lightning clients.

Fix blanking out non-node-context feature flags when pulling features from init context.

Fixes bug introduced in 912f877

Fix typo in lightning-net-tokio crate description.

Fix (and test) net-tokio outbound conns without a threaded env

Fix long-standing race in net-tokio reading after a disconnect event

If rust-lightning tells us to disconnect a socket after we read
some bytes from the socket, but before we actually give those bytes
to rust-lightning, we may end up calling rust-lightning with a
Descriptor that isn't registered anymore.

Sadly, there really isn't a good way to solve this, and it should
be a pretty quick event, so we just busy-wait.

Rewrite lightning-net-tokio using async/await and tokio 0.2

This is a rather major rewrite, using async/await and tokio 0.2,
which cleans up the code a ton as well as adds significantly to
readability.

Add test_update_add_htlc_bolt2_receiver_zero_value_msat

BOLT2: Check we don't send and accept 0-msat HTLC

Failing this requirement at sending means a strict receiver would
fail our channel while processing a HTLC routed from a third-party.

Fix by enforcing check on both sender and receiver side.

Swap read_event read type for a slice isntead of a Vec

It looks like we don't currently use the Vec as a Vec, and can
happily take a slice, which makes things easier on the calling
side.

Merge pull request #435 from TheBlueMatt/2020-01-node_announce

Add ability to broadcast our own node_announcement

Update pre-HTLC DataLossProtect to match new spec changes

This was the way DataLossProtect was originally written, however it
didn't match other implementations at the time during testing. It
turns out, other implementations didn't agree with each other
anyway (depending on the exact timeline), so the spec was clarified
somewhat in https://github.com/lightningnetwork/lightning-rfc/pull/550
. This updates us to be in line with the new guidance and appears
to solve out-of-sync issues in testing.

Use block timestamps as the min for generated update messages.

Fixes issue #493 and should resolve some issues where other nodes
(incorrectly) reject channel_update/node_announcement messages
which have a serial number that is not a relatively recent
timestamp.

Further document the initial routing table send.

As requested by Arik at https://github.com/rust-bitcoin/rust-lightning/pull/435#discussion_r378093821

Add ability to broadcast our own node_announcement.

This is a somewhat-obvious oversight in the capabilities of
rust-lightning, though not a particularly interesting one until we
start relying on node_features (eg for variable-length-onions and
Base AMP).

Sadly its not fully automated as we don't really want to store the
list of available addresses from the user. However, with a simple
call to ChannelManager::broadcast_node_announcement and a sensible
peer_handler, the announcement is made.

Allow more than one address per type in node_announcement messages

lnd has been blatantly ignoring this line in the spec forever, so
its somewhat of a lost cause trying to enforce it.

Allow node_announcement timestamps of 0 in accordance with BOLT 7

Unlike channel_update messages, node_announcement messages have no
requirement that the timestamp is greater than 0.

Merge pull request #535 from TheBlueMatt/2020-03-462-nits

A few minor nits on #462