Rename payment_basepoint/key to simply payment_point/key.

We no longer derive any keys from the payment point, so they aren't
a "base" but simply a point/key.

f note why we use a dummy pubkey as req by antoine

f make comment about fuzztarget pk validity more clear

f refactor out inline if into a local variable

Require option_static_remotekey in channel/channelmonitor.

This simplifies channelmonitor quite nicely (as expected) as we
never have to be concerned with learning data in a DataLossProtect
which is require for us to claim our funds from the latest remote
commitment transaction.

f Fix incorrect/early feature addition noted by Jeff (TODO: Tweak commit message)

Add detection of feature_static_remotekey support and print

This adds the ability to check for static_remotekey in appropriate
feature contexts and prints it at connect time. It is still
considered unknown for the purposes of requires_unknown_bits() as
we don't yet implement it.

Check local signtures explicitly in channel tx-generation tests

It appears the local signatures which are specified in the channel
transaction-generation tests were never checked directly (though
they were checked as a part of the overall fully-signed-transaction
tests).

Check them explicitly so that they can be updated for static remote
key.

Add additional trace logging in channel signature validation

This makes it easier to amend the full_stack_target
test_no_existing_test_breakage test by always providing the
neccessary data in the log.

Merge pull request #590 from jkczyz/2020-04-feature-flags

Features module improvements

Sanity check that known features are not required

Expand testing of unknown feature bits

Include tests for requires_unknown_bits and supports_unknown_bits when
an unknown even bit, odd bit, or neither is set. Refactor bit clearing
such that tests and production code share the same code path. Fix a
potential spec incompatibility (currently only exposed in testing code)
where trailing zero bytes are not removed after a bit is cleared.

Generalize with_known_relevant_init_flags

Converting from InitFeatures to other Features is accomplished using
Features::with_known_relevant_init_flags. Define a more general
to_context method which converts from Features of one Context to
another.

Additionally, ensure the source context only has known flags before
selecting flags for the target context.

Generalize feature methods to work in any context

Refactoring the features module allowed for making code specific to
certain contexts generalizable. Specifically, KNOWN_FEATURE_MASK
is defined on Context instead of hardcoded in each method
specialization. Thus, such methods are no longer required.

Remove duplicate specification of features

Features for a given context are duplicated throughout the features
module. Use a macro for defining a Context and the applicable features
such that features only need to be defined for a Context in one place.
The Context provides bitmasks for selecting known and unknown feature
flags.

BOLT 1 and BOLT 9 refer to features as "known" if a peer understands
them. They also use the term "supported" to mean either optional or
required.

Update the features module to use similar terminology.
- Define contexts in terms of required and optional features rather than
  just supported features
- Define known features as those that are optional or required
- Rename supported() constructor to known()

For completeness, clear_optional_bit for each feature is now called
clear_bits and clears both optional and required bits.

Improve features module documentation

Encapsulate feature flag checking and manipulation

Each feature is represented by two bits within Features' flags field.
Working with these flags requires bitwise operations, which can be error
prone. Rather than directly checking and manipulating bits, encapsulate
the bits within each feature trait and provide mechanisms for doing so.

This removes the need to comment on which features correspond to bitwise
expressions since the expressions use feature trait identifiers instead.

With this approach, byte literals and expressions can be evaluated at
compile time still. However, for these cases, knowing which byte within
the flags that a feature corresponds to still must be determined by the
implementor.

Remove the special case where initial_routing_sync has no even bit. Now,
it (bit 2) is considered known by the implementation.

Set initial_routing_sync in InitFeatures

The initial_routing_sync feature is set by peer_handler whenever a full
sync of the network graph is desired. It is not explicitly set when
creating features with InitFeatures::supported().

An upcoming refactor will change supported() to known(), which will
return all features known by the implementation. Thus, the
initial_routing_sync flag will need to be set by default. This commit
makes the behavior change ahead of the refactor.

Merge pull request #609 from LNP-BP/refactor-deps

Refactor dependencies

Adopting (W)PubkeyHash types

Adopting new bitcoin hash types and crate version

BDR: Linearizing secp256k1 deps

