Test that txn pay at least a minimum relay fee in functional tests

This also pays a fee on the transactions we generate in response to
SpendableOutputDescriptors in tests.

This fixes the known issues in #630, though we should test for
standardness in other ways as well.

Fix feerate calculation on closing transactions

This resolves a number of bugs around how we calculate feerates on
closing transactions:

 * We previously calculated the weight wrong both by always
   counting two outputs instead of counting the number of outputs
   that actually exist in the closing transaction and by not
   counting the witness redeemscript.
 * We use assertions to check the calculated weight matches what we
   actually build (with debug_assertions for variable-length sigs).
 * As an additional sanity check, we really should check that the
   transaction had at least min-relay-fee when we were the channel
   initator.

Fix max fee_satoshis constant to be 21 million, not 2.1 million.

Though hopefully we never see a fee of 2.1 million BTC, either...

Merge pull request #731 from TheBlueMatt/2020-10-fix-big-lock

Actually hold the total_consistency_lock instead of take-and-drop

Merge pull request #730 from TheBlueMatt/2020-09-no-rescan

Drop last bits of rescan as its too complicated to be worth having

Actually hold the total_consistency_lock instead of take-and-drop

It was noticed (via clippy) by @casey that we were taking and then
immediately dropping the total_consistency_lock because `let _ =`
doesn't actually bind the response to anything. This appears to be
a consequence of wanting `if let Some(_) =` to not hold a ref to
the contained value at all, but is relatively surprising to me.

Drop last bits of rescan as its too complicated to be worth having

Previously, we had a concept of "rescaning" blocks when we detected
a need to monitor for a new set of outputs in future blocks while
connecting a block. In such cases, we'd need to possibly learn about
these new spends later in the *same block*, requiring clients who
filter blocks to get a newly-filtered copy of the same block. While
redoing the chain access API, it became increasingly clear this was
an overly complicated API feature, and it seems likely most clients
will not use it anyway.

Further, any client who *does* filter blocks can simply update their
filtering algorithm to include any descendants of matched
transactions in the filter results, avoiding the need for rescan
support entirely.

Thus, it was decided that we'd move forward without rescan support
in #649, however to avoid significant further changes in the
already-large 649, we decided to fully remove support in a
follow-up.

Here, we remove the API features that existed for rescan and fix
the few tests to not rely on it.

After this commit, we now only ever have one possible version of
block connection transactions, making it possible to be
significantly more confident in our test coverage actually
capturing all realistic scenarios.

Drop stale comment about a rescan that doesn't happen in tests

Merge pull request #729 from casey/readme

Add content to readme

Fix capitalization Gleb suggested

Clarify that lightning-net-tokio does networking only

Reword first paragraph and add tagline

Add content to readme

- Change header to "Rust-Lightning"
- Add crate and documentation badges
- Add introductory paragraph
- Move previous intro content under "Status" heading

Merge pull request #649 from jkczyz/2020-06-refactor-chain-listener

Refactor chain monitoring

Merge branch '2020-06-refactor-chain-listener-move-chainmonitor' into 2020-06-refactor-chain-listener

Move ln/channelmonitor.rs to chain/chainmonitor.rs

Move channelmonitor.rs from ln to chain module

Given the chain::Watch interface is defined in terms of ChannelMonitor
and ChannelMonitorUpdateErr, move channelmonitor.rs from the ln module
to the chain module.

Merge ChainMonitor impl blocks

Define type alias for enumerated transaction data

Transaction data from a block may be filtered before it is passed to
block_connected functions, which may need the index of each transaction
within the block. Rather than define each function in terms of a slice
of tuples, define a type alias for the slice where it can be documented.

Replace WatchEvent usage with get_outputs_to_watch

Outputs to watch are tracked by ChannelMonitor as of
73dce207dd0ea6c3ac57af3ebb8b87ee03e82c9e. Instead of determining new
outputs to watch independently using ChainWatchedUtil, do so by
comparing against outputs already tracked. Thus, ChainWatchedUtil and
WatchEvent are no longer needed.

Include funding TXO in outputs to watch

