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 and uses that for codecov generation.
This also moves fuzzing to Rust stable, as honggfuzz broke its MSRV
and it seems likely it will again in the future.
This is the next step after "Move pending-HTLC-updated ChannelMonitor
from ManyChannelMonitor", moving our events into ChannelMonitor as
well and leaving only new-outputs-to-watch in the return value for
ChannelMonitor::block_connected (which is fine as those are
duplicatively tracked in the ChannelMonitor directly, so
losing/replaying them is acceptable).
As noted in the docs, Events don't round-trip fully, but round-trip
in a way that is useful for ChannelManagers, specifically some events
don't make sense anymore after a restart.
In testing, due to other patches, I managed to flood the send queue
with messages and cause us not to be able to send pings, thus
getting a peer disconnected for ping timeout. To my surprise, this
also force-closed all of my channels with that peeer.
Obviously a ping timeout does not indicate that no future connection
with said peer will be possible, and we shouldn't be force-closing
channels as a result.
This also logs when a peer is disconnected to ping timeout to make
debug easier.
This removes the somewhat-easy-to-misuse Clone from ChannelMonitors,
opening us up to being able to track Events in ChannelMonitors with
less risk of misuse.
Sadly it doesn't remove the Clone requirement for ChannelKeys,
though gets us much closer - we now just need to request a second
copy once when we go to create the ChannelMonitors.
This removes the ability to merge ChannelMonitors in favor of
explicit ChannelMonitorUpdates. It further removes
ChannelManager::test_restore_channel_monitor in favor of the new
ChannelManager::channel_monitor_updated method, which explicitly
confirms a set of updates instead of providing the latest copy of
each ChannelMonitor to the user.
This removes almost all need for Channels to have the latest
channel_monitor, except for broadcasting the latest local state.
This is a rather huge diff, almost entirely due to removing the
type parameter from ChannelError which was added in
c20e930b31 due to holding the
ChannelKeys in ChannelMonitors.
This prepares for only creating the ChannelMonitor on funding by
removing any channel_monitor calls from Channel open/accept-time to
funding-signed time.
This is a rather big step towards using the new ChannelMonitorUpdate
flow, using it in the various commitment signing and commitment
update message processing functions in Channel. Becase they all
often call each other, they all have to be updated as a group,
resulting in the somewhat large diff in this commit.
In order to keep the update_ids strictly increasing by one for
ease of use on the user end, we have to play some games with the
latest_monitor_update_id field, though its generally still pretty
readable, and the pattern of "get an update_id at the start, and
use the one we got at the start when returning, irrespective of
what other calls into the Channel during that time did" is
relatively straightforward.
This is the first of several steps to update ChannelMonitor updates
to use the new ChannelMonitorUpdate objects, demonstrating how the
new flow works in Channel.
This is the first step in migrating ChannelMonitor updating logic
to use incremental Update objects instead of copying the
ChannelMonitors themselves and insert_combine()ing them.
This adds most of the scaffolding and updates relevant comments to
refer to the new architecture, without changing how any actual
updates occur.
Currently Channel relies on its own internal channel_monitor copy
to keep track of funding_txo information, which is both a bit
awkward and not ideal if we want to get rid of the ChannelMonitor
copy in Channel.
Instead, just duplicate it (its small) and keep it directly in
Channel, allowing us to remove the (super awkward)
ChannelMonitor::unset_funding_txo().
In the process of removing a local ChannelMonitor in each Channel,
we need to track our counterpartys' commitment secrets so that we
can check them locally instead of calling our channel monitor to
do that work for us.
In order to drop the ChannelMonitor from Channel, we need to track
remote per_commitment_secrets outside of the monitor to validate new
ones as they come in.
This just moves the current code from ChannelMonitor into a new
CounterpartyCommitmentSecrets struct in chan_utils.
The way PeerHandler was written, it was supposed to remove from
self.peers iff the API docs indicate that disconnect_event should
NOT be called (and otherwise rely on disconnect_event to do so).
Sadly, the implementation was way out of whack with reality - in
the implementation, essentially anywhere where PeerHandler
originated the disconnection, the peer was removed and no
disconnect_event was expected. The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.
We opt to change the docs, mostly, as well as clean up the
ping/pong handling somewhat and rename a few functions to clarify
what they actually do.
This is important for a number of reasons:
* Firstly, I hit this trying to implement rescan in the demo
bitcoinrpc client - if individual ChannelMonitors are out of
sync with each other, we cannot add them all into a
ManyChannelMonitor together and then rescan, but need to rescan
them individually without having to do a bunch of manual work.
Of the three return values in ChannelMonitor::block_connected,
only the HTLCsource stuff that is moved here makes no sense to
be exposed to the user.
* Secondly, the logic currently in ManyChannelMonitor cannot be
reproduced by the user! HTLCSource is deliberately an opaque
type but we use its data to decide which things to keep when
inserting into the HashMap. This would prevent a user from
properly implementing a replacement ManyChannelMonitor, which is
unacceptable.
* Finally, by moving the tracking into ChannelMonitor, we can
serialize them out, which prevents us from forgetting them when
loading from disk, though there are still other races which need
to be handled to make this fully safe (see TODOs in
ChannelManager).
This is safe as no two entries can have the same HTLCSource across
different channels (or, if they did, it would be a rather serious
bug), though note that, IIRC, when this code was added, the
HTLCSource field in the values was not present.
We also take this opportunity to rename the fetch function to match
our other event interfaces, makaing it clear that by calling the
function the set of HTLCUpdates will also be cleared.
