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.

Document exactly our CLTV sanitization policy for incoming HTLCs

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.

Cache local_commitment_tx in OnchainTxHandler

As transaction generation and signature is headed to be moved
inside OnchainTxHandler, cache local_commitment_tx signed by remote.

If access to local commitment transaction is needed, we extend Onchain
TxHandler API to do so.

Cache funding_redeemscript in OnchainTxHandler

As transaction generation and signature is headed to be moved
inside OnchainTxHandler, cache any usefule witness element.

Remove duplicata for local commitment+HTLC txn

Previously, we would regenerate this class of txn twice due to
block-rescan triggered by new watching outputs registered.

This commmit doesn't change behavior, it only tweaks TestBroadcaster
to ensure we modify cleanly tests anticipating next commit
refactor.

Merge pull request #589 from jkczyz/2020-04-feature-fixes

Missing feature checks and tests

Add missing known features in constructor

PaymentSecret and BasicMPP were added in d39f25839ad9ff5e2a0e1dd8919e991828d1bf35
but were not accounted for in with_known_relevant_init_flags.

Remove signing local commitment transaction from ChannelMonitor

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

Local commitment transaction should stay half-signed by remote until
we need to broadcast for a channel force-close or a HTLC to timeout onchain.

Add an unsafe test-only version of sign_local_commitment to fulfill our
test_framework needs.

Add missing feature sanity checks

PaymentSecret and BasicMPP were added in d39f25839ad9ff5e2a0e1dd8919e991828d1bf35
but the sanity test for supported features was missed.

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