The funding TXO was never added to ChannelMonitor's outputs_to_watch in
73dce207dd0ea6c3ac57af3ebb8b87ee03e82c9e. Include it when constructing a
ChannelMonitor.

Fix architecture diagram arrow directions

Arrows should signify "calls" or "generates" unless noted.

Fix architecture diagram line length

Replace WatchEventProvider with chain::Filter

WatchEventProvider served as a means for replacing ChainWatchInterface.
However, it requires users to explicitly fetch WatchEvents, even if not
interested in them. Replace WatchEventProvider by chain::Filter, which
is an optional member of ChainMonitor. If set, interesting transactions
and output spends are registered such that blocks containing them can be
retrieved from a chain source in an efficient manner.

This is useful when the chain source is not a full node. For Electrum,
it allows for pre-filtered blocks. For BIP157/158, it serves as a means
to match against compact filters.

Remove ChainListener

BlockNotifier was removed in the previous commit, thus ChainListener is
no longer needed. Instead, anything needing chain events should be
notified directly.

Remove BlockNotifier

BlockNotifier is a convenience for handing blocks to listeners. However,
it requires that each listener conforms to the ChainListener interface.
Additionally, there are only two listeners, ChannelManager and
ChainMonitor, the latter of which may not be used when monitoring
channels remotely. Remove BlockNotifier since it doesn't provide much
value and constrains each listener to a specific interface.

Remove Key parameter from ChainMonitor

ChainMonitor's template Key parameter was meant to allow supporting
both local monitoring, where Key=OutPoint, and watchtowers, where Key=
(PublicKey, u32). Use OutPoint directly since the watchtower case will
not be supported this way.

Rename SimpleManyChannelMonitor to ChainMonitor

ManyChannelMonitor was renamed chain::Watch in the previous commit. Use
a more concise name for an implementation that monitors the chain for
channel activity. Future work will parameterize the struct to allow for
different varieties of persistence. Thus, users usually will be able to
use ChainMonitor directly rather than implementing a chain::Watch that
wraps it.

Replace ManyChannelMonitor with chain::Watch

Rename ManyChannelMonitor to chain::Watch and move to chain/mod.rs,
where chain-related interfaces live. Update the documentation for
clarity and to conform to rustdoc formatting.

Remove ChainWatchInterface

The remaining use of ChainWatchInterface was replaced by chain::Access
in the previous commit, and thus it is no longer needed.

Replace ChainWatchInterface in NetGraphMsgHandler

ChainWatchInterface was intended as an interface for watching rather
than accessing the chain. Remove get_chain_utxo and add chain::Access
trait for this behavior. Wrap it with an Option in NetGraphMsgHandler in
order to simplify the error interface.

Remove ChainWatchInterface from channelmonitor.rs

Use of ChainWatchInterface was replaced with WatchEvent in the previous
commit. Remove it from the parameterization of SimpleManyChannelMonitor
since it is no longer needed.

Replace use of ChainWatchInterface with WatchEvent

SimpleManyChannelMonitor is parameterized by ChainWatchInterface to
signal what transactions and outputs to watch for on chain. The
interface has grown to cover chain access (via get_chain_utxo) and block
block filtering (via filter_block and reentered), which has added
complexity for implementations and user (see ChainWatchInterfaceUtil).

Pull the watch functionality out as a first step to eliminating
ChainWatchInterface entirely.

Add test utilities for {dis}connecting a block

Replace direct uses of BlockNotifier in functional tests with utility
functions. This is in preparation for signaling watch events back via a
refactoring of ManyChannelMonitor and ChainWatchInterface. Those events
will be processed by connect_block.

Replace BlockNotifier with Node in test utilities

Change confirm_transaction and connect_blocks to take a Node instead of
a BlockNotifier. This is in preparation for signaling watch events back
via a refactoring of ManyChannelMonitor and ChainWatchInterface.

Simplify BlockNotifier tests

Use a simple ChainListner implementation rather than large test objects
for testing BlockNotifier.

Remove unregister_single_listener_ref_test since it is redundant with
unregister_single_listener_test.

Remove unnecessary clone() calls.

Align ChannelMonitor interface with ChainListener

