akovalenko/lnd.xprv
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

contractcourt/contract_resolvers: correct off-by-one HTLC expiry

Browse Source 
This commit attempts to fix an inconsistency in when we consider an HTLC
to expire. When we first launched the resolver we would compare the
current block height against the expiry, while for new incoming blocks
we would compare against expiry-1.

This lead to a flake during integration tests, during a call to
RestartNode after _exactly_ enough blocks for the HTLC to expire. In
some cases the resolver would see the new blocks and consider the HTLC
to be expired (because of the -1), while in some cases resolver would
shut down before seeing the new blocks, and upon restart wouldn't act on
the new height because we did not compare against -1.

This commit fixes this by doing the same comparison in both cases.
This commit is contained in:
Johan T. Halseth 2018-08-14 09:09:02 +02:00
parent 6e33115da9
commit 5476f6d310
No known key found for this signature in database
GPG Key ID: 15BAADA29DA20D26
1 changed files with 5 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
contractcourt/contract_resolvers.go
View File

@ -845,7 +845,11 @@ func (h *htlcOutgoingContestResolver) Resolve() (ContractResolver, error) {
if err != nil {
return nil, err
}
if uint32(currentHeight) >= h.htlcResolution.Expiry {
// If the current height is >= expiry-1, then a spend will be valid to
// be included in the next block, and we can immediately return the
// resolver.
if uint32(currentHeight) >= h.htlcResolution.Expiry-1 {
log.Infof("%T(%v): HTLC has expired (height=%v, expiry=%v), "+
"transforming into timeout resolver", h,
h.htlcResolution.ClaimOutpoint)