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.
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.
Antoine Riard [Thu, 14 Nov 2019 23:50:24 +0000 (18:50 -0500)]
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.
Antoine Riard [Tue, 5 Nov 2019 00:54:43 +0000 (19:54 -0500)]
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
Antoine Riard [Wed, 13 Nov 2019 00:27:55 +0000 (19:27 -0500)]
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.
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 [Mon, 29 Jul 2019 16:40:43 +0000 (12:40 -0400)]
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).
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
projects / rust-lightning / log