Use external key signer to generate closing transaction signatures

Sign channel_announcements via a new ChannelKeys API

Use EnforcingChannelKeys in fuzz targets to get more coverage

Merge pull request #404 from TheBlueMatt/2019-11-signer-api

Replace keys API with Signer API to support hardware wallets eventually

Merge pull request #417 from TheBlueMatt/2019-12-ver-bump

Bump to 0.0.10

Bump versions to 0.0.10

Bump bitcoin dep to 0.21

Pre-build fuzz targets at once in travis instead of as we need them

Document more current security assumption of KeysInterface

Improve some comments of interface methods.

Make commitment transaction signing a part of ChannelKeys.

This adds a new fn to ChannelKeys which is called when we generte
a new remote commitment transaction for signing. While it may be
theoretically possible to unwind state updates by disconnecting and
reconnecting as well as making appropriate state machine changes,
the effort required to get it correct likely outweighs the UX cost
of "preflighting" the requests to hardwre wallets.

Make ChannelKeys an API and template Channel with it.

Instead of having in-memory access to the list of private keys
associated with a channel, we should have a generic API which
allows us to request signing, allowing the user to store private
keys any way they like.

The first step is the (rather mechanical) process of templating
the entire tree of ChannelManager -> Channel impls by the
key-providing type. In a later commit we should expose only public
keys where possible.

Bump versions to 0.0.10

Bump bitcoin dep to 0.21

Merge pull request #416 from TheBlueMatt/2019-12-fuzz-clib

Refactor fuzzing to be a C-callable library plus rust binaries

Refactor fuzzing to be a C-callable library plus rust binaries

This should help us avoid rust's at-load syscalls by calling the
tests from a C program.

Merge pull request #414 from TheBlueMatt/2019-12-347-nits

347 with travis fix and a few nits.

Avoid cloning RBF state when we just want to modify fields.

Add test_bump_txn_sanitize_tracking_maps

Extend test visibility of claim-tracking maps to do so.

Cover both "If 2 claimable-outpoint-spending txn are in 1 block,
clean up properly" and "Clean up claimable_outpoints when
pending_claim_requests is cleaned" fix commits in same patchset.

Sanitize pending_claim_requests if no more outpoints to claim

Dont RBF a tx twice if it hits RBF timer when one input is spent

Clean up claimable_outpoints when pending_claim_requests is cleaned

When claimable_outpoints was introduced in "Move
our_claim_txn_waiting_first_conf to pending_claim_requests", removal
of elements from it (which are just pointers into
pending_claim_requests) was never added.

If 2 claimable-outpoint-spending txn are in 1 block, clean up properly

This resolves an issue where we will never track 2 on-chain events
which are waiting for ANTI_REORG_DELAY at the same height.

This partially reverts and fixes "Move our_claim_txn_waiting_first_conf
to pending_claim_requests".

Log block tick in ChannelMonitor

Correct input comparison for input-subset RBF bump creation

This resolves a regression introduced in "Implement bumping engine in
ChannelMonitor::block_connected" in which not all inputs are checked.
Several opportunities to clarify and clean up comments are also taken.

Fix test_bump_penalty_txn_on_revoked_htlcs as now remote claim txn
build the same way than us are going to be register as cleaning
pending_claim_request after ANTI_REORG_DELAY. It means during this
delay we are going to generate invalid bumped claiming txn on
already claimed outpoints. Previously these txn weren't issued
because all their outpoints would have been removed.

Fix full_stack_target by adding more input for FuzzEstimator

Dont forget RBF previous-feerate info if tx size changed.

While our fee may change wildly (or even go down), the previous
fee *rate* is still valid, and we should use that as the basis for
our RBF.

Add test_set_outpoints_partial_claiming

Track and react to remote partial-claiming of pending claim request

A pending claim request may contain a set of multiple outpoints.
If one or multiple of them get claimed by remote party, our in-flight
claiming transactions aren't valid anymore so we need to react
quickly and regenerate claiming transaction with accurate set.

However, a claimed outpoint may be disconnected and we need to resurrect
back outpoint among set of orignal pending claim request.

To guarantee consistency of contentious claimed outpoint we cache it
as OnchainEvent::ContentionsOutpoint and only delete it after
ANTI_REORG_DELAY.

Fix test broken by change, partial claiming on revoked txn
force us to regenerate txn

Add test_bump_penalty_txn_on_remote_commitment

Add test_bump_penalty_txn_on_revoked_htlcs

Add test_bump_penalty_txn_on_revoked_commitment

Test multiple rounds of 25% heuristic in bump_claim_tx on remote revoked commitment
txn with htlcs pending in both directions.

