Allow duplicate-payment_hash HTLCs for HTLC forwards

This is required by BOLT 2 to ensure that no attacker can simply
relay every public node a duplicate-payment_hash HTLC for each HTLC
it receives to deduce where an HTLC came from.

Note that this makes the claim logic much less incentive-compatible
as we will not claim all available HTLCs with the same payment_hash
even if we know the preimage! This is OK because, most likely, any
attackers trying to map the network will use small-value payments
and, hopefully, we will move away from constant hashes across an
entire payment at some point in the near future.

This further simplifies the payment transition state a bit, so
hopefully at least we got some readability out of all of this

Split HTLC tracking into separate Inbound/Outbound types

This isnt as simplifying as I'd hoped, but still increases
compile-time checking, which is nice, and removes one of two
panic!()s.

Merge pull request #165 from TheBlueMatt/2018-09-pre-disconnect-misc

Further minor misc changes from reconnect work

panic on invalid calls to Channel::send_commitment instead of Err

Do not allow sending HTLCs when the first hop is disconnected

Sync get_update_fail_htlc, get_update_fulfill_htlc state err result

Both get_update_fail_htlc and get_update_fulfill_htlc should never
be called before any HTLC could have been accepted (ie
pre-ChannelFunded) nor should they ever be called
post-ShutdownComplete as the Channel object should be destroyed at
that point. Previously get_update_fulfill_htlc would panic, but
get_update_fail_htlc would return an Err. For now make them both
panic but we can revisit this if we want to have fewer panics in
the future.

Add force_close_channel call command to full_stack_target

Merge pull request #164 from TheBlueMatt/2018-09-channel-connection-cleanups

Minor cleanups

Disallow duplicate Init messages from peers

Fix PeerManager::get_peer_node_ids to filter according to docs

Disconnect duplicate node_id connections after Noise handshake

Update add_update_monitor docs to indicate registration req.

It wasn't entirely clear from the existing docs that it is the
responsibility of the implementor of ManyChannelMonitor to
register the relevant outpoint.

Document Channel::get_funding_redeemscript precondition

Merge pull request #159 from ariard/channel_monitor

Add registration of commitment tx's outputs from check_spend_remote_transaction

Add registration of commitment tx's outputs from
check_spend_remote_transaction

Fixup more descriptive var names by Matt Corallo <git@bluematt.me>

Refactor/dont re-enter block_conencted on duplicate watch calls

Previously we'd hit an infinite loop if a block_connected call
always resulted in the same ChainWatchInterface registrations.
While we're at it, we also split ChainWatchUtil in two to make
things a bit more flexible for users, though not sure if that
actually matters, and make the matching more aggressive in testing,
even if we pick the more performant option at runtime.

Narrow ChainWatchInterface::install_watch_script

Merge pull request #162 from ariard/channel_manager_refactor_all

Channel manager refactor all (following & end)

Refactor handle_update_fee to wrapper error handling function

Refactor handle_revoke_and_ack to wrapper error handling function

Refactor handle_commitment_signed to wrapper error handling function

Refactor handle_update_fail_malformed_htlc to wrapper error handling function

Refactor handle_update_fail_htlc to wrapper error handling function

Refactor handle_update_fulfill_htlc to wrapper error handling function

Refactor handle_update_add_htlc to wrapper error handling function

Refactor handle_closing_signed to wrapper error handling function

Merge pull request #160 from ariard/channel_manager_refactor_all

Channel manager refactor all

Merge pull request #156 from TheBlueMatt/2018-09-funding_created_action

Ensure funding_created always returns Some(_) HandleError::action

Refactor handle_shutdown to wrapper error handling function

Refactor handle_funding_locked to wrapper error handling function

Refactor handle_funding_signed to wrapper error handling function

Remove unused import in router_target

Ensure funding_created always returns Some(_) HandleError::action

Merge pull request #154 from ariard/funding_created_refactor

Refactor handle_funding_created to wrapper error handling function

Refactor handle_funding_created to wrapper error handling function

Merge pull request #155 from SWvheerden/patch-1

patch to change temp_channel from deserialise to copy

change temp_channel from deserialise to copy

Merge pull request #151 from ariard/channel_manager_refactor

Refactor handle_accept_channel to wrapper error handling function

Refactor handle_accept_channel to wrapper error handling function

Merge pull request #152 from TheBlueMatt/2018-09-chan-cleanups

Channel cleanups

Add further clarification TODO in finish_force_close_channel

Drop HTLCState::LocalRemovedAwaitingCommitment

This was redundant and was included because the HTLC still needed
to be monitored, but that happens in ChannelMonitor, so there is no
need for it in Channel itself.

Document+check commitment_signed generation success on send_htlc

Because we don't have an HTLCState for
update_add_htlc-generated-but-not-yet-commitment_signed to simplify
the mess of HTLCState match arms, any time a Channel::send_htlc
call returns Ok(Some(_)) we MUST call commitment_signed and it MUST
return success (or close the channel). We mention this in the docs
and panic if its not met in ChannelManager (which lets the fuzz
tester check this).

Always return an Error Message in invalid sig/key errors in Channel

Merge pull request #150 from TheBlueMatt/2018-09-bolt7-compliance

Finish up #129 BOLT 7 compliance

Merge pull request #147 from TheBlueMatt/2018-09-channelmanager-err-macro

