Add TODOs

TESTING

TESTING

Make full_stack_target more absurdly huge and check for funds loss

Connect blocks at the end

Additional asserts to include in fuzztesting (though may get hit?)

Demonstrate mutating functions which are not fully test-covered

Impl ReadableArgs for Arc<ChannelManager>, not just ChannelManager.

This provides a simple wrapper for deserializing right into an
Arc<ChannelManager>, which improves UX a tiny bit when working with
SimpleArcChannelManager types.

Test that we don't forget to track any outputs at monitor-load

This tests, after each functional test, that if we serialize and
reload all of our ChannelMonitors we end up tracking the same set
of outputs as before.

Track the full list of outpoints a chanmon wants monitoring for.

Upon deserialization/reload we need to be able to register each
outpoint which spends the commitment txo which a channelmonitor
believes to be on chain. While our other internal tracking is
likely sufficient to regenerate these, its much easier to simply
track all outpouts we've ever generated, so we do that here.

Fix rustc nightly compiler error.

This works around a regression in nightly rustc that prevents type
inference from working properly.

Run with mutagen on travis.

Sadly our test coverage isn't very good and I had to hunt for
functions to mutate where we fail tests on every mutation mutagen
creates, but committing the framework is a start.

Rewrite lightning-net-tokio using async/await and tokio 0.2

This is a rather major rewrite, using async/await and tokio 0.2,
which cleans up the code a ton as well as adds significantly to
readability.

Swap read_event read type for a slice isntead of a Vec

It looks like we don't currently use the Vec as a Vec, and can
happily take a slice, which makes things easier on the calling
side.

Only run lightning-net-tokio build on Rust 1.39.0+ on Travis.

This disables building the lightning-net-tokio crate on 1.34.2 on
Travis in anticiption of relying on async/await for
lightning-net-tokio, with the nice side-effect of reducing the
amount of work done on our slowest Travis job.

This also adds 1.39.0 to Travis as that is the new MSRV for
lightning-net-tokio.

Panic on txn with value > 21mill in ChannelMonitor::block_connected

full_stack_target found a crash where we may overflow ruring fee
calculation if a transaction appears on-chain with massive value
available for us to claim. Since these transactions are clearly
bogus, we shouldn't allow full_stack_target to connect them, but
we also improve the error generated by explicitly panicing on them.

Drop individual fuzz target duplicate_crash tests for file reader

Previously, in each of our fuzz tests we had a dummy test which
had a hard-coded hex string which it passed into the fuzz target
so that when a failing test case was found, its hex could be
copied into the test and you could run cargo test to analyze the
failure. However, this was somewhat unwieldy as converting large
tests back and forth between hex and raw files is quite annoying.

Instead, we replace each of those tests with a test in each target
that looks for files in fuzz/test_cases and runs each file it finds.

Since we're editing every bin target anyway, we also automate adding
no_main to libfuzzer builds with #![cfg_attr].

Silence new rustc warnings re: extra ()s, dyn, and unused params

Only expose constants exposed for testing in cfg(test)

Fix deadlock in handle_error!() when we have HTLCs to fail-back.

This partially reverts 933ae3470309f21ef7537ffbcdc42070d60e1e74,
though note that 933ae3470309f21ef7537ffbcdc42070d60e1e74 fixed a
similar deadlock while introducing this one.

If we have HTLCs to fail backwards, handle_error!() will call
finish_force_close() which will attempt to lock channel_state while
it is locked at the original caller.

Test that EnforcingChannelKeys doesn't panic on duplicate RAAs

Fix EnforcingChannelKeys panic when our counterparty burns their $.

If our counterparty burns their funds by revoking their current
commitment transaction before we've sent them a new one, we'll step
forward the remote commitment number. This would be otherwise fine
(and may even encourage them to broadcast their revoked state(s) on
chain), except that our new EnforcingChannelKeys expects us to not
jump forward in time. Since it isn't too important that we punish
our counterparty in such a corner-case, we opt to just close the
channel in such a case and move on.

Test basic AMP payments in chanmon_consistency

Time out AwatingRemoteRAA outgoing HTLCs when we reach cltv_expiry