Add RBF-bumping of preimage/timeout txn on remote HTLC outputs

Given they are only signed by us we can RBF at wish

Fix tests broken by introduction of more txn broadcast
(channel_monitor_network_test)

Add locktime in RemoteHTLC as it's needed to generate
timeout txn.

Implement bumping engine in ChannelMonitor::block_connected

Add RBF-bumping of justice txn, given they are only signed by us we
can RBF at wish.

Aggregation of bump-candidates and more aggresive bumping heuristics
are left open

Fix tests broken by introduction of more txn broadcast.
Some tests may have a relaxed check (claim_htlc_ouputs_single_tx)
as broadcast bumped txn are now interwining in previous broadcast ones
and breaking simple expectations

Use bumping engine to rebuild claiming transaction in case of partial-
claim of its outpoints set.

Remove superflous pending_claims

As local onchain txn are already monitored in block_connected by
check_spend_local_transaction, it's useless to generate twice
pending claims for HTLC outputs on local commitment tx.

We could do the alternative.

Move our_claim_txn_waiting_first_conf to pending_claim_requests

Add claimable_outpoints maps.

Both structures are tied and should ensure their mutual consistency.

Pending_claim_requests is cached by original claim txid. Medatada
and per input material should be constant between bumped transactions,
only change should be partial-claiming of outpoints set and block
reorgs.

Due to RBF rules, if an input has been part of an aggregate tx
at first claim try, if we want the bumped tx to land nicely
in the mempool, inputs should be distributed in multiple
bumped tx but still be aggregate in a new bumped tx.

Add log_trace on bump candidates tracking-buffer insertions

Add MIN_RELAY_FEE_SAT_PER_1000_WEIGHT

Hardcode min relay fee as its value is fixed on the bitcoin network
and updating it would be done really conservatively.

Merge pull request #413 from TheBlueMatt/2019-12-381-nits

381 with a few nits resolved.

Document the default values of configs

Change the new() functions for config to Default::default()

Merge pull request #403 from TheBlueMatt/2019-11-rand-onion

Randomize initial onion packet data.

Randomize initial onion packet data.

This avoids at least the trivial hop count discovery attack, though
other obvious ones remain and are slightly harder to avoid.

See https://github.com/lightningnetwork/lightning-rfc/pull/697

Merge pull request #405 from TheBlueMatt/2019-11-cleanups

Misc Cleanups

Merge pull request #407 from TheBlueMatt/2019-11-396-english

#396 with a few english fixes

Update comments to be a bit more descriptive and fix english a bit

Add test_announce_disable_channels

Add timer_chan_freshness_every_min

Latency/peer disconnection may trigger us to mark as disabled
some of our channels. After some time, if channels are still
disabled we need to broadcast ChannelUpdate to inform other network
peers about the uselessness of these channels.

Add UpdateStatus in Channel to track freshness of gossiped liveness.

Added enum and method are only used in next commit.

Fix add_update_monitor check to unwrap() instead of an unused bool

Move test profile to crate root, so it has effect again

Add dyn tags in fuzz_targets

We only support newish rust in fuzz_targets, so this is fine.

Merge pull request #401 from ariard/2019-11-log-tx-broadcast

Add log for every tx broadcast

Add log for every tx broadcast

Added macro log_tx in macro_logger.rs

Merge pull request #399 from TheBlueMatt/2019-11-fuzz-top-level

Move fuzz to top level.

Move fuzz to top level.

Merge pull request #389 from valentinewallace/split-chain-watch-interface

remove circular references in channelmanager and channelmonitor

chaininterface+multi: add filter_block and reentered to ChainWatchInterface

Because filter_block takes a  and returns a list of s , we must add a lifetime to the ChainWatchInterface, which bubbles up in a lot of places. These places include adding a lifetime  to the Node struct, which causes a lot of rearranging tests so that variables don't go out of scope before the Node that owns them does.

chaininterface: add BlockNotifier struct

Adding this struct will allow us to remove the circular reference
between ChainListeners and the ChainWatchInterface, because it
separates out the responsibility of notifying listeners about new
blocks from the responsibility of storing and retrieving watched
transactions.

multi: remove listeners field and method from ChainWatchInterface

This includes the purpose of this PR, which is to remove the circular reference created by ChainListeners self-adding themselves to their ChainWatchInterface's `listeners` field.

Merge pull request #397 from ariard/2019-11-doc-announce-sigs

Doc announce_sigs

Extend test for announcement_sigs

Document our handling of announcement_sigs

We may have in the future to rebroadcast announcement_sigs at
peer reconnection if this a burning issue as spec lacks
a acknowledgement mechanism.

