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

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.

empty_commit: PR 441 follows

Fix initial outbound sync infinite loop (XXX: Needs test)

Fix apparent error in sending DataLossProtect

XXX: IIRC this was updated on the RFCs

empty_commit: critical bugfixes follow

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

Add a helper struct to allow a user to safely pass in an addr list

empty_commit: PR 435 follows

Test Router serialization round-trip in functional_tests.

This tests Router serialization round-trip at the end of each
functional test in the same way we do ChannelMonitors and
ChannelManagers to catch any cases where we were able to get into
a state which would have prevented reading a Router back off disk.

Change Option<T>::read serialization format to include length

This is a cheap way to fix an error in Router serialization
roundtrip due to us calling read_to_end during the read of
channel/node announcement/updates. During normal message reading,
we only have limited bytes to read (specifically the message buffer)
so this is fine, however when we read them inside Router, we have
more data from other fields of the Router available as well. Thus,
we end up reading the entire rest of the Router into one message
field, and failing to deserialize.

Because such fields are always stored in Option<>s, we can simply
use a LengthLimitingStream in the Option<> serialization format and
make only the correct number of bytes available.

By using a variable-length integer for the new field, we avoid
wasting space compared to the existing serialization format.

Make Readable::read a templated on the stream, not Readable itself

This makes Readable symmetric with Writeable and makes sense -
something which is Readable should be Readable for any stream which
implements std::io::Read, not only for a stream type it decides on.

This solves some lifetime-compatibility issues in trying to read()
from a LengthLimitingReader in arbitrary Readable impls.

Impl ReadableArgs for Arc<ChannelManager>, not just ChannelManager.

This provides a simple wrapper for deserializing right into an
Arc<ChannelManager>, which improves UX a tiny bit when working with
SimpleArcChannelManager types.

empty_commit: PR 523 follows

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.

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.

Only run lightning-net-tokio build on Rust 1.39.0+ on Travis.

This disables building the lightning-net-tokio crate on 1.34.2 on
Travis in anticiption of relying on async/await for
lightning-net-tokio, with the nice side-effect of reducing the
amount of work done on our slowest Travis job.

This also adds 1.39.0 to Travis as that is the new MSRV for
lightning-net-tokio.

empty_commit: PR 472 follows

Merge pull request #517 from ccdle12/2020-02-per-channel-config

Add an override optional UserConfig per new outbound channel

Merge pull request #507 from moneyball/patch-2

Add project tracking and conventions we want to adopt

made fixes per val and matt feedback

Add an override optional UserConfig per new outbound channel

Merge pull request #520 from TheBlueMatt/2020-02-events-in-monitors

Move events into ChannelMonitor from ManyChannelMonitor

Add comment noting that ChannelMonitor events are serialized

Drop stale doc comment + TODO describing MessageSendEvents

Move events into ChannelMonitor from ManyChannelMonitor

This is the next step after "Move pending-HTLC-updated ChannelMonitor
from ManyChannelMonitor", moving our events into ChannelMonitor as
well and leaving only new-outputs-to-watch in the return value for
ChannelMonitor::block_connected (which is fine as those are
duplicatively tracked in the ChannelMonitor directly, so
losing/replaying them is acceptable).

Implement Readable/Writeable for Events

As noted in the docs, Events don't round-trip fully, but round-trip
in a way that is useful for ChannelManagers, specifically some events
don't make sense anymore after a restart.

Merge pull request #522 from valentinewallace/chanmgr-fee-est-arc-to-deref

Update ChannelManager's FeeEstimator from Arc to Deref.

Merge pull request #521 from TheBlueMatt/2020-02-ping-connection-possible

Dont treat a timer tick as no_connection_possible

Dont treat a timer tick as no_connection_possible and log

In testing, due to other patches, I managed to flood the send queue
with messages and cause us not to be able to send pings, thus
getting a peer disconnected for ping timeout. To my surprise, this
also force-closed all of my channels with that peeer.

Obviously a ping timeout does not indicate that no future connection
with said peer will be possible, and we shouldn't be force-closing
channels as a result.

This also logs when a peer is disconnected to ping timeout to make
debug easier.

Add logging on receipt of unknown message types.

This should make peer disconnection easier to debug.

Update ChannelManager's FeeEstimator from Arc to Deref.

Merge pull request #518 from valentinewallace/chanmgr-keysmgr-arc-to-deref

multi: update ChannelManager's keys manager from Arc to Deref

multi: update ChannelManager's keys manager from Arc to Deref

Merge pull request #489 from TheBlueMatt/2020-02-chan-updates

Move to a Monitor-Update return from copying around ChannelMonitors

Drop TODO which was implemented long ago

Drop Clone from ChannelMonitor.

This removes the somewhat-easy-to-misuse Clone from ChannelMonitors,
opening us up to being able to track Events in ChannelMonitors with
less risk of misuse.

Sadly it doesn't remove the Clone requirement for ChannelKeys,
though gets us much closer - we now just need to request a second
copy once when we go to create the ChannelMonitors.

Rm ChannelMonitor merge capabilities in favor of explicit add/update