ChannelMonitor has block_connected and block_disconnected methods called
by <SimpleManyChannelMonitor as ChainListener>. Use similar parameters
in ChannelMonitor such that transformations are not needed and the
interface is more closely aligned with ChainListener.

Remove ChainWatchInterface from BlockNotifier

ChainListeners should be independent of each other, but in practice this
is not the case because ChainWatchInterface introduces a dependency
between them. Push ChainWatchInterface down into the ChainListener
implementations where needed. Update ChainListener's block_connected
method to take a slice of the form &[(usize, &Transaction)] where each
transaction is paired with its position within the block.

Merge pull request #715 from TheBlueMatt/2020-09-no-rescan-tests

Do not test any block-contents-rescan cases

Do not test any block-contents-rescan cases

In anticipation for removing support for users calling
block_connected multiple times for the same block to include all
relevant transactions in the next PR, this commit stops testing
such cases. Specifically, users who filter blocks for relevant
transactions before calling block_connected will need to filter by
including any transactions which spend a previously-matched
transaction in the same block (and we now do so in our own
filtering logic, which is also used in our testing).

Clean up test_bump_penalty_txn_on_revoked_htlcs

Add a few comments to make it clear whats going on a bit more and
assert the basic structure of more transactions.

Further, point out where transactions are double-spends and don't
confirm double-spends.

Clean up static_spendable_outputs_justice_tx_revoked_htlc_success_tx

Add a few comments to make it clear whats going on a bit more and
don't test/confirm a double-spend transaction.

Clean up static_spendable_outputs_justice_tx_revoked_htlc_timeout_tx

Add a few comments to make it clear whats going on a bit more and
don't test/confirm a bogus transaction.

derive(Debug) on Events

We'd previously largely not turned on derive(Debug) on any of our
structs, but not for good reason. Especially for Events objects,
Debug can be a very useful for users to quickly print what they
received from us without having to write out a large match.

Merge pull request #713 from valentinewallace/cross-platform-ci

Update CI to run on Macos and Windows in addition to Ubuntu.

Update CI to run build and tests on Macos and Windows in addition to Ubuntu.

We only run Macos and Windows on Rust stable, for efficient CI.

Remove unnecessary include in Github Actions script.

Only link dead code when necessary in CI.

Merge pull request #690 from TheBlueMatt/2020-09-633-bindings

Small tweaks post #633/#684

Fix two bugs which access the wrong peer's htlc_minimum_msat value

 * Channel::get_counterparty_htlc_minimum_msat() returned
   holder_htlc_minimum_msat, which was obviously incorrect.
 * ChannelManager::get_channel_update set htlc_minimum_msat to
   Channel::get_holder_htlc_minimum_msat(), but the spec explicitly
   states we "MUST set htlc_minimum_msat to the minimum HTLC value
   (in millisatoshi) that the channel peer will accept." This makes
   sense because the reason we're rejecting the HTLC is because our
   counterparty's HTLC minimum value is too small for us to send to
   them, our own HTLC minimum value plays no role. Further, our
   router already expects this - looking at the same directional
   channel info as it does fees.

Finally, we add a test in the existing onion router test cases
which fails if either of the above is incorrect (the second issue
discovered in the process of writing the test).

Move onion failure tests from functional_tests to their own file

They all have a specific structure, so having them in the mess that
is functional_tests isn't really conducive to readability. More
importantly, functional_tests is so big it slows down compilation,
so even dropping a few hundred lines is a win.

Update bindings after merge of #633, #679, #683.

Clarify docs on payment_point slightly

Merge pull request #679 from ariard/2020-08-concurrent-watchtowers

Implement concurrent broadcast tolerance for distributed watchtowers

Merge pull request #696 from TheBlueMatt/2020-09-ci-check-commits

Check each commit at least builds in CI

Check each commit at least builds in CI

Improve PermanentFailure requiremnts documentation

Sources of the failure may be multiple in case of distributed watchtower
deployment. In either case, the channel manager must return a final
update asking to its channel monitor(s) to broadcast the lastest state
available. Revocation secret must not be released for the faultive
channel.