Merge pull request #379 from rrybarczyk/use-workspaces

Use workspaces to separate crates

Merge branch 'master' of github.com:rust-bitcoin/rust-lightning into use-workspaces

Update travis file to accommodate workspaces

Merge pull request #395 from ariard/2019-11-expected-amt-claim-funds

Avoid probing attacks with same hash lower amounts

Add test_check_htlc_underpaying

Check expected amount in claim_funds

Require to specify expected amount so that we can claim only
payment for thhe correct amount, and reject payments for incorrect
amounts (which are probably middle nodes probing to break our privacy).

Send back incorrect_or_unknown_payments_details (PERM|15) to avoid
the probe node learning that final node is waiting a payment with
the routed hash.

Merge branch 'master' of github.com:rust-bitcoin/rust-lightning into use-workspaces

Merge pull request #394 from TheBlueMatt/2019-11-broken-build

Fix broken build

Drop needless mut

Fix build broken by silent merge conflicts

Merge pull request #393 from ariard/2019-11-send-cmt-error-handling

Fulfill error handling for send_commitment in processing htlcs forward

Merge pull request #390 from ariard/2019-11-consistent-errors

Make field error of ErrorPacket (former HandleError) mandatory

Merge pull request #392 from ariard/2019-11-manager-init-height

Add init height in ChannelManager constructor

Make field error of LightingError mandatory

We also fulfilled last empty ErrorAction:
- Router secp fail : IgnoreError
- processing error in Router : IgnoreError
- get_channel_update too early : IgnoreError

Add init height in ChannelManager constructor

Merge pull request #391 from ariard/2019-11-fix-preimage-collision-onchain

Avoid claiming remote received HTLCs with side-learned preimage

Use workspaces to separate crates

Fulfill error handling for send_commitment in processing htlcs forward

Add test_duplicate_htlc_different_direction_onchain

Avoid claiming remote received HTLCs with preimage

In case of duplicate HTLCs with same hash going in opposite
directions we may learn preimage of offered one, but we shouldn't
claim received one to avoid invalidation of combined claim.
The received HTLC is going to be claimed by a timeout tx at
timelock expiration.

Fix #337

Rename HandleError to LightningError to stress already-processed error

Merge pull request #386 from TheBlueMatt/2019-10-useless-lints

Disable some useless lints

Disable some useless lints

Merge pull request #384 from ariard/2019-10-clean-warnings

Remove useless test framework warnings

Remove useless test framework warnings

Merge pull request #377 from elichai/2019-08-update-deps

Updating dependencies

Update the fuzz and net-tokio crates

Cast weights to u64 to support the new rust-bitcoin api

Updated bitcoin, bitcoin_hashes and secp256k1 dependencies

Merge pull request #374 from dongcarl/2019-08-channel-open-sanity

tests: Add sanity tests for ChannelOpens

tests: Add sanity tests for ChannelOpens

Merge pull request #349 from ariard/2019-07-data_loss

Implement option_data_loss_protect on both sides

Add test_data_loss_protect

Cache to_remote_script if we are fallen-behind

Also, restrict commitment transaction filters in ChannelMonitor::
block_connected

Make get_latest_local_commitment_txn public

You may use it to get a broadcastable local toxic tx in case of fallen-behind,
i.e when receiving a channel_reestablish with a proof that our remote side
knows a higher revocation secret than the local commitment number we are aware
of. Broadcasting these transactions are UNSAFE, as they allow remote side to punish
you. Nevertheless you may want to broadcast them if remote don't close channel with his
higher commitment transaction after a substantial amount of time (a month or even a year)
to get back funds. Best may be to contact out-of-band the other node operator to coordinate
with him if option is available to you. In any-case, choice is up to the user.

Also, log toxic commitment tx id in channel_reestablish sending back
ChannelError::CloseDelayBroadcast

Enforce option_data_loss_protect user-side

If we remote peer provide us a revocation secret which doesn't
match with next_remote_revocation_number we close the channel
If we learn that we are fallen-behind, we send back a CloseDelayBroadcast
error, special take care will be take to log error and channel should
stale, i.e we expect our honest peer to unilateral close to claim
on it our balance

Add ChannelError::CloseDelayBroadcast to signal that you need to close
the channel but not to broadcast it while however update ChannelMonitor
with remote per_commitment_point thanks to our peer being a gentleman

Merge pull request #310 from ariard/2019-02-clarify-send-htlc-policy

Clarify policy applied in send htlc error msgs

Clarify policy applied in send htlc error msgs

max_htlc_value_in_flight_msat is applied
per-direction

Merge pull request #370 from TheBlueMatt/2019-07-369-fix-spaces

2019 07 369 fix spaces