In case of committing out-of-time outgoing HTLCs, we force
ourselves to close the channel to avoid remote peer claims on a
non-backed HTLC

Time out incoming HTLCs when we reach cltv_expiry (+ test)

We only do this for incoming HTLCs directly as we rely on channel
closure and HTLC-Timeout broadcast to fail any HTLCs which we
relayed onwards where our next-hop doesn't update_fail in time.

Refactor test utils and add a simple MPP send/claim test.

Implement multipath sends using payment_secret.

This rather dramatically changes the return type of send_payment
making it much clearer when resending is safe and allowing us to
return a list of Results since different paths may have different
return values.

Expand the Route object to include multiple paths.

Rather big diff, but its all mechanical and doesn't introduce any
new features.

Add/announce features for payment_secret and basic_mpp

Impl Base AMP in the receive pipeline and expose payment_secret

Sadly a huge diff here, but almost all of it is changing the method
signatures for sending/receiving/failing HTLCs and the
PaymentReceived event, which all now need to expose an
Option<[u8; 32]> for the payment_secret.

It doesn't yet properly fail back pending HTLCs when the full AMP
payment is never received (which should result in accidental
channel force-closures). Further, as sending AMP payments is not
yet supported, the only test here is a simple single-path payment
with a payment_secret in it.

Refuse to deserialize OnionHopDatas with values > 21 million

We should probably do this for all values (and define a newtype
for msat values), but this will do for now.

Support (de)serializing payment_data in onion TLVs and track them

This is the first step in Base AMP support, just tracking the
relevant data in internal datastructures.

Split only-receive/forward data out of PendingHTLCInfo into an enum

This should avoid blowing up the size of the struct when we add
additional data that is only relevant for receive.

Clarify the in-flight HTLC state-tracking structs a bit.

This also renames PendingForwardHTLCInfo to PendingHTLCInfo since
it now also encompasses Pending *Received* HTLCs.

Add some basic sanity tests for feature flags

Avoid treating option_upfront_shutdown (req) as unknown_required.

This fixes the bitmask in requires_unknown_bits.

Add ability to broadcast our own node_announcement.

This is a somewhat-obvious oversight in the capabilities of
rust-lightning, though not a particularly interesting one until we
start relying on node_features (eg for variable-length-onions and
Base AMP).

Sadly its not fully automated as we don't really want to store the
list of available addresses from the user. However, with a simple
call to ChannelManager::broadcast_node_announcement and a sensible
peer_handler, the announcement is made.

Allow node_announcement timestamps of 0 in accordance with BOLT 7

Unlike channel_update messages, node_announcement messages have no
requirement that the timestamp is greater than 0.

Add a helper struct to allow a user to safely pass in an addr list

Use RouteHop's new node_features to send TLV-encoded onion hops

This implements the new TLV variable-length encoding for onion hop
data, opting to send it if the RouteHop's node_features indicates
support. It also uses the new process_inline method in ChaCha20 to
optimize a few things (though it grows a new TODO for a
probably-important optimization).

Add support for variable-length onion payload reads using TLV

Add macros for building TLV (de)serializers.

