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

Add net-tokio/target to gitignore

Make SocketDescriptor::send_data take slice instead of vec and offset

Merge pull request #367 from TheBlueMatt/2019-07-fst-unique-channels

Make temporary channel ids unique in full_stack_target

Merge pull request #368 from TheBlueMatt/2019-07-travis-fix

Fix travis failure if previous travis run on branch failed to build

Fix travis failure if previous travis run on branch failed to build

Support option_data_loss_protect for remote peer

In case of sending channel_reestablish message, we join
our current per_commitment_point and their highest revocation
secret we know about

We set data_loss_protect by default and adjust encoding_init
test in consequence

Merge pull request #364 from TheBlueMatt/2019-07-no-unimpl

Implement the last three (relevant) unimplemented()s in ChannelManager

Merge pull request #366 from TheBlueMatt/2019-07-useless-todo-removal

Drop some useless TODO messages to clean things up pre-0.1

Handle monitor update failure during funding on the fundee side

This carries a surprising amount of complexity despite only being
possible in the case where monitor updating failed during the
processing of funding_generated. Specifically, this requires
handling rebroadcasting funding_locked once we successfully persist
our monitor again.

As an alternative we could never send funding_signed when the
monitor failed to persist, but this approach avoids needless
delays during funding.

Allow a counterparty to resend their funding_locked before ours

Handle monitor update failures during funding on the funder side

Make temporary channel ids unique in full_stack_target

This avoids a crash where a channel with a duplicate id is created
immediately after another is closed, where the other still has a
pending funding generation event. Resulting in funding generation
being passed to the wrong channel (which isn't in an appropriate
state).

Drop TODO suggesting we avoid a test-only function to get chan keys

It suggested figuring something else out after #81, but the API we
settled on after #81 (which I think is just fine) doesn't allow for
anything cleaner, so this is fine as-is.

Drop update_fee TODOs as we're gonna drop it before 0.1 anyway

See #365 for more.

Merge pull request #363 from TheBlueMatt/2019-07-codecov

Generate codecov.io reports

Generate codecov.io reports

Merge pull request #361 from TheBlueMatt/2019-07-cmfc-crash

Make chanmon_fail_consistency slightly less aggressive

Merge pull request #362 from TheBlueMatt/2019-07-no-bogus-sec-required

Do not require upfront_shutdown as the security gain is marginal

Do not require upfront_shutdown as the security gain is marginal

There is really no reason to want to never open a channel just
because a counterparty doesn't support upfront_shutdown.

Make chanmon_fail_consistency slightly less aggressive

This resolves some crashes that both afl and honggfuzz found.

Merge pull request #360 from TheBlueMatt/2019-07-new-warnings

Fix unused variable introduced in my changes in bdbf5666a9d693b9bf1

Merge pull request #355 from ariard/2019-07-fix-csv-delay-check-remote-htlc

Fix bug in check_spend_remote_htlc and let csv delays being user configurable

Add test_user_configurable_csv_delay

Extend test_justice_tx with user-set csv delay to test that
we are able to claim revokeable outputs with different csv delay
between both peers.

Add user configurable csv delay encumbering channel refund output,

within reasonable lower or upper bound

Add our_to_self_delay in Channel, to cache user config field at
channel construction.

Move BREAKDOWN_TIMEOUT/MAX_LOCAL_BREAKDOWN_TIMEOUT in ChannelManager

Let these values being used as default ones in UserConfig.

Also, reduce them to something more reasonable, for BREAKDOWN_TIMEOUT
from 1 week to 1 day, for MAX_LOCAL_BREAKDOWN_TIMEOUT from 2 weeks
to 1.

Fix unused variable introduced in my changes in bdbf5666a9d693b9bf1

The original was written by Tamas, but I made one small tweak and
broke the warning-free-ness of it.

Merge pull request #359 from rust-bitcoin/2019-07-bump-percentage

Bump progress tracker

Merge pull request #356 from TheBlueMatt/2019-07-more-chanmon-fuzz

