Require to specify expected amount so that we can claim only
payment for thhe correct amount, and reject payments for incorrect
amounts (which are probably middle nodes probing to break our privacy).
Send back incorrect_or_unknown_payments_details (PERM|15) to avoid
the probe node learning that final node is waiting a payment with
the routed hash.
We also fulfilled last empty ErrorAction:
- Router secp fail : IgnoreError
- processing error in Router : IgnoreError
- get_channel_update too early : IgnoreError
In case of duplicate HTLCs with same hash going in opposite
directions we may learn preimage of offered one, but we shouldn't
claim received one to avoid invalidation of combined claim.
The received HTLC is going to be claimed by a timeout tx at
timelock expiration.
Fix#337
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
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.
