Antoine Riard [Thu, 1 Aug 2019 14:54:02 +0000 (10:54 -0400)]
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
Antoine Riard [Wed, 10 Jul 2019 20:39:10 +0000 (16:39 -0400)]
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
Matt Corallo [Mon, 29 Jul 2019 17:45:35 +0000 (13:45 -0400)]
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.
Matt Corallo [Sun, 28 Jul 2019 00:49:44 +0000 (20:49 -0400)]
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.
Matt Corallo [Wed, 24 Jul 2019 20:03:48 +0000 (20:03 +0000)]
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.
Matt Corallo [Tue, 23 Jul 2019 19:39:11 +0000 (15:39 -0400)]
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.
Matt Corallo [Fri, 19 Jul 2019 02:17:36 +0000 (22:17 -0400)]
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.
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.
projects / rust-lightning / log