Fail HTLCs backwards asynchronously

Add an enum option to pending forwards to fail backwards

Refactor HTLCForwardInfo into an enum in prep for delayed-fail

macro-out a bunch of PendingHTLCsForwardable+forward calls

Move process_onion_failure into onion_utils

Merge pull request #275 from TheBlueMatt/2018-12-manager-split

Split up ChannelManager

Drop needless mut found by rustc 1.22

Move ChannelManager network tests into their own module

Move onion encryption/decryption/etc into an onion_utils module

Drop channel_held_info which was only for the channel fuzz target

Merge pull request #270 from TheBlueMatt/2018-12-drop-rust-crypto

Drop rust-crypto for bitcoin_hashes

trace_log more in channelmonitor

Use bitcoin_hashes' fixed_time_eq, removing the rust-crypto dep

Drop rust-crypto trait usage

Steal rust-crypto's Poly1305 implementation wholesale

Steal rust-crypto's ChaCha20 implementation wholesale

Use bitcoin_hashes' Ripemd160/Hash160 from rust-crypto+rust-bitcoin

Note that this requires rewriting full_stack_target tests, which
sucks, but it does let the fuzzer hit more stuff since the real
ripemd160 isn't ever actually called anymore.

Switch Sha256 to using bitcoin_hashes and our own HKDF

Change the way channel keys are generated

This fixes a somewhat-misuse of HKDF in ChannelKeys::new_from_seed,
but much more importantly removes a use of rust-crypto's HKDF funcs

Merge pull request #274 from TheBlueMatt/2018-12-243-review

Onion Error Handling

Update incorrect_payment_amount generation/handling for BOLT uptd

ie dont generate them as they're a really obvious privacy leak.
Luckily we were already handling them the same aside from log
printing so don't have to touch anything there. I was lazy in
updating tests but it only effects log printing, so whatever.

Add tests for process_onion_failure return value sanity

Add test_util for overriding session privs for onion crypt

Add some additional channel-creation-broadcast-msg sanity checks

Always return malformed for BADONION errors

Also be willing to forward something with a pubkey that we know is
complete garbage, but upstream will just fail that with BADONION
when they get it.

I think this is kinda intended by the spec, but it definitely needs
to be clarified.

Add TODO noting confusion over |20 (channel_disabled) definition

Include flags when sending channel_disabled onion errors

Rewrite most of process_onion_failure

Swap an if let for a match and add some TODO

Merge pull request #273 from ariard/2018-12-17-replace-by-permanent-channel-failure

Replace some unknown_next_peer by permanent_channel_failure

Replace some unknown_next_peer by permanent_channel_failure

Merge pull request #269 from TheBlueMatt/2018-12-198-review

Detect HTLC-resolving on-chain actions and pass them to ChannelManager

Add some TODOs for correctness in ChannelMonitor

Add constant for HTLC failure anti-reorg delay

Include the node id in ChannelManager test logs

Add additional log traces in channelmonitor/manager

Add logging of HTLC outputs resolved by remote peer justice tx

In case of broadcast of revoked local commitment tx, we may be
interested that we've screwed up

Typify payment_hash and payment_preimage

Fix variable name as payment_hash instead of txid for index
of remote_hash_commitment_number in ChannelMonitor reader

Add bigger test for failing HTLCs claimed through revocation

Add test for failing/fulfilling HTLCs from on-chain actions

Including detection of timeout claims, fulfill claims, and
failing all current HTLCs in case of revoked-commitment broadcast.

Add const ACCEPTED_HTLC_SCRIPT_WEIGHT and OFFERED_HTLC_SCRIPT_WEIGHT to
ease readability

Conditionnal compilation for weight of second one to handle test special
cltv values

Generate PaymentFailed events for outbound payments we fail

Move monitor-generated HTLC event handling to manager event-getters

This is somewhat awkward, but prevents a slew of duplicate events.
Really this should probably be more explicit, but would be easy to
move that along with a slew of block_connected-event-processing
refactors, see-also GH #80.

This affects full_stack_target only on accident cause the demo test
didn't continue onwards with another block connection.

Fail all pending HTLCs if the remote broadcasts a revoked tx

Detect onchain timeout of a HTLC in ChannelManager block_connected

Pass failure backward

Add is_resolving_output in ChannelMonitor

Called in ChannelMonitor block_connected, returning
HTLCUpdate upstream via ManyChannelMonitor to
link htlcs between monitors. Used by ChannelManager to
fulfill/fail htlcs backwards accordingly

If spurrious HTLCUpdate are generated due to block re-scan
and htlc are already LocalRemoved, discard them in
channel get_update_*_htlc

Return refs from build_commitment_transaction, removing clone()s

Track HTLCSource in ChannelMonitor

Insert it in current_local_signed_tx, prev_local_signed_tx,
remote_claimable_outpoints. For so get it provided by
Channel calls to provide_latest_{local,remote}_tx

Track outputs fron local commitment tx

Aims to detect onchain resolution of channel

Modify in consequence test_txn_broadcast to still pass
channel_monitor_network_test

Modify some tests due to block re-scan caused by
detections extensions

Merge pull request #266 from TheBlueMatt/2018-12-closing_signed-3-leg-commitment

Remove check which makes us sometimes never send closing_signed

Merge pull request #263 from TheBlueMatt/2018-12-monitor-fail-2

Handle monitor update failures in msg-recv functions

Expand comment on ChannelMonitorUpdateErr::PermanentFailure a bit

Add test for monitor update failure on CS/RAA/CR handling

Handle monitor update failures in msg-recv functions

This adds a few TODOs around further message rebroadcasting which
needs to be implemented as well as some loss of tracking of HTLCs
on permanent channel failure which needs to get transferred over to
the appropriate in-memory ChannelMonitor.

Swap handle_monitor_update_fail for a macro ala try_chan_entry

This resolves an API bug where send_payment may return a
MonitorUpdateFailed Err both when the payment will not be sent and
when the HTLC will be retried automatically when monitor updating
is restored. This makes it impossible for a client to know when
they should retry a payment and when they should not.

Merge pull request #268 from TheBlueMatt/2015-12-fuzz-fix-output-idx

Check tx output matches monitor output data (and is sufficient len)

Check tx output matches monitor output data (and is sufficient len)

Fixes a panic found by fuzzer in case the monitor per-commitment
data is garbage. We had a similar check for revoked commitment tx
but didn't copy it down to non-revoked commitment tx, so do that
now.

Merge pull request #264 from TheBlueMatt/2018-12-198-first-commit

Refactor KeyStorage as Storage

Unify the update pattern in provide_latest_local_commitment_tx_info

Simplify ChannelMonitor Storage updates a bit

Simplify insert_combine by unimplemented!()ing unimplemented things

Refactor KeyStorage as Storage

Move PrivMode as Local, SigsMode as Watchtower

Cut funnding_txo from ChannelMonitor, move it inside Local

Rename log_funding_option as log_funding_info

Remove check which makes us sometimes never send closing_signed

This is the case pointed out by nayuta-gondo at
https://github.com/lightningnetwork/lightning-rfc/issues/499#issuecomment-438623208
though this doesn't actually solve the issue of ensuring we have a
consistent fee view when we start shutdown processing. There isn't
a clear solution to that however without adding additional state
tracking in Channel.

This also removes an associated test that tests for the correct
behavior (but didn't consider the bug) as we no longer behave
correctly. This should be fine as we'll be removing all the
update_fee garbage with option_simplified_commitment anyway.

Merge pull request #265 from TheBlueMatt/2018-12-fuzz-fix-no-witness

Fix crash on no-witness tx in ChannelMonitor found by fuzzer

Avoid writing to stdout during fuzz tests

Remove unused import in full_stack_target

Fix crash on no-witness tx in ChannelMonitor found by fuzzer

Tehnically we can't currently hit this, but a theoretical future
watchtower could, and full_stack_target crashes on it.

Merge pull request #261 from TheBlueMatt/2018-11-reestablish-fix

Fix channel_reestablish generation/handling around next_remote.

Fix channel_reestablish generation/handling around next_remote.

Merge pull request #260 from yuntai/201811-sessionkey

Add a method to get session secret for onion packet to KeysInterface

Add a method to get session secret for onion packet to KeysInterface

Merge pull request #258 from TheBlueMatt/2018-11-close-locked

Simplify + document the ChannelManager Err flow, fix close-outside-lock race, finish ChannelError conversion

Merge pull request #259 from TheBlueMatt/2018-11-256-redux

Add test_claim_on_remote_revoked_sizeable_push_msat

Add test_claim_on_remote_revoked_sizeable_push_msat

Refactor check spendable outputs macros into one

In consequence, harden spendable outputs tests

Fix vocabulary abuse

Simplify + document the ChannelManager Err flow a bit

This removes all the channel-closure stuff from handle_error!() and
MsgHandleErrInternal, making all the Err handling consistent by
closing the channel before releasing the channel_state lock and
then calling handle_error!() outside of the lock.

Remove MsgHandleErrInternal::from_chan_maybe_close as it's useless

Technically funding_transaction_generated was fine using it, but
calling force_shutdown on an empty Channel inside the channel_state
lock isn't a big deal and almost any other use of it would be
unsafe.

Properly handle ChannelError::Close results in update_fee.

Best reviewed with -b

Properly handle ChannelError::Close results in send_payment.

Best reviewed with -b

Close channels on Err returns inside the same channel_state lock

If we never accessed channels for a peer outside of a message
handler for that peer then this wouldn't be a problem since message
handlers are required to be serialized per-peer. However, that
isn't the world we live in - we may want to forward payments or we
may get a send_payment call.

Stop needlessly returning &HTLCSource out of Channel.

This moves a clone() inside Channel from ChannelManager making
references simpler for the coming refactors.

Remove remaining uses of HandleError in Channel Err return values

This converts block_connected failures to returning the
ErrorMessage that needs to be sent directly, since it always
results in channel closure and never results in needing to call
force_shutdown. It also converts update_add_htlc and closing_signed
handlers to ChannelError as the rest of the message handlers.

Split channel_reserve_test so we don't rely on unfilled Err actions

Currently channel_reserve_test sends a garbage update_add_htlc
message and then relies on it being silently ignored to continue
using the channel. This shouldn't be the case, so take the easy
way out and split the test in two, at first not delivering the
bogus update_add_htlc and then delivering it, but not running the
rest of the test.

Merge pull request #257 from TheBlueMatt/2018-11-007-bump

Bump to 0.0.7 for API rev

Bump to 0.0.7 for API rev

Merge pull request #246 from TheBlueMatt/2018-11-fuzz-crash-redux

Several fuzz-found bugfixes.

Merge pull request #255 from TheBlueMatt/2018-11-230-ext

Two post-#230 fixups

Check P2WPKH script against expected before gen'ing an output event

This fixes a bug in 3518f1f85d8a3daff451b3fe56cc7854b833e2bd where
we may generate an output event for a P2WPKH output which is not
ours if the transaction has a sequence/lock_time combination which
false-positives our remote tx detection.

Also note that the TODO is removed as this should already be
covered without issue if the client properly replays the chain on
restart.

Provide commitment point to monitor with the remote txn update

This extends 1b33064554ae48c9173acf8bf1e0052d33a855df by
re-simplifying the ChannelMonitor <-> Channel interface a bit as we
never have any use for the latest remote commitment point until we
have knowledge of a remote transaction generated using it.

Merge pull request #254 from TheBlueMatt/2018-11-channelerror

Move a ton of Channel functions to ChannelError from HandleError

Fix two compiler warnings introduced in a51dbb4a4de014238ab67ba507c

Move a ton of Channel functions to ChannelError from HandleError

This is a big patch, but its all very mechanical, everything here
should be pretty obvious, and it all has to happen at once due to a
few common utility functions all having the same return type.

Note that this exposes a race in channel closure where we may
access a channel via some non-peer-specific mechanism like
forwarding an HTLC or sending a payment during the time between
the channel gave us a Close error and expected us to never call it
again and the time we actually removed it from the channel_state
set outside of the internal_* handler.

Create simple ChannelMonitor-specific Err type

Merge pull request #231 from philipr-za/philip-204-check-commitment-transaction-fee

Check funder can afford commitment transaction fee when receiving update_fee

Merge pull request #230 from ariard/handle_sizeable_push_msat

Handle sizeable push msat (fix #195) + handle two first per_commitment_point + keys interface tests

Add test_static_output_closing_tx

Add test_dynamic_spendable_outputs_local_htlc_*

Cover both local HTLC-Timeout/Success case

Add key_storage selection in ChannelMonitor insert_combine

Based on commitment_number

Add test_static_spendable_outputs_justice_tx_revoked_htlc*

Cover both HTLC-Timeout/Success cases

Add test_static_spendable_outputs_justice_tx_revoked_commitment_tx