This is somewhat awkward, but prevents a slew of duplicate events.
Really this should probably be more explicit, but would be easy to
move that along with a slew of block_connected-event-processing
refactors, see-also GH #80.
This affects full_stack_target only on accident cause the demo test
didn't continue onwards with another block connection.
Called in ChannelMonitor block_connected, returning
HTLCUpdate upstream via ManyChannelMonitor to
link htlcs between monitors. Used by ChannelManager to
fulfill/fail htlcs backwards accordingly
If spurrious HTLCUpdate are generated due to block re-scan
and htlc are already LocalRemoved, discard them in
channel get_update_*_htlc
Insert it in current_local_signed_tx, prev_local_signed_tx,
remote_claimable_outpoints. For so get it provided by
Channel calls to provide_latest_{local,remote}_tx
Aims to detect onchain resolution of channel
Modify in consequence test_txn_broadcast to still pass
channel_monitor_network_test
Modify some tests due to block re-scan caused by
detections extensions
This adds a few TODOs around further message rebroadcasting which
needs to be implemented as well as some loss of tracking of HTLCs
on permanent channel failure which needs to get transferred over to
the appropriate in-memory ChannelMonitor.
This resolves an API bug where send_payment may return a
MonitorUpdateFailed Err both when the payment will not be sent and
when the HTLC will be retried automatically when monitor updating
is restored. This makes it impossible for a client to know when
they should retry a payment and when they should not.
Fixes a panic found by fuzzer in case the monitor per-commitment
data is garbage. We had a similar check for revoked commitment tx
but didn't copy it down to non-revoked commitment tx, so do that
now.
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.
