Add more comments about timelock assumptions and security model
authorAntoine Riard <ariard@student.42.fr>
Thu, 18 Jul 2019 22:50:03 +0000 (18:50 -0400)
committerAntoine Riard <ariard@student.42.fr>
Fri, 19 Jul 2019 21:19:46 +0000 (17:19 -0400)
commit963f002056d86365447dc1ce244251a449df5b6d
treedc61be6c42fc6a0ab640634bd0c9d5a7855e83ca
parent041b04c31870f5ae054665ea23d0425195b55e6d
Add more comments about timelock assumptions and security model

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.
src/ln/channelmanager.rs
src/ln/channelmonitor.rs
src/ln/functional_tests.rs