Matt Corallo [Thu, 18 Jul 2019 23:51:12 +0000 (19:51 -0400)]
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.
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
Antoine Riard [Tue, 9 Jul 2019 18:38:30 +0000 (14:38 -0400)]
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
Antoine Riard [Thu, 18 Jul 2019 21:27:48 +0000 (17:27 -0400)]
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
Antoine Riard [Thu, 18 Jul 2019 22:50:03 +0000 (18:50 -0400)]
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.
Matt Corallo [Thu, 18 Jul 2019 22:13:28 +0000 (18:13 -0400)]
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.
Antoine Riard [Fri, 31 May 2019 00:54:02 +0000 (20:54 -0400)]
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
Matt Corallo [Fri, 14 Jun 2019 22:45:38 +0000 (18:45 -0400)]
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.
Matt Corallo [Sat, 1 Jun 2019 11:02:31 +0000 (07:02 -0400)]
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.
Matt Corallo [Tue, 5 Mar 2019 20:36:11 +0000 (15:36 -0500)]
Rewrite Channel resend tracking to make it much more reliable
Resending revoke_and_ack and commitment_signed (+update) messages
after monitor-update-failure or disconnection has been a highly
unreliable part of our codebase for some time (as evidenced by the
number of bugs caught in the chanmon_fail_consistency fuzz target).
This is due to its rather ad-hoc nature and tracking/behavior which
consists of checking a number of different flags to try to deduce
which messages were/were not delivered and go from there. Instead,
this commit rewrites it to simply keep track of the order messages
were generated originally, as we always resend in the
originally-generated order.
I'm anticipating this will be way more robust than the old code, in
addition to its simplicity.
Matt Corallo [Sun, 3 Mar 2019 19:02:51 +0000 (14:02 -0500)]
Move fail_reason into OutboundHTLCState states
This should probably have happened when we moved most state into
the state enums themselves, but specifically forcing awareness of
the removed/not removed state would have prevented me from
introducing a bug in the first version of an upcoming reserve-value
patch.
Carl Dong [Thu, 7 Feb 2019 18:08:21 +0000 (13:08 -0500)]
util: Derive PartialEq for Level
PartialEq, Eq, and Hash should all be derived together wherever possible
to not violate Hash invariants. See the documentation for
std::hash::Hash for more details.
Matt Corallo [Mon, 21 Jan 2019 16:44:59 +0000 (11:44 -0500)]
Fix holding cell freeing in case we fail to add some HTLC
Previously, if we went to free the holding cell HTLC updates, and
adding one failed as we hit our outbound HTLC limit (or in-flight
value limit), we would not send a commitment_signed, leaving us in
an invalid state. We first fix that bug, and then refuse to add
things to our holding cell once we reach our limits considering the
holding cell, as we shouldn't have multiple commitment dance rounds
worth of HTLCs in the holding cell anyway.
Matt Corallo [Tue, 8 Jan 2019 04:11:37 +0000 (23:11 -0500)]
Drop pending outbound messages on peer disconnection
This shouldn't be required, but it may help prevent some downstream
race conditions due to clients not sending message events quickly
enough and trying to send stale messages before new
channel_reestablish messages.
projects / rust-lightning / log