Bitcoin deps refactoring (BDR): Linearizing bitcoin_hash deps

Unset upfront_shutdown_script using bit clearing

The test_upfront_shutdown_script functional test clears this feature
flag. However, the method used to clear the flag is implemented by bit
toggling. Thus, if the flag is not set the method would actually set it.
Implement the method using bit clearing instead.

Merge pull request #608 from TheBlueMatt/2020-04-0.0.11

0.0.11

Merge pull request #598 from TheBlueMatt/2020-04-559-cleanups

Clean up ChannelKeys API

Bump versions to 0.0.11/net-tokio 0.0.3

Remove trivial assertions in LocalCommitmentTransaction fns

We don't need to assert that transaction structure is what we
expect when the transaction is created by a function twenty lines
up in the same file.

Remove TODOs from documentation in keysinterface

We should never be exposing our own TODOs to the world.

Don't modify LocalCommitmemntTransaction after construction

Instead of adding signatures to LocalCommitmentTransactions, we
instead leave them unsigned and use them to construct signed
Transactions when we want them. This cleans up the guts of
LocalCommitmentTransaction enough that we can, and do, expose its
state to the world, allowing external signers to have a basic
awareness of what they're signing.

Batch-sign local HTLC txn with a well-doc'd API, returning sigs

1107ab06c33bd360bdee7ee64f4b690e753003f6 introduced an API to have a
ChannelKeys implementer sign HTLC transactions by calling into the
LocalCommitmentTransaction object, which would then store the tx.

This API was incredibly awkward, both because it required an
external signer trust our own internal interfaces, but also because
it didn't allow for any inspection of what was about to be signed.

Further, it signed the HTLC transactions one-by-one in a somewhat
inefficient way, and there isn't a clear way to resolve this (as
the which-HTLC parameter has to refer to something in between the
HTLC's arbitrary index, and its index in the commitment tx, which
has "holes" for the non-HTLC outputs and skips some HTLCs).

We replace it with a new function in ChannelKeys which allows us
to sign all HTLCs in a given commitment transaction (which allows
for a bit more effeciency on the signers' part, as well as
sidesteps the which-HTLC issue). This may also simplify the signer
implementation as we will always want to sign all HTLCs spending a
given commitment transaction at once anyway.

We also de-mut the LocalCommitmentTransaction passed to the
ChanKeys, instead opting to make LocalCommitmentTransaction const
and avoid storing any new HTLC-related data in it.

Return Result<Signature> instead of modifying args in ChannelKeys

This cleans up sign_local_commitment somewhat by returning a
Result<Signaure, ()> over the local commitment transaction instead
of modifying the struct which was passed in.

This is the first step in making LocalCommitmentTransaction a
completely pub struct, using it just to communicate enough
information to the user to allow them to construct a signaure
instead of having it contain a bunch of logic.

This should make it much easier to implement a custom ChannelKeys
by disconnecting the local commitment transaction signing from our
own datastructures.

Track signing of local txn in channelmonitor and refuse updates

In e46e183084ed858f41aa304acd78503aea1a96ed we began tracking
whether a local commitment transaction had been signed and
broadcast in OnchainTxHandler, refusing to update the local
commitment transaction state in the ChannelMonitor on that basis.

This is fine, except that it doesn't make a lot of sense to store
the full local transaction state in OnchainTxHandler - we should be
providing it the unsigned local transaction at the time we wish to
broadcast and no more (just like we do all other transaction data).

Dry-up InputMaterial::Funding

As channel_value last usage was for computing feerate but as this
one is static per-commitment and will always-be following specification,
we remove it.

Merge pull request #579 from ariard/2020-04-sanitize-cltv-delay

Sanititze and document incoming HTLC cltv_expiry handling

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.

Merge pull request #607 from TheBlueMatt/2020-04-more-cleanups

CI and rustc warning cleanup

Include color when building fuzz targets in CI

Disable timeout for full_stack_target runs in CI

It seems we've recently been seeing sporadic long-running
full_stack_target cases when running honggfuzz in CI. These
shouldn't be killed (as its possible they hit an error or a deadlock,
especially since the longest-running tests probably have the most
coverage).