There's quite a bit of machinery included here, but it neatly
avoids any dynamic allocation during TLV deserialization, and the
calling side looks nice and simple. The macro-generated code is
pretty nice, though has some redundant if statements (I haven't
checked if they get optimized out yet, but I can't imagine they
don't).

Expose VecWriter outside of util::ser since peer_handler uses it

Add new streams and serialization wrappers for TLV types.

This adds a number of new stream adapters to track and/or calculate
the number of bytes read/written to an underlying stream, as well
as wrappers for the two (?!) variable-length integer types that TLV
introduces.

Add a ChaChaReader adapter to read an encrypted stream & use it

This prepares for variable-length per-hop-data by wrapping the full
hop_data field in a decrypting stream, with a few minor
optimizations and redundant allocations to boot.

Move BogusHopData generation into test instead of OnionHopData.

This, as it should be, restricts OnionHopData to only being able to
represent valid states, while still allowing for tests to generate
bogus hop data fields to test deserialization.

Pull hmac out of OnionHopData.

Its a bit awkward to have an hmac field covering the struct that
its in, and there is little difference in removing it, so just pull
it out and use a [u8; 32] where we care about the hmac.

Flatten OnionHopData struct with the Realm0 struct.

Previously OnionHopData contained a OnionRealm0HopData field however
instead of bumping the realm number, it has been replaced with a
length, used to indicte the length of a TLV-formatted object.

Because a TLV-formatted hop data can contain the same information as
a realm-0 hop data, we flatten the field and simply keep track of
what format it was in.

Better document msg fuzz target behavior and be slightly more strict

Merge pull request #459 from ariard/2020-01-fix-htlc-height-timer

Fix bumping timer for claiming revoked HTLC outputs

Merge pull request #460 from lightning-signer/channel-value

Channel value to ChannelKeys constructor

Merge pull request #458 from TheBlueMatt/2020-01-spendable-docs

Clean up documentation around spendable outputs significantly.

Merge pull request #443 from valentinewallace/channelmgr-arcs-to-derefs

Drop ChannelManager's ChannelMonitor Arc for Deref

Clean up documentation around spendable outputs significantly.

 * Fixed a number of grammar issues
 * Clarified the docs for users who are intimately farmiliar with
   arbitrary lines of text copied from the BOLTs
 * Added a bit more text so that things are easier to read and less
   disjoint.
 * Clarified exactly how the witness stack should look since I had
   to go dig for it.

Update ChannelManager's ChannelMonitor Arc to be a Deref

Additional changes:
* Update fuzz crate to match ChannelManager's new API
* Update lightning-net-tokio library to match ChannelManager's new ChannelMonitor Deref API
* Update tests to match ChannelManager's new ChannelMonitor Deref API

Remove unnecessary sign_closing_transaction arg

channel value to ChannelKeys constructor

Fix bumping timer for claiming revoked HTLC outputs

Previously, we were using their_to_self_delay instead of
our_to_self_delay which was falsifying test.

Merge pull request #457 from ariard/2020-01-fix-append-onchain

Fix spurious calls of broadcast_by_local_state

Merge pull request #433 from TheBlueMatt/2019-12-features-in-routes

Plumb Features through into Routes

Fix spurious calls of broadcast_by_local_state

DRY-up list_channels by having a common lister that takes a filter

Pass node features through to RouteHops

This exposes the latest Init-context features in the ChannelDetails
passed to the Router during route calculation, which combines those
with the Node-context features tracked from node_announcements to
provide the latest Node-context features in RouteHop structs.

Fields are also added for Channel-context features, though those are
only partially used since no such features are defined today anyway.

These will be useful when determining whether to use new
TLV-formatted onion hop datas when generating onions for peers.

Keep track of the Init Features for every connected/channel'd peer

Since we want to keep track of the Init-context features for every
peer we have channels with, we have to keep them for as long as the
peer is connected (since we may open a channel with them at any
point).

We go ahead and take this opportunity to create a new per-peer-state
struct which has two levels of mutexes which is appropriate for
moving channel storage to.

Since we can't process messages from a given peer in parallel, the
inner lock is a regular mutex, but the outer lock is RW so that we
can process for different peers at the same time with an outer read
lock.

Pass peer's Init message through to ChannelManager

Merge pull request #451 from lightning-signer/txkeys

Provide remote channel public keys to signer

Use ChannelPublicKeys in Channel

Hide derived fields in TxCreationKeys

Provide remote channel public keys to signer

Merge pull request #447 from ariard/2020-01-fix-weight-computation

Bound incoming HTLC witnessScript to min/max limits

Bound incoming HTLC witnessScript to min/max limits

Fix a crash where previously we weren't able to detect any accepted
HTLC if its witness-encoded cltv expiry was different from expected
ACCEPTED_HTLC_SCRIPT_WEIGHT. This should work for any cltv expiry
included between 0 and 16777216 on mainnet, testnet and regtest.

Fix crash when a claim tx has some non-witness inputs.

The logger which decides what to refer to an on-chain claim tx was
assuming that all inputs would have a witness. While this was fine
for the one-input case, it broke the fuzzer which was connecting a
consensus-invalid transaction. Further, in the case we have multiple
inputs, some may not have a witness, which we shouldn't crash on.

This fixes 9df0250dbbad7449e3ec8f90532ce9197eb31997.

Merge pull request #450 from ariard/2020-01-fix-fst-blk-disconnection

Fix full_stack_target block disconnection

Fix full_stack_target mishandling of block disconnection

Log block disconnection in ChannelMonitor

Merge pull request #448 from lightning-signer/visibility-for-test

Increase visibility for external integration tests

increase visibility for external integration tests

Merge pull request #444 from lightning-signer/funding-script

Construct funding redeem script in signer

construct funding redeem script in signer

Merge pull request #449 from jkczyz/2020-01-remove-borrow-parts

Remove unnecessary borrow_parts() methods

Remove unnecessary borrow_parts() methods

Accessing a struct through an std::syn::MutexGuard using implicit
dereferencing can confuse the borrow checker. This situation arises when
obtaining mutable references to more than one field of the struct, which
is normally allowed.

https://doc.rust-lang.org/nomicon/borrow-splitting.html

However, when using implicit dereferencing, a mutable reference to the
the entire struct is taken. Thus, attempting to access another field in
this manner will lead to a compilation error.

https://doc.rust-lang.org/error-index.html#E0499

A simple way to avoid this is to first obtain a mutable reference to the
struct using explicit dereferencing.

Merge pull request #428 from TheBlueMatt/2019-12-flat-features

Implement Flat Features

Seal the features contexts

Move features into a separate module out of msgs.

Refactor features a bit more to describe what the constructors do

The Features::new() method is nonsense and doesn't describe what
features were being set - we introduce an empty() and supported()
constructors instead.

Fix Feature endianness by swapping bytes on read/write.

The spec is a bit mum on feature endianness, so I suppose it falls
under the "everything is big endian unless otherwise specified"
clause, but we were treating it as little.

Relay/store channel/node announces w/ unknown req'd feature bits

This change was made in the flat features BOLT PR, as if a channel
requires some unknown feature bits we should still rumor it, we just
shouldn't route through it.

Implement Flat Features

This merges local and global features into one struct, which is
parameterized by where it appers. The parameterization restricts
which queries can be made and which features can be set, in line
with the latest BOLT 9.

Closes #427.

Merge pull request #439 from TheBlueMatt/2020-01-398-fixups

398 with nits fixed.

Drop Result for ChannelMessageHandler methods

Simplify interfaces between ChannelMessageHandler and PeerManager,
by switching all ChannelMessageHandler errors to HandleError sent
internally instead of being return. With further refactors in Router
and PeerChannelEncryptor, errors management on the PeerManager-side
won't be splitted between try_potential_handleerror and HandleError
processing.

Inside ChannelManager, we now log MsgHandleErrInternal and send
ErrorAction to PeerManager.

On a high-level, it should allow client using API to be more flexible
by polling events instead of waiting function call returns.

We also update handle_error macro to take channel_state_lock from
caller which should avoid some deadlock potential for some edges
cases.

Filter out IgnoreError in handle_error macro, update test in
consequence.

Add assert_log method to TestLogger to harden test

Extend mock Node with logger.

Merge pull request #437 from Aleru/new-api-ping

New API for ping generation

New API for ping generation

New API for generating pings

Merge pull request #420 from TheBlueMatt/2019-12-chan-ext-signer

Remove signing from Channel

Sign local HTLC transactions at broadcast-time, instead of generate

Make ChannelMonitor sign local transactions (at broadcast time)

Set basic channel info in chanmon all at once, add a bit more info

Drop duplicative current-local-tx storage in channel.

We now have current-local-tx broadcast ability in channel monitors
directly (for ChannelManager deserialization), so we can just use
that instead of always having the Channel store signed ready-to-go
copies of the latest local commitment transaction.

This is further kinda nice since ChannelMonitor is live and can, eg
broadcast HTLC-Success transactions immediately as they will be
generated at broadcast time instead of in advance.

Finally, this lets us clean up a tiny bit in Channel.

Fix parameter name incorrectly changed in 4ebe64fafd2ca0e17aab31fb0

Merge pull request #426 from TheBlueMatt/2019-12-bad-lifetimes

Remove unused lifetimes.