You may use it to get a broadcastable local toxic tx in case of fallen-behind,
i.e when receiving a channel_reestablish with a proof that our remote side
knows a higher revocation secret than the local commitment number we are aware
of. Broadcasting these transactions are UNSAFE, as they allow remote side to punish
you. Nevertheless you may want to broadcast them if remote don't close channel with his
higher commitment transaction after a substantial amount of time (a month or even a year)
to get back funds. Best may be to contact out-of-band the other node operator to coordinate
with him if option is available to you. In any-case, choice is up to the user.
Also, log toxic commitment tx id in channel_reestablish sending back
ChannelError::CloseDelayBroadcast
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
We were previously using their_to_self_delay to regenerate scripts for
spending remote revoked htlc transactions, and that's a bug.
Their_to_self_delay is delay enforced by peer upon outputs returning
funds back to us.
Our_to_self_delay is delay enforced by us upon outputs returning funds
back to peer.
We must adapt our delay between two bumps of claim txn in respect
to the timelock encumbering the targeted outpoint. If HTLC or
revoked output is near to expire, we should try to get our claim
in every block. If it's reasonably in the future, we may give us
more latency to bump
Rename HTLC_FAIL_ANTI_REORG_DELAY to ANTI_REORG_DELAY because
we are going to rely on it also to remove bump candidates outpoint
from tracker after claim get enough depth.
Rename HTLC_FAIL_TIMEOUT_BLOCKS to LATENCY_GRACE_PERIOD_BLOCKS because
it's carrying more meaningfully that we are doing a favor to our
peer instead of ruthlessly enforcing the contract.
CLTV_EXPIRY_DELTA should be > to LATENCY_GRACE_PERIOD_BLOCKS +
+CLTV_CLAIM_BUFFER + ANTI_REORG_DELAY + LATENCY_GRACE_PERIOD_BLOCKS
When we reached height + LATENCY_GRACE_PERIOD_BLOCKS and we have pending
unsolved outbound HTLC, we fail onchain with
our local commitment tx. At this point we expect to get in chain in a
worst-case delay of CLTV_CLAIM_BUFFER. When our HTLC-timeout is
confirmed with ANTI_REORG_DELAY we may safely fail backward the
corresponding inbound output.
Add test_failure_delay_htlc_local_commitment and
test_no_failure_dust_htlc_local_commitment
Move some bits of check_spend_remote as we need to fail dust HTLCs
which can be spread on both prev/lastest local commitment tx
Broadcasting a commitment tx means that we have to fail
inbound HTLC in backward channel. Doing it prematurely would
put us at risk in case of reorg. So we delay passing failure
update upstream until solving tx mature to HTLC_FAIL_ANTI_
REORG_DELAY.
Requirements differ if HTLC is a revoked/non-revoked dust/
non-revoked non-dust one.
Add connect_blocks in test_utils to fix broken tests due to
anti-reorg delay enforcement
Remove anti-duplicate htlc update stuff in ManySimpleChannelMonitor
This resulted in a full_stack_target failure as we overflow during
subtraction otherwise.
Instead, we try lower and lower fee estimator confirmation targets
until we find one low enough, or discard the transaction. We should
be able to handle this much cleaner, but for now this at least gets
the fuzzer working again.
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.
