Move PrivMode as Local, SigsMode as Watchtower
Cut funnding_txo from ChannelMonitor, move it inside Local
Rename log_funding_option as log_funding_info
This is the case pointed out by nayuta-gondo at
https://github.com/lightningnetwork/lightning-rfc/issues/499#issuecomment-438623208
though this doesn't actually solve the issue of ensuring we have a
consistent fee view when we start shutdown processing. There isn't
a clear solution to that however without adding additional state
tracking in Channel.
This also removes an associated test that tests for the correct
behavior (but didn't consider the bug) as we no longer behave
correctly. This should be fine as we'll be removing all the
update_fee garbage with option_simplified_commitment anyway.
This removes all the channel-closure stuff from handle_error!() and
MsgHandleErrInternal, making all the Err handling consistent by
closing the channel before releasing the channel_state lock and
then calling handle_error!() outside of the lock.
Technically funding_transaction_generated was fine using it, but
calling force_shutdown on an empty Channel inside the channel_state
lock isn't a big deal and almost any other use of it would be
unsafe.
If we never accessed channels for a peer outside of a message
handler for that peer then this wouldn't be a problem since message
handlers are required to be serialized per-peer. However, that
isn't the world we live in - we may want to forward payments or we
may get a send_payment call.
This converts block_connected failures to returning the
ErrorMessage that needs to be sent directly, since it always
results in channel closure and never results in needing to call
force_shutdown. It also converts update_add_htlc and closing_signed
handlers to ChannelError as the rest of the message handlers.
Currently channel_reserve_test sends a garbage update_add_htlc
message and then relies on it being silently ignored to continue
using the channel. This shouldn't be the case, so take the easy
way out and split the test in two, at first not delivering the
bogus update_add_htlc and then delivering it, but not running the
rest of the test.
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.