Silence fuzz build unused import warnings

Address new rustc warnings.

Fix step naming in fuzz tests in GitHub Actions

Run Github Actions on PRs, too

Merge pull request #593 from TheBlueMatt/2020-04-par-fuzz-check

Thread fuzz test cases

Document exactly our CLTV sanitization policy for incoming HTLCs

Thread fuzz test cases

Adds threading (with logger capture) to fuzz targets so that we can
more effeciently test a failing fuzz corpus on new code changes.

Merge pull request #587 from TheBlueMatt/2020-04-mpp-timeout

Time out HTLCs before they expire

Add test for timing out HTLCs which are in the holding cell

Time out AwatingRemoteRAA outgoing HTLCs when we reach cltv_expiry

In case of committing out-of-time outgoing HTLCs, we force
ourselves to close the channel to avoid remote peer claims on a
non-backed HTLC

Add test for partial-send MPP due to monitor update failure

Relatively simple test that, after a monitor update fails, we get
the right return value and continue with the bits of the MPP that
did not send after the monitor updating is restored.

Add a test for timeout'ing HTLCs which claim to be a part of an MPP

This is a key test for our automatic HTLC time-out logic, as it
ensures we don't allow an HTLC which indicates we should wait for
additional HTLCs before responding to cause us to force-close a
channel due to HTLC near-timeout.

Expand expect_payment_failed!() to take error codes and use it more

expect_payment_failed!() was introduced after many of the tests
which could use it were written, so we take this opportunity to
switch them over now, increasing test coverage slightly by always
checking the payment hash expected.

Time out incoming HTLCs when we reach cltv_expiry (+ test)

We only do this for incoming HTLCs directly as we rely on channel
closure and HTLC-Timeout broadcast to fail any HTLCs which we
relayed onwards where our next-hop doesn't update_fail in time.

Add a constant and docs for when we should fail an HTLC.

Merge pull request #601 from D4nte/ci-in-github-action

Add GitHub Action to build the project

Add a pop of colour

Add CI using GitHub Action

Same setup than Travis except for removing
`rm -f target/debug/lightning-*` as I do not believe
such file would exist on a fresh run.

I have not setup caching at this stage. The library is
small so I don't think it'd be that necessary/helpful.

I'd recommend to let both CI run for a bit to compare
performance and stability. The CI setup is straightforward
so I do not foresee any issue with GitHub actions.

Once happy, Travis file can be removed and branch
protection checks can be updated to block on the GitHub
actions.

You can also check the [Coverage report](https://codecov.io/gh/D4nte/rust-lightning/tree/752a58bc0441a49a0513f2cad979ad9e2621312a/lightning/src/chain) to ensure it is as expected.

Merge pull request #597 from TheBlueMatt/2020-04-more-chanmon-cleanups

Few more ChannelMonitor Cleanups

De-Option<> current_local_signed_commitment_tx in ChannelMonitor

Since we now are always initialised with an initial local commitment
transaction available now, we might as well take advantage of it and
stop using an Option<> where we don't need to.

Delay creating outbound ChannelMonitor until funding_signed rcpt

Previously, we created the initial ChannelMonitor on outbound
channels when we generated the funding_created message. This was
somewhat unnecessary as, at that time, we hadn't yet received
clearance to broadcast our initial funding transaction, and thus
there should never be any use for a ChannelMonitor. It also
complicated ChannelMonitor a bit as, at this point, we didn't have
an initial local commitment transaction.

By moving the creation of the initial ChannelMonitor to when we
receive our counterparty's funding_signed, we can ensure that any
ChannelMonitor will always have both a latest remote commitment tx
and a latest local commitment tx for broadcast.

This also fixes a strange API where we would close a channel
unceremoniously on peer-disconnection if we hadn't yet received the
funding_signed, but we'd already have a ChannelMonitor for that
channel. While it isn't strictly a bug (some potential DoS issues
aside), it is strange that these two definitions of a channel being
open were not in sync.

Add HTLC/extra data in LocalCommitmentTransaction from construction