This removes the ability to merge ChannelMonitors in favor of
explicit ChannelMonitorUpdates. It further removes
ChannelManager::test_restore_channel_monitor in favor of the new
ChannelManager::channel_monitor_updated method, which explicitly
confirms a set of updates instead of providing the latest copy of
each ChannelMonitor to the user.

This removes almost all need for Channels to have the latest
channel_monitor, except for broadcasting the latest local state.

Create ChannelMonitors with basic_channel_info and funding_info set

This removes most of the reliance on ChannelMonitor Clone, creating
them in Channel only at the time when we need to start monitoring
the chain.

Use ChannelMonitorUpdate in fallen-behind handling during reestablish

This is a rather huge diff, almost entirely due to removing the
type parameter from ChannelError which was added in
c20e930b31e973e0fb290322c9ac425002e3b672 due to holding the
ChannelKeys in ChannelMonitors.

Set ChannelMonitor basic_channel_info on funding, not on accept

This prepares for only creating the ChannelMonitor on funding by
removing any channel_monitor calls from Channel open/accept-time to
funding-signed time.

Use ChannelMonitorUpdates in commitment signing fns in Channel

This is a rather big step towards using the new ChannelMonitorUpdate
flow, using it in the various commitment signing and commitment
update message processing functions in Channel. Becase they all
often call each other, they all have to be updated as a group,
resulting in the somewhat large diff in this commit.

In order to keep the update_ids strictly increasing by one for
ease of use on the user end, we have to play some games with the
latest_monitor_update_id field, though its generally still pretty
readable, and the pattern of "get an update_id at the start, and
use the one we got at the start when returning, irrespective of
what other calls into the Channel during that time did" is
relatively straightforward.

Impl (de)serialization for bitcoin::Transaction.

There is little risk of misusing this as there's not much in the
way of other ways you may want to serialize bitcoin::Transaction

Update Channel::funding_signed to use ChannelMonitorUpdate

This is the first of several steps to update ChannelMonitor updates
to use the new ChannelMonitorUpdate objects, demonstrating how the
new flow works in Channel.

Add types for updating ChannelMonitors without copying them.

This is the first step in migrating ChannelMonitor updating logic
to use incremental Update objects instead of copying the
ChannelMonitors themselves and insert_combine()ing them.

This adds most of the scaffolding and updates relevant comments to
refer to the new architecture, without changing how any actual
updates occur.

Use Channel::funding_txo instead of its channel_monitor.funding_txo

Currently Channel relies on its own internal channel_monitor copy
to keep track of funding_txo information, which is both a bit
awkward and not ideal if we want to get rid of the ChannelMonitor
copy in Channel.

Instead, just duplicate it (its small) and keep it directly in
Channel, allowing us to remove the (super awkward)
ChannelMonitor::unset_funding_txo().

Track counterparty's commitment secrets in Channel directly.

In the process of removing a local ChannelMonitor in each Channel,
we need to track our counterpartys' commitment secrets so that we
can check them locally instead of calling our channel monitor to
do that work for us.

Swap out ChannelMonitor remote secret tracking for a struct.

In order to drop the ChannelMonitor from Channel, we need to track
remote per_commitment_secrets outside of the monitor to validate new
ones as they come in.

This just moves the current code from ChannelMonitor into a new
CounterpartyCommitmentSecrets struct in chan_utils.

Clarify the in-flight HTLC state-tracking structs a bit.

This also renames PendingForwardHTLCInfo to PendingHTLCInfo since
it now also encompasses Pending *Received* HTLCs.

Merge pull request #509 from valentinewallace/chanmgr-tx-broadcaster-to-deref

multi: update ChannelManager tx broadcaster from Arc to Deref

multi: update ChannelManager tx broadcaster from Arc to Deref

Merge pull request #515 from TheBlueMatt/2020-02-further-peer-docs

Further clean up some comments wrt the peer socket handling API

Further clean up some comments wrt the peer socket handling API

Merge pull request #512 from TheBlueMatt/2020-02-peer_handler-docs

Fix incorrect docs/disconnect handling in peer_handler

Merge pull request #474 from TheBlueMatt/2020-02-htlc-updated-in-monitors

Move pending-HTLC-updated ChannelMonitor from ManyChannelMonitor

Fix incorrect docs around disconnect in peer_handler + rename fns

The way PeerHandler was written, it was supposed to remove from
self.peers iff the API docs indicate that disconnect_event should
NOT be called (and otherwise rely on disconnect_event to do so).

Sadly, the implementation was way out of whack with reality - in
the implementation, essentially anywhere where PeerHandler
originated the disconnection, the peer was removed and no
disconnect_event was expected. The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

We opt to change the docs, mostly, as well as clean up the
ping/pong handling somewhat and rename a few functions to clarify
what they actually do.

Test basic HTLC claim behavior from monitor -> manager on reorg

Move pending-HTLC-updated ChannelMonitor from ManyChannelMonitor

