This resolves a TODO/issue in would_broadcast_at_height where we
will not fail a channel with HTLCs which time out in remote
broadcastable transactions.
We really shouldn't have split out the with-source HTLCs from the
in-transaction HTLCs when we added back-failing, and will need
almost all of the info in HTLCOutputInCommitment for each HTLC to
fix would_broadcast_at_height, so this is a first step at
recombining them.
When our counterparty claims multiple HTLCs from offered outputs in
one transaction we should still be able to learn the preimages.
Sadly, due to two bugs we were not previously doing so.
This fixes HTLC fail-backwards in case we haven't yet sent enough
to have a to_remote output to claim, plus some edge cases where it
could be removed due to a fee update, though hopefully that goes
away with simplified_commitment.
Note that this requires rewriting full_stack_target tests, which
sucks, but it does let the fuzzer hit more stuff since the real
ripemd160 isn't ever actually called anymore.
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
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 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.
