Opponent's clock frozen at 5.4 seconds in rated 5+0 game • page 1/1 • Lichess Feedback • lichess.org

RemainComm

During my rated 5+0 blitz game, my opponent's clock remained frozen at exactly 5.4 seconds over multiple consecutive moves.

Both players continued making moves, but my clock counted down normally while my opponent's displayed time never decreased.

There was no time increment. I eventually gave up and lost on time.

Please investigate the game's recorded clock history and determine whether this was a synchronization problem or a clock malfunction.

Game:

https://lichess.org/game/xwQyCIGN/black

Thank you.

During my rated 5+0 blitz game, my opponent's clock remained frozen at exactly 5.4 seconds over multiple consecutive moves. Both players continued making moves, but my clock counted down normally while my opponent's displayed time never decreased. There was no time increment. I eventually gave up and lost on time. Please investigate the game's recorded clock history and determine whether this was a synchronization problem or a clock malfunction. Game: https://lichess.org/game/xwQyCIGN/black Thank you.

Ender88

edited

Lichess has a mechanic of 0s premoves.

That means that an user can set up an automatic move as response to your move while you are moving.
This kind of moves are still sent from the client automatically so you would expect a bit of lag.

Unfortunately there is a lag compensation algorithm that will compensate lag based on how much it was measured lag for the specific user in previous moves.
That sound great, but AFAIK how algorithms measure lag can theoretically be influenced by a malicious user to inflate measured lag.

That translate in a situation where theoretically an user could legitimately make an unlimited number of moves without spending any time; moreover AFAIK a rogue user could also abuse that mechanism to squeeze extra time for every move (I mean that AFAIK an user could set a premove or do a regular move while trucking the lag compensation algorithm, cancelling small parts of thinking time because it will appear to algorithm as lag that will be compensated back).

IMHO those are bad design choices, but up today it seems how game's mechanics works here

Ps: I didn't check the algorithm recently I reported what I have conclude few time ago based on a GitHub issue but AFAIK the underlying issue (prevent faking lag) is not solvable without a trusted infrastructure that AFAIK at the moment doesn't exist because it will be costly.

Lichess has a mechanic of 0s premoves. That means that an user can set up an automatic move as response to your move while you are moving. This kind of moves are still sent from the client automatically so you would expect a bit of lag. Unfortunately there is a lag compensation algorithm that will compensate lag based on how much it was measured lag for the specific user in previous moves. That sound great, but AFAIK how algorithms measure lag can theoretically be influenced by a malicious user to inflate measured lag. That translate in a situation where theoretically an user could legitimately make an unlimited number of moves without spending any time; moreover AFAIK a rogue user could also abuse that mechanism to squeeze extra time for every move (I mean that AFAIK an user could set a premove or do a regular move while trucking the lag compensation algorithm, cancelling small parts of thinking time because it will appear to algorithm as lag that will be compensated back). IMHO those are bad design choices, but up today it seems how game's mechanics works here Ps: I didn't check the algorithm recently I reported what I have conclude few time ago based on a GitHub issue but AFAIK the underlying issue (prevent faking lag) is not solvable without a trusted infrastructure that AFAIK at the moment doesn't exist because it will be costly.