This fixes a bug in 3518f1f85d where
we may generate an output event for a P2WPKH output which is not
ours if the transaction has a sequence/lock_time combination which
false-positives our remote tx detection.
Also note that the TODO is removed as this should already be
covered without issue if the client properly replays the chain on
restart.
This extends 1b33064554 by
re-simplifying the ChannelMonitor <-> Channel interface a bit as we
never have any use for the latest remote commitment point until we
have knowledge of a remote transaction generated using it.
This is a big patch, but its all very mechanical, everything here
should be pretty obvious, and it all has to happen at once due to a
few common utility functions all having the same return type.
Note that this exposes a race in channel closure where we may
access a channel via some non-peer-specific mechanism like
forwarding an HTLC or sending a payment during the time between
the channel gave us a Close error and expected us to never call it
again and the time we actually removed it from the channel_state
set outside of the internal_* handler.
This fixes a bug in 78232f2aed found
by fuzzer - if the channel isn't yet fully established we will call
get_channel_update(), get an Err result, and then unwrap() it. If
this actually happens it means someone on the network is making up
short_channel_ids and trying to route over them, but that shouldn't
result in us crashing
366e79615b fixed the same crash for
Errs that come up during handshake, but was incomplete and should
have just dropped the node_id being different based on
inbound/outbound. This patch does so and actually fixes the issue.
Found by fuzzer.
See https://github.com/lightningnetwork/lightning-rfc/issues/499
for a bit more about the ambiguity we're addressing here.
Also drop holding cell update_fee the same way we drop holding
cell update_add_htlcs when sending shutdown, resolving a bug.
If we make an outbound connection to a peer who we are already
connected to, and the outbound connection fails
pre-noise-completion, we will remove the original peer connection
from our node_id_to_descriptor map.
The fuzzer managed to find this by crashing in Channel's assertions
that we don't do a get_channel_reestablish() when the Channel isn't
already marked disconnected.
We always require that any changes to Channel state be committed
immediately (within the same lock) so we should never have
uncommitted changes which would prevent us from sending a Shutdown
response.