Refactor ChannelManager handle functions into a Channel-closing macro

Handle partial-response UTXO impls or reorgs in chan_announcements

Mostly to add a big comment noting why we aren't "spec-compliant"

Util-func channel removal (fixing a bug in HTLC failure updates)

Reject rumors of channels that are from one node back to itself

Move announcement_signatures handling into new force-close macro

Because we've separated out channel closure from ErrorMessage
returning we can return error messages in a few additional cases,
like if the peer sent us a message for a channel they didn't own.

Fill out IgnoreError actions in get_channel_announcement

They are all just "its too early/late to get an announcement"
errors so simply ignoring them and not sending an announce is fine

Simplify secp_call! macro in ChannelManager

Ensure Channel::new_from_req always returns an ErrorMessage on Err

Dont return an Err from Channel::get_accept_channel that can't fail

Refactor handle_open_channel to wrapper error handling function

Original version is from Antoine Riard <ariard@student.42.fr>,
the error type and some return type fixes are from
Matt Corallo <git@bluematt.me>

Add ChannelManager-specific HandleError type and macro to use it

Original macro is from Antoine Riard <ariard@student.42.fr>,
the error type and additional mappings are from
Matt Corallo <git@bluematt.me>

Merge pull request #145 from TheBlueMatt/2018-09-134-rebased

#134 rebased

Merge pull request #143 from TheBlueMatt/2018-08-announcement_sigs_erroraction

Ensure handle_announcement_signatures always has a ErrorAction

Provide better get_chain_utxo return coverage in router_target

Ensure we aren't duplicatively reading things in router_target

Add DummyChainWatcher in route_target

Add test_invalid_channel_announcemnt + test utilities

Fix typo

Check script_pubkey against expected channel_announcement

Implement get_chain_utxo and ChainError in
ChainWatchInterface to Router check on channel_announcement

Needed for BOLT 7

Add ChainWatchInterface in Router

Merge pull request #144 from yuntai/onion_call_back_simple

Remove code fragments with no effect

Remove code fragments with no effect

Check for misuse of funding_transaction_generated and panic

Ensure handle_announcement_signatures always has a ErrorAction

Add ErrorAction in secp Error -> HandleError conv in ChannelManager

Merge pull request #139 from TheBlueMatt/2018-08-fuzz-fixes-7

Fix crash that #127 intended to fix but did not completely fix

Remove unused feeest field in ChannelManager tests

Fix crash that #127 intended to fix but did not completely fix

Introduced in #124, and found by fuzzer

Merge pull request #136 from TheBlueMatt/2018-08-excess-signed-data-bolt-7

Correctly verify and forward excess data post-signature in signed announcement messages

Also fwd channel_update and node_announcement immediately

Not really sure why the API was different for channel_announcement,
but this brings everything in sync.

Fail parsing node/channel announcements with unknown even features

This is required for BOLT 7 compliance

Update msg_targets with new, must-roundtrip, and hole messages

Correct excess-data handling in NodeAnnouncement

Breaks parsing of padding within addresses, but nothing currently
generates such messages, and I'm proposing we remove it in the spec

Correct excess-data handling in ChannelUpdate

Correct excess-data handling in ChannelAnnouncement verif in Router

Ignore invalid lnd msgs by matching DecodeError instead of a macro

Remove unused test variable left orphaned by 5d923e2a634351e2852924

Merge pull request #133 from TheBlueMatt/2018-08-announcement_sigs

Clean up/clarify channel announcement_signatures handling

Merge pull request #135 from yuntai/201808-channelreestablish

Make my_current_per_commitment_point in ChannelReestablish optional

Use Option<DataLossProtect> for ChannelReestablish

and fix test

Fix test for ChannelReestablish

Make my_current_per_commitment_point Option

Per Bolt #2, both your_last_per_commitment_secret &
my_current_per_commitment_point are optional depending on
`data_loss_protect`

Clean up/clarify channel announcement_signatures handling

Make note about complying with BOLT 7 announcement_signatures

Merge pull request #132 from TheBlueMatt/2018-08-bolt-4-spec-return-fail

Return a malformed HTLC message when ephemeral pubkey is garbage

Remove incorrect auto-generated header from error_message_target

Return a malformed HTLC message when ephemeral pubkey is garbage

This resolves a spec-compliance bug with BOLT 4 where we simply
failed to deserialize the message and thus could never return an
HTLC failure message. However, note that BOLT 4 incorrectly hints
that a non-malformed message should be used ("...MUST report a
route failure to the origin node") which we cannot do as we cannot
derive a SharedSecret to encrypt a regular update_fail_htlc message

Update PendingHTLCStatus to hold malformed HTLC error messages

Add update_fail_malformed_htlcs vec to CommitmentUpdate

Not sure why this wasn't there to begin with

Merge pull request #131 from TheBlueMatt/2018-08-bolt-1-compliance

update Error/Init handling to be BOLT 1 compliant

Merge pull request #130 from TheBlueMatt/2018-08-fuzz-fixes-6

 Fix crash introduced in #124

Update error deserialization in compliance with BOLT #1

Handle Error messages by closing channels as required by BOLT 1

Ensure we never send messages prior to Init for BOLT 1 compliance

Remove unused node_id tracking in ChannelManager tests