This is important for a number of reasons:
 * Firstly, I hit this trying to implement rescan in the demo
   bitcoinrpc client - if individual ChannelMonitors are out of
   sync with each other, we cannot add them all into a
   ManyChannelMonitor together and then rescan, but need to rescan
   them individually without having to do a bunch of manual work.
   Of the three return values in ChannelMonitor::block_connected,
   only the HTLCsource stuff that is moved here makes no sense to
   be exposed to the user.
 * Secondly, the logic currently in ManyChannelMonitor cannot be
   reproduced by the user! HTLCSource is deliberately an opaque
   type but we use its data to decide which things to keep when
   inserting into the HashMap. This would prevent a user from
   properly implementing a replacement ManyChannelMonitor, which is
   unacceptable.
 * Finally, by moving the tracking into ChannelMonitor, we can
   serialize them out, which prevents us from forgetting them when
   loading from disk, though there are still other races which need
   to be handled to make this fully safe (see TODOs in
   ChannelManager).

This is safe as no two entries can have the same HTLCSource across
different channels (or, if they did, it would be a rather serious
bug), though note that, IIRC, when this code was added, the
HTLCSource field in the values was not present.

We also take this opportunity to rename the fetch function to match
our other event interfaces, makaing it clear that by calling the
function the set of HTLCUpdates will also be cleared.

Merge pull request #514 from TheBlueMatt/2020-02-no-lto-travis-fuzz

Skip lto on travis when building fuzz targets as it takes 30 min

Skip lto on travis when building fuzz targets as it takes 30 min

Merge pull request #510 from TheBlueMatt/2020-02-fewer-fuzz-rustc-warns

Silence new rustc warnings re: extra ()s, dyn, and unused params

Merge pull request #511 from TheBlueMatt/2020-02-test-pub-in-test-only

Only expose constants exposed for testing in cfg(test)

Only expose constants exposed for testing in cfg(test)

Silence new rustc warnings re: extra ()s, dyn, and unused params

Merge pull request #506 from arik-so/ping_encryption_fix

Encrypt ping messages before sending them

Remove unused code in peer handler test utility method.

Merge pull request #508 from maxgiraldo/2020-02-sp-grammar

docs(CONTRIBUTING): fix spelling and grammar

Fix ping message sent on timer ticks to be encrypted so the peer can decrypt it instead of shutting down the connection.

docs(CONTRIBUTING): fix spelling and grammar

Fix some minor spelling and grammar mistakes.

Merge pull request #502 from rloomba/rloomba/add_unregister_listener

[chaininterface] Add ability for BlockNotifier to unregister listeners

Add project tracking and conventions we want to adopt

Merge pull request #503 from TheBlueMatt/2020-02-chanmon-ser-roundtrip

Fix Two Bugs around ChannelManager serialization round-trip

Merge pull request #455 from TheBlueMatt/2020-01-monitor-reload-watch

Track the full list of outpoints a chanmon wants monitoring for

Allow deserialization of new Channels before we've seen a block

Previously, if we have a live ChannelManager (that has seen blocks)
and we open a new Channel, if we serialize that ChannelManager
before a new block comes in, we'll fail to deserialize it. This is
the result of an overly-ambigious last_block_connected check which
would see 0s for the new channel but the previous block for the
ChannelManager as a whole.

We add a new test which catches this error as well as hopefully
getting some test coverage for other similar issues in the future.

Fix serialization rt bug in Channel and test in functional_tests

Previously, when attempting to write out a channel with some
RemoteAnnounced pending inbound HTLCs, we'd write out the count
without them, but write out some of their fields. We should drop
them as intended as they will need to be reannounced upon
reconnection.

This was found while attempting to simply reproduce a different
bug by adding tests for ChannelManager serialization rount-trip at
the end of each functional_test (in Node::drop). That test is
included here to prevent some classes of similar bugs in the future.

Add comment describing how ChannelMonitor::block_connected is called

Test that we don't forget to track any outputs at monitor-load

This tests, after each functional test, that if we serialize and
reload all of our ChannelMonitors we end up tracking the same set
of outputs as before.

Track the full list of outpoints a chanmon wants monitoring for.

Upon deserialization/reload we need to be able to register each
outpoint which spends the commitment txo which a channelmonitor
believes to be on chain. While our other internal tracking is
likely sufficient to regenerate these, its much easier to simply
track all outpouts we've ever generated, so we do that here.

add functionality for BlockNotifier to unregister a previously registered listener, in order to no longer receive events

Merge pull request #440 from TheBlueMatt/2020-01-feature-sanity

Fix a bug in required feature checks

Merge pull request #499 from moneyball/patch-1

add clarity to the language

fixes per rloomba feedback

Merge pull request #501 from TheBlueMatt/2020-02-rescan-clarify

Clarify rescan rules for block_connected somewhat

fixes per arik feedback

Clarify rescan rules for block_connected somewhat

add clarity to the language

Add some basic sanity tests for feature flags

Avoid treating option_upfront_shutdown (req) as unknown_required.

This fixes the bitmask in requires_unknown_bits.

Merge pull request #470 from ariard/2020-01-contributing-draft

First draft, don't-cover-everything-but-yet-a-good-start-CONTRIBUTING.md

Merge pull request #496 from TheBlueMatt/2020-02-461-extra-mut

Remove unnecessary mut introduced in 0c595a7ff69bd177b2e7fa8c1b361