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.

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.

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