Peer may send us a shutdown_scriptpubkey in open_channel or
accept_channel messages. Before to enforce this policy on channel
closing, we want to be sure that our peer has opt-in to it.
Extend LocalFeatures new method visibilty from crate to public
for fuzz tests
Resending revoke_and_ack and commitment_signed (+update) messages
after monitor-update-failure or disconnection has been a highly
unreliable part of our codebase for some time (as evidenced by the
number of bugs caught in the chanmon_fail_consistency fuzz target).
This is due to its rather ad-hoc nature and tracking/behavior which
consists of checking a number of different flags to try to deduce
which messages were/were not delivered and go from there. Instead,
this commit rewrites it to simply keep track of the order messages
were generated originally, as we always resend in the
originally-generated order.
I'm anticipating this will be way more robust than the old code, in
addition to its simplicity.
This should probably have happened when we moved most state into
the state enums themselves, but specifically forcing awareness of
the removed/not removed state would have prevented me from
introducing a bug in the first version of an upcoming reserve-value
patch.
Previously, if we went to free the holding cell HTLC updates, and
adding one failed as we hit our outbound HTLC limit (or in-flight
value limit), we would not send a commitment_signed, leaving us in
an invalid state. We first fix that bug, and then refuse to add
things to our holding cell once we reach our limits considering the
holding cell, as we shouldn't have multiple commitment dance rounds
worth of HTLCs in the holding cell anyway.
This fixes a rather subtle case handling RAAs when we don't
generate a response due to a previous monitor update failure, but
would otherwise send a CS response. We need to still set
AwaitingRemoteRevoke on the channl in question, but previously did
not. Found by chanmon_fail_consistency fuzz test with the failing
test converted and added manually.
Primarily this fixes the case where we receive an RAA which does
not require a response, allowing us to call monitor_update_failed
without generating pending messages.
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.
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
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 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.