In the future, we may return wider type of failures to take more
fine-grained processing decision (e.g if local disk failure and
redudant remote channel copy available channel may still be processed
forward).

Add test_concurrent_monitor_claim

Watchower Alice receives block 134, broadcasts state X, rejects state Y.
Watchtower Bob accepts state Y, receives blocks 135, broadcasts state Y.
State Y confirms onchain. Alice must be able to claim outputs.

Implement concurrent broadcast tolerance for distributed watchtowers

With a distrbuted watchtowers deployment, where each monitor is plugged
to its own chain view, there is no guarantee that block are going to be
seen in same order. Watchtower may diverge in their acceptance of a
submitted `commitment_signed` update due to a block timing-out a HTLC
and provoking a subset but yet not seen by the other watchtower subset.
Any update reject by one of the watchtower must block offchain coordinator
to move channel state forward and release revocation secret for previous
state.

In this case, we want any watchtower from the rejection subset to still
be able to claim outputs if the concurrent state, has accepted by the
other subset, is confirming. This improve overall watchtower system
fault-tolerance.

This change stores local commitment transaction unconditionally and fail
the update if there is knowledge of an already signed commitment
transaction (ChannelMonitor.local_tx_signed=true).

Merge pull request #684 from bmancini55/gossip_queries

Adding gossip_queries messages and serializations

Adding fuzzers for gossip_queries messages

This commit adds ser/deser fuzzers for five new structs in ln::msgs used
for gossip_queries.

Adding gossip_queries message structs and serialization

This adds the message structs and implements Readable and Writeable
traits for the standard gossip_queries messages.

Merge pull request #633 from ariard/2020-05-rename-keys-var

Rename a's keys as local's keys and b's keys as remote's keys

Cleanup locally-selected-delay

Comment meaning of holder/counterparty

Diverse chan_utils cleanups

Cleanups post-cbindings merge

Fix misusage of holder_selected_contest_delay instead of counterparty
_selected_contest_delay in HolderCommitmentTransaction

Fix old payment_point comment

Overhaul LocalCommitmentTx to new nomenclature

Overhaul ChannelMonitor/OnchainTxHandler to new nomenclature

Change ChannelKeys interface nomenclature to holder/counterparty one

Transaction signing methods are changed from local_/remote_ prefix
to newer holder_/counterparty_ wihout any semantic changes.

Underscore TxCreationKeys ownership

A TxCreationKeys set represents the key which will be embedded in output
scripts of a party's commitment tx state. Among them there is a always
a key belonging to counter-party, the HTLC pubkey. To dissociate
strongly, prefix keys with broadcaster/countersignatory.

A revocation keypair is attributed to the broadcaster as it's used
to punish a fraudulent broadcast while minding that such keypair
derivation method will be always used by countersignatory as it's
its task to enforce punishement thanks to the release secret.

Change variable nomenclature for to_self_delay

To avoid reviewers confusion, rename counterparty_to_self_delay
to counteparty_selected_contest_delay, i.e the justice delay announced
by a channel counterparty restraining our transactions, and to_self_delay
to locally_selected_contest_delay, i.e the justice delay announced by us
restraining counterparty's transactions

We deviate from wider nomenclature by prefixing local data with a
locally_ extension due to the leak of this value in transactions/scripts
builder, where the confusion may happen.

Rename further AcceptChannelData to the new nomenclature.

Change variable nomenclature for Channel fields

Previously most of variable fields relative to data belonging to
our node or counterparty were labeled "local"/"remote". It has been
deemed confusing with regards to transaction construction which is
always done from a "local" viewpoint, even if owner is our counterparty

Merge pull request #688 from TheBlueMatt/2020-09-dev-docs

Add developer guideline notes for C/C++ bindings generation

Add a few more things to gitignore for bindings

Rename lightning C/C++ bindings library to libldk

This should fix #689.

Note that genbindings.sh is really also a test script.

Remove the bindings crate from the root namespace to let it break

Until we get the bindings generation process super stable, let the
bindings get stale with respect to the main repo while still letting
`cargo check` pass.

Add developer guideline notes for C/C++ bindings generation

Change variable nomenclature in chan_utils

Variables should be named according to the script semantic which is
an invariant with regards to generating a local or remote commitment
transaction.

I.e a broadcaster_htlc_key will always guard a HTLC to the party able
to broadcast the computed transactions whereas countersignatory_htlc_key
will guard HTLC to a countersignatory of the commitment transaction.

Merge pull request #618 from TheBlueMatt/2020-05-sample-c-bindings

C/C++ Bindings

Use Debian experimental in CI to match LLVM between rustc and clang

Specify panic = abort in profiles for lightning-c-bindings

Apply -O1 only to tests, not all dev (which is used for bindings)

Add bindings README

Add CI run for bindings generation (though we'll allow it to fail)

LTO in release mode by default, which is really critical for C libs

Update the root Cargo.toml to point to the new subcrate

Add automatically generated C/C++ wrapper bindings

Add all the manually-generated bits for the c-bindings crate

Including:
 * A script to automatically generate all the rest,
 * Cargo.toml and cbindgen.toml,
 * manually-written wrapper types for a few types

Add annotations for things which we cannot (yet) expose

Add tool to read a Rust crate and generate C-compatible wrappers

In general, it maps:
 * Traits to a struct with a void* and a list of function pointers,
   emulating what the compiler will do for a dyn trait anyway,
 * Structs as a struct with a single opaque pointer to the
   underlying type and a flag to indicate ownership. While this is
   a bit less effecient than just a direct pointer, it neatly lets
   us expose in the public interface the concept of ownership by
   setting a flag in the generated struct.
 * Unit enums as enums with each type copied over and conversion
   functions,
 * Non-unit enums have each field converted back and forth with a
   type flag and a union across all the C-mapped fields.

Remove a few final ::-containing paths in generic args

This cleans upa few last cases of functions/objects which our C
bindings generator doesn't know how to read.

Merge pull request #686 from TheBlueMatt/2020-09-bump-deps

Bump rust-bitcoin and friends

Silence new rustc warning about useless muts

Use rust-bitcoin's new SigHashCache instead of SignatureHashComp's

Thew new API is a bit harder to misuse by taking a reference to the
transaction to require the inputs match the input being signed.

Update to latest upstream rust-bitcoin

Merge pull request #676 from TheBlueMatt/2020-08-c-bindings-cleanups-3

Pre-C-Bindings Cleanups #3

Merge pull request #674 from TheBlueMatt/2020-08-keyif-rand-names

Simplify + clarify random-bytes-fetching from KeysInterface

Add a C-bindings-compatible read lock type for NetworkGraph

In order to calculate a route, it is likely that users need to take
a read()-lock on NetGraphMsgHandler::network_graph. This is not
possible naively from C bindings, as Rust's native RwLock is not
exposed.

Thus, we provide a simple wrapper around the RwLockReadGuard and
expose simple accessor methods.

Rename TxCreationKeys::new to not conflict w/ auto-gen'd C bindings

The C bindings automatically create a _new() function for structs
which contain only pub fields which we know how to map. This
conflicts with the actual TxCreationKeys::new() function, so we
simply rename it to capture its nature as a derivation function.

Give ChannelManagerReadArgs HashMap-of-monitors ownership

Its somewhat awkward that ChannelManagerReadArgs requires a mutable
reference to a HashMap of ChannelMonitors, forcing the callsite to
define a scope for the HashMap which they almost certainly won't use
after deserializing the ChannelManager. Worse, to map the current
version to C bindings, we'd need to also create a HashMap binding,
which is overkill for just this one use.

Instead, we just give the ReadArgs struct ownership of the HashMap
and add a constructor which fills the HashMap for you.

Use ln OutPoints not bitcoin ones in SpendableOutputDescriptors

Lightning OutPoints only have 16 bits to express the output index
instead of Bitcoin's 32 bits, implying that some outputs are
possibly not expressible as lightning OutPoints. However, such
OutPoints can never be hit within the lightning protocol, and must
be on-chain spam sent by a third party wishing to donate us money.
Still, in order to do so, the third party would need to fill nearly
an entire block with garbage, so this case should be relatively
safe.

A new comment in channelmonitor explains the reasoning a bit
further.