If we remote peer provide us a revocation secret which doesn't
match with next_remote_revocation_number we close the channel
If we learn that we are fallen-behind, we send back a CloseDelayBroadcast
error, special take care will be take to log error and channel should
stale, i.e we expect our honest peer to unilateral close to claim
on it our balance
Add ChannelError::CloseDelayBroadcast to signal that you need to close
the channel but not to broadcast it while however update ChannelMonitor
with remote per_commitment_point thanks to our peer being a gentleman
In case of sending channel_reestablish message, we join
our current per_commitment_point and their highest revocation
secret we know about
We set data_loss_protect by default and adjust encoding_init
test in consequence
This carries a surprising amount of complexity despite only being
possible in the case where monitor updating failed during the
processing of funding_generated. Specifically, this requires
handling rebroadcasting funding_locked once we successfully persist
our monitor again.
As an alternative we could never send funding_signed when the
monitor failed to persist, but this approach avoids needless
delays during funding.
It suggested figuring something else out after #81, but the API we
settled on after #81 (which I think is just fine) doesn't allow for
anything cleaner, so this is fine as-is.
Let these values being used as default ones in UserConfig.
Also, reduce them to something more reasonable, for BREAKDOWN_TIMEOUT
from 1 week to 1 day, for MAX_LOCAL_BREAKDOWN_TIMEOUT from 2 weeks
to 1.
We use user config to decide to commit to closing script
in open_channel/accept_channel messages. We don't check
that other peer supporting the option as including
script without other peer public support is borne by
the protocol. If user opt-out, following protocol and
due to the fact we always signal, we provide a zero-length
script
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.