1107ab06c33bd360bdee7ee64f4b690e753003f6 introduced some additional
metadata, including per-HTLC data in LocalCommitmentTransaction. To
keep diff reasonable it did so in ChannelMonitor after the
LocalCommitmentTransaction had been constructed and passed over the
wall, but there's little reason to do so - we should just be
constructing them with the data from the start, filled in by Channel.

This cleans up some internal interfaces a bit, slightly reduces
some data duplication and moves us one step forward to exposing
the guts of LocalCommitmentTransaction publicly in a sensible way.

Drop redundant parameters in sign_local_commitment_tx

The ChanKeys is created with knowledge of the Channel's value and
funding redeemscript up-front, so we should not be providing it
when making signing requests.

Avoid a few useless clone() calls in onchaintx.rs

3d640da5c343111f538f006996c13c9a98e0d9e6 looped over a new HashMap
new_claims, clone()ing entries out of it right before droppng the
whole thing. This is an obvious candidate for drain(..).

Clarify documentation on deserialization reorg requirements

Use more generic name as it will be use in GitHub Action too

Drop ChannelMonitor::write_for_watchtower

Not only was watchtower mode never implemented, but the bits that
we had were removed some time ago. It doesn't seem likely we'll
move forward with a "watchtower-mode" ChannelMonitor, instead
we'll likely have some other, separate struct for this.

Merge pull request #602 from murtyjones/test-byte-utils

Add tests to byte_utils.rs

Merge pull request #603 from moneyball/patch-3

fixed typo

fixed typo

Update lightning/src/util/byte_utils.rs

add tests

Merge pull request #594 from TheBlueMatt/2020-04-cleanups

Trivial Cleanups

Merge pull request #596 from D4nte/586-update-htlc-error-code-content

Include `height` to `incorrect_or_unknown_payment_details` failure

Test that `height` is included for incorrect payment details

Ensure that the best know blockchain height is included in the
data of `incorrect_or_unknown_payment_details` message failure.

Include `height` to `incorrect_or_unknown_payment_details` failure

`incorrect_or_unknown_payment_details` failure message,
`0x4000 (PERM) | 15`, should include the following data:
- [u64:htlc_msat]
- [u32:height]
This patches ensure that the height is included in all
the occurrences of this failure message.

De-Option<> some fields in ChannelMonitor which are set at init

After we moved the ChannelMonitor creation later during Channel
init, we never went back and cleaned up ChannelMonitor to remove
a number of now-useless Option<>s, so we do that now.

Drop std::error::Error impl for DecodeError

It appears to be effectively-deprecated in Rust now, and didn't
really appear to serve a lot of purpose anyway.

Concretize some types in fuzz, addressing new rustc warnings

Fix new rustc warnings for unnecessary parenthesis

Drop uneccessary indirection in map-updating in 1107ab06c3

1107ab06c33bd360bdee7ee64f4b690e753003f6 added a Vec of future
updates to apply during a loop, fixing a borrow checker issue that
didn't exist in the merged version of the patch. This simply reverts
that small part of the change.

Merge pull request #558 from TheBlueMatt/2020-03-555-nits

Flatten ChannelMonitor substructs that don't add clarity

Flatten ChannelMonitor substructs that don't add clarity

The new OnchainDetection struct (which is the remnants of the old
KeyStorage enum, which was removed in 1dbda4faedc33506e63176e6a456)
doesn't really add any clarity to ChannelMonitor, so best to just
drop it and move its members into ChannelMonitor directly.

Drop uneccessary clone() introduced in 16fba9fd664522ac8d24111547b4

Merge pull request #559 from ariard/2020-03-move-local-commitment

Split parsing and transaction management for local transactions between Chanmon/Onchain

Add test_update_err_monitor_lockdown

This test tries the new lockdown logic in case of a signed-and-broadcast
local commitment transaction while a concurrent ChannelMonitorUpdate for
a next _local_ commitment is submitted from offchain. Update is rejected
as expected with a ChannelMonitorUpdateErr.

Monitor should panic on receiving buggy update sequences

