New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of secret reveals allows for incorrect acceptance of RemoveLockExpired #2835

konradkonrad opened this Issue Oct 18, 2018 · 1 comment


None yet
3 participants

konradkonrad commented Oct 18, 2018

Problem Definition

In a mediated transfer, the mediator can learn about a secret of the HTL in two ways:

  • off-chain through a RevealSecret message
  • on-chain through a SecretRevealed event

These reveals have different semantics in interaction with the HTL's expiration.

An on-chain reveal freezes the expiration at the time of the on-chain reveal.

An off-chain reveal should be followed by an updated balance proof with the HTL amount unlocked (Secret message). If the updated balance proof is not received, and the HTL is about to expire, the known secret will be revealed on-chain.

On the other hand, a failed transfer, which secret is never revealed, will lead to locked tokens that will drain the channel. In order to revive the channel's capacity, the payers in such a transfer will send RemoveExpiredLock messages with an updated balance proof to the payees, with a reduced locked amount of tokens.

Currently, a mediator could potentially be attacked by making it accept a RemoveExpiredLock update to the partners balance proof (i.e. agreeing on a timed-out/failed transfer), although the secret was revealed on-chain. This is due to incorrect state handling after an off-chain reveal. The code paths for an on-chain reveal do no-op in case of an already known secret in the state, so the node will ignore later off-chain reveals.

Affected code sections

Potential exploit

The attack could be an eclipse attack, where the attacker controls Initiator and Target node and depletes the mediating Victim's forward deposit to the Target. After the Target node reveals the secret to the Victim, the Victim will send an unlocked balance proof to the Target. Following the protocol, the Victim will reveal the secret to the Initiator. The attacker will never respond to the reveal. Now the Victim needs to stop the expiration by revealing on-chain. After the original timeout, the attacking Initiator will send a RemoveExpiredLock message to the Victim, which will accept it, because of the incorrect handling. Now the Victim would be in a state where it believes the "empty" balance proof of the Initiator, and the Target will have received all of the Victims token.

Applicability / PoC



This comment has been minimized.


LefterisJP commented Oct 19, 2018

Fixed by #2843 and when #2846 is merged

@LefterisJP LefterisJP closed this Oct 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment