Merge pull request #283 from TheBlueMatt/2019-01-htlc-resolution-log

Simplify and expand logging in is_resolving_htlc_output

Merge pull request #282 from TheBlueMatt/2019-01-multi-htlc-claims

Fix multi-remote-HTLC-claim preimage learning

Simplify and expand logging in is_resolving_htlc_output

This clarifies all the conditions we can hit and also ensures they
are all logged in a clear and consistent manner.

Fix multi-remote-HTLC-claim preimage learning

When our counterparty claims multiple HTLCs from offered outputs in
one transaction we should still be able to learn the preimages.
Sadly, due to two bugs we were not previously doing so.

Fix source name in is_resolving_htlc_output

Merge pull request #280 from TheBlueMatt/2018-12-no-to-remote-revoked-htlcs

Move fail-backwards up for no to-remote output claims

Fix stale comment in functional_tests after failing back async

Macro-DRY HTLC back-fails for revoked remote transaction broadcast

Add test_commitment_revoked_fail_backward_exhaustive no_to_remote

This tests a case we previously didn't handle correctly where we
returned early if there was no to_remote output to claim and thus
failed to fail-backwards HTLCs which were present.

Add dust mode to test_commitment_revoked_fail_backward_exhaustive

This tests that we fail back HTLCs that don't make it into
commitment transactions the same as we test ones that do.

Merge pull request #281 from ariard/harden-inbound-htlc-resolved

Harden test for logging of inbound htlc being resolved

Log resolution of offered HTLC by HTLC-timeout tx

Move fail-backwards up for no to-remote output claims

This fixes HTLC fail-backwards in case we haven't yet sent enough
to have a to_remote output to claim, plus some edge cases where it
could be removed due to a fee update, though hopefully that goes
away with simplified_commitment.

Merge pull request #278 from TheBlueMatt/2018-12-fail-on-unrevoked-remote

Fail HTLC backwards on unrevoked remote commitment tx broadcast

More comments/hardening test_fail_backwards_unrevoked_remote_announce

Fail HTLC backwards on unrevoked remote commitment tx broadcast

Macro-out BroadcastChannelUpdate-on-channel-close in func tests

Log errors forwarding/failing HTLCs

Remove long-stale TODO

Merge pull request #276 from TheBlueMatt/2018-12-async-fail

 Fail HTLCs backwards asynchronously

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.