Channel shouldn't send a ChannelForceClosed update followed by
a LatestLocalCommitmentTxInfo as it would be a programming error
leading to risk of money loss. Force-closing the channel will
broadcast the local commitment transaction, if the revocation
secret for this one is released after its broadcast, it would
allow remote party to claim outputs on this transaction using
the revocation path.

Make acces and signature of local commitment transaction unique

Local commitment transaction broadcast can be triggered by a)
a Channel force-close or b) reaching some block height implying
a onchain HTLC-timeout. If one of this condition is fulfilled,
commitment is signed and from then any state update would be
rejected.

ChannelMonitor init at Channel creation need to be refactored
before to make get_fully_signed_local_tx infaillible to avoid
choking in the test framework.

Remove temporary anti-duplicata logic

Move HTLC tx generation in OnchainTxHandler

HTLC Transaction can't be bumped without sighash changes
so their gneeration is one-time for nwo. We move them in
OnchainTxHandler for simplifying ChannelMonitor and to prepare
storage of keys material behind one external signer interface.

Some tests break due to change in transaction broadcaster order.
Number of transactions may vary because of temporary anti-duplicata
tweak can't dissociate between 2- broadcast from different
origins (ChannelMonitor, ChannelManager) and 2-broadcast from same
component.

Add OnchainTxHandler::get_fully_signed_htlc

In case of channel force-closure, access to local commitment
transactions and its dependent HTLCs is needed. Instead of using
broadcast_by_local_state which registers outpoint to claim and
outputs to watch which are going to be discarded in this case,
we simply ask OnchainTxHandler to build and sign HTLC transactions
through new API.

Cache csv_local inside OnchainTxHandler

csv_local is csv_delay encumbering local revokable_redeemscript
for to_local an htlc output on local commitment/HTLC transactions.

Cache per-HTLC data in OnchainTxHandler::HTLCTxCache

Splitting further parsing from transaction generation, we cache
transaction elements needed for local HTLC transaction inside
OnchainTxHandler. Duplicated data will be removed from ChannelMonitor
in future commits.

Cache HTLC transaction material inside OnchainTxHandler

Splitting further parsing from transaction generation, we cache
transaction elements needed for local HTLC transaction inside
OnchainTxHandler. Duplicated data will be removed from ChannelMonitor
in future commits.

Remove signing htlc transaction from ChannelMonitor

Extend external signer interface to sign HTLC transactions on its
behalf without seckey passing. This move will allow us to remove
key access access from ChannelMonitor hot memory in further work.

HTLC transactions should stay half-signed by remote until
we need to broadcast them for timing-out/claiming HTLCs onchain.

Remove per_input_material introduce in commit 0011713

Caching of input material for HTLC transaction was introducted
prevently but since then API (InputMaterial) has changed
between ChannelMonitor and OnchainTxHandler

Access signed local commitment through OnchainTxHandler

Implementing dynamic fee bumping implied to cache transaction material
including its witness, to generate a bumped version if needed.

ChannelMonitor is slowly rescoped to its parsing function with ongoing
patchset and data duplicata are removed. If signed local commitment tx
access is needed, it's done through OnchainTxHandler extended API

For test framework purpose, we use the test-only method
ChannelMonitor::unsafe_get_latest_local_commitment_txn to intentionally
generate unsafe local commitment to exerce revocation logic.

Cache current local commitment number in ChannelMonitor.

By caching current local commitment number instead of deciphering
it from local commitment tx, we may remove local commitment tx
from ChannelMonitor in next commit.

Move local commitment tx generation in OnchainTxHandler

Local Commitment Transaction can't be bumped without anchor outputs
so their generation is one-time for now. We move them in
OnchainTxHandler for simplifying ChannelMonitor and to prepare
storage of keys material behind one external signer interface.

Some tests break due to change in transaction broadcast order but
number of transactions broadcast should stay the same.

Prevent any update of local commitment transaction once signed

To prevent any unsafe state discrepancy between offchain and onchain,
once local commitment transaction has been signed due to an event
(either block height for HTLC-timeout or channel force-closure), don't
allow any further update of local commitment transaction view
to avoid delivery of revocation secret to counterparty for the
aformentionned signed transaction.