Specifically, there really should be no Errs, but in case there is
some case where duplicate HTLC removes are possible, return
IgnoreError and debug_assert to see if fuzzing can find them.
This is completely unsafe as we have provided the remote side with
a commitment_signed which they can broadcast, including the HTLC
transaction, and then could claim it on-chain after we've failed it
backwards!
This is required by BOLT 2 to ensure that no attacker can simply
relay every public node a duplicate-payment_hash HTLC for each HTLC
it receives to deduce where an HTLC came from.
Note that this makes the claim logic much less incentive-compatible
as we will not claim all available HTLCs with the same payment_hash
even if we know the preimage! This is OK because, most likely, any
attackers trying to map the network will use small-value payments
and, hopefully, we will move away from constant hashes across an
entire payment at some point in the near future.
This further simplifies the payment transition state a bit, so
hopefully at least we got some readability out of all of this
Both get_update_fail_htlc and get_update_fulfill_htlc should never
be called before any HTLC could have been accepted (ie
pre-ChannelFunded) nor should they ever be called
post-ShutdownComplete as the Channel object should be destroyed at
that point. Previously get_update_fulfill_htlc would panic, but
get_update_fail_htlc would return an Err. For now make them both
panic but we can revisit this if we want to have fewer panics in
the future.
This was redundant and was included because the HTLC still needed
to be monitored, but that happens in ChannelMonitor, so there is no
need for it in Channel itself.
Because we don't have an HTLCState for
update_add_htlc-generated-but-not-yet-commitment_signed to simplify
the mess of HTLCState match arms, any time a Channel::send_htlc
call returns Ok(Some(_)) we MUST call commitment_signed and it MUST
return success (or close the channel). We mention this in the docs
and panic if its not met in ChannelManager (which lets the fuzz
tester check this).
This fixes a violation of BOLT 2 and will let us consolidate some
HTLC update handling. Good bit of code movement, but is mostly
refactor to store HTLC failure status in pending_htlcs in Channel.
Add `derive_minimum_depth()` and `derive_maximum_minimum_depth()` and hide
CONF_TARGET constant behind these functions.
Replace `DisconnectPeer` error with `HandleError` with `ErrorAction::SendErrorMessage`