Add deserialize+load steps to chanmon_fail_consistency (fixes #327)

Bump progress tracker

Honestly mostly cause we have progress on simplified_commitment in Core, but also our punishment transaction generation stuff is really coming along nicely.

Merge pull request #358 from TheBlueMatt/2019-07-no-unsafe

forbid unsafe

Add deserialize+load steps to chanmon_fail_consistency (fixes #327)

forbid unsafe

Fix: use our_to_self_delay in check_spend_remote_htlc

We were previously using their_to_self_delay to regenerate scripts for
spending remote revoked htlc transactions, and that's a bug.

Their_to_self_delay is delay enforced by peer upon outputs returning
funds back to us.

Our_to_self_delay is delay enforced by us upon outputs returning funds
back to peer.

Drop msgs bound for a disconnecting peer at disconnect time

This simplifies chanmon_fail_consistency greatly and makes it a
tiny bit more realistic. It also sets us up for more
disconnect-relatex events without the complexity blowing up.

Fix some newly-introduced unused-$THING warnings

Merge pull request #353 from TheBlueMatt/2019-07-no-rand

Make rand a dev-dependency

Make rand a dev-dep by having the user randomize HTLC forward delay

This removes the last calls to rand outside of test and moves the
dep to a dev-dependency, dropping our fuzz rng wrapper in the
process.

Stop using rng in peer_channel_encryptor to generate ephemeral keys

This removes the bulk of our reliance on the rand crate in non-test
envs, paving a way towards a syscall-less rust-lightning and WASM.
Since this is a breaking change for full_stack_target (and several
fuzz targets), go ahead and make other changes to make things more
distinct.

Update commitment tx to match actual tx (dunno when it broke)

Move travis fuzzing to 1.34.2 to get integer atomics

Remove dangling link in fuzz/

Drop rng and SystemTime calls from KeysManager

They were only used for ensuring generated keys were globally
unique (ie in case the user opened the same seed at a different
time, we need generated keys to be globally unique).

Instead, we let the user specify a time in secs/nanos, and provide
a precise meaning for the user to understand.

Merge pull request #348 from ariard/2019-07-upfront-shutdown-script

Implement option_upfront_shutdown_script on both sides

Test option_upfront_shutdown_script

Pass UserConfig to node creation test utilities

We way want more granularity on the set of user opt-in features at
a given time, specially with new 1.1 spec features

Pass LocalFeatures flag to channel creation test utilities

We may want more granularity on the set of features activated at
a given time, specially with new 1.1 spec features

Implement option_upfront_shutdown_script user-side

We use user config to decide to commit to closing script
in open_channel/accept_channel messages. We don't check
that other peer supporting the option as including
script without other peer public support is borne by
the protocol. If user opt-out, following protocol and
due to the fact we always signal, we provide a zero-length
script

Support option_upfront_shutdown_script for local peer

Track shutdown_pubkey of peer at open/accept_channel messages

Fix encoding_init test

Provide peer local_features to handle_open_channel/accept_channel

Peer may send us a shutdown_scriptpubkey in open_channel or
accept_channel messages. Before to enforce this policy on channel
closing, we want to be sure that our peer has opt-in to it.

Extend LocalFeatures new method visibilty from crate to public
for fuzz tests

Merge pull request #336 from ariard/2019-04-in-flight-txn-tracking-clean

2019 04 in flight txn tracking clean

Implement dynamic height timer for bump candidates txn

We must adapt our delay between two bumps of claim txn in respect
to the timelock encumbering the targeted outpoint. If HTLC or
revoked output is near to expire, we should try to get our claim
in every block. If it's reasonably in the future, we may give us
more latency to bump

Add in-flight claim-tx tracking

When we generate a justice tx, a htlc tx on remote commitment or
a htlc tx on local commitment we track them until first conf.

Add more comments about timelock assumptions and security model

Rename HTLC_FAIL_ANTI_REORG_DELAY to ANTI_REORG_DELAY because
we are going to rely on it also to remove bump candidates outpoint
from tracker after claim get enough depth.

Rename HTLC_FAIL_TIMEOUT_BLOCKS to LATENCY_GRACE_PERIOD_BLOCKS because
it's carrying more meaningfully that we are doing a favor to our
peer instead of ruthlessly enforcing the contract.

CLTV_EXPIRY_DELTA should be > to LATENCY_GRACE_PERIOD_BLOCKS +
+CLTV_CLAIM_BUFFER + ANTI_REORG_DELAY + LATENCY_GRACE_PERIOD_BLOCKS
When we reached height + LATENCY_GRACE_PERIOD_BLOCKS and we have pending
unsolved outbound HTLC, we fail onchain with
our local commitment tx. At this point we expect to get in chain in a
worst-case delay of CLTV_CLAIM_BUFFER. When our HTLC-timeout is
confirmed with ANTI_REORG_DELAY we may safely fail backward the
corresponding inbound output.

Merge pull request #340 from TheBlueMatt/2019-06-channeldetails-fields

Add balance and is_live fields to ChannelDetails

Merge pull request #351 from TheBlueMatt/2019-07-no-instant

Drop system clock calls for PendingHTLCsForwardable events.

Drop system clock calls for PendingHTLCsForwardable events.

Instead, return a Duration and let the user do the work of waiting.
This is one of only a handful of steps to make us
mostly-syscall-free, at least enough to run in WASM according to
elichai.

Drop time_created in HTLCAwaitingACK::AddHTLC (we can use the CLTV)

Add balance and is_live fields to ChannelDetails

Move htlc_updated_waiting_threshold_conf to an OnchainEvent model

We need also to track claim tx until their maturation to know
when we may safely remove them from could-be-bumped-txn buffer

Add block_disconnecting tests to cancel HTLC failure updates

Add test_sweep_outbound_htlc_failure_update

Fail back dust HTLC of local commitment tx after enough confirmations

Add test_failure_delay_htlc_local_commitment and
test_no_failure_dust_htlc_local_commitment

Move some bits of check_spend_remote as we need to fail dust HTLCs
which can be spread on both prev/lastest local commitment tx

Delay failure of non-dust HTLC-outputs until solving timeout tx matures

Fix tests broken by introduced change

Implement block_disconnect for pruning of waiting-conf HTLC updates

Modify ChainListener API by adding height field to block_disconnect

Track HTLC-failure trigger tx until anti-reorg delay reached

Broadcasting a commitment tx means that we have to fail
inbound HTLC in backward channel. Doing it prematurely would
put us at risk in case of reorg. So we delay passing failure
update upstream until solving tx mature to HTLC_FAIL_ANTI_
REORG_DELAY.
Requirements differ if HTLC is a revoked/non-revoked dust/
non-revoked non-dust one.

Add connect_blocks in test_utils to fix broken tests due to
anti-reorg delay enforcement

Remove anti-duplicate htlc update stuff in ManySimpleChannelMonitor

Add log_trace on to_remote/to_local inclusion in commitment tx

Merge pull request #346 from ariard/log_trace_remote_local_outp

Add log_trace on to_remote/to_local inclusion in commitment tx

Add log_trace on to_remote/to_local inclusion in commitment tx

Merge pull request #341 from TheBlueMatt/2019-06-fuzz-crash-fee-sub

Gracefully handle fee-larger-than-claimed-value in ChannelMonitor

Gracefully handle fee-larger-than-claimed-value in ChannelMonitor

This resulted in a full_stack_target failure as we overflow during
subtraction otherwise.

Instead, we try lower and lower fee estimator confirmation targets
until we find one low enough, or discard the transaction. We should
be able to handle this much cleaner, but for now this at least gets
the fuzzer working again.

Merge pull request #339 from TheBlueMatt/2019-06-net-tokio-ver-bump

Add subcrate that implements network socket handling with Tokio, bump to 0.0.9

Bump version to 0.0.9 to get current master fixes uploaded.

Add subcrate that implements network socket handling with Tokio

This is still pretty raw and ist mostly just a straight move from
rust-lightning-bitcoinrpc, but first step is to get it there,
second is to actually make it actually safe to use.

Bump rust-bitcoin dep to 0.18

Merge pull request #320 from TheBlueMatt/2019-03-chan-send-rewrite

Rewrite Channel resend tracking to make it much more reliable

Merge pull request #334 from ariard/2019-04-fee-estimation-monitor

Add Fee Estimation in ChannelMonitor

Assert that our weight prediction can't result in unspendable txn

Add unit test for get_witnesses_weight

Add fee estimation in check_spend_remote_htlc

Add FeeEstimator in ChannelMonitor

Merge pull request #335 from TheBlueMatt/2019-04-330-nits

Make channel open confs configurable (and change from 12 to 6)

Make channel open confs configurable (and change from 12 to 6)

This fixes compatibility with c-lightning etc as they won't accept
a minimum_depth of 12.

Merge pull request #332 from ariard/2019-03-option-serialize-channel-monitor

Use more Writeable/Readable for Option<T> in ChannelMonitor serializer/deserializer

Use more Writeable/Readable for Option<T> in ChannelMonitor