I don&#x27;t understand many of the leaps you make in your argument. From what I can see, you&#x27;re defending that Redlock is &quot;good enough&quot; in cases where you don&#x27;t care about your computers hating you. This is not a good environment for distributed systems when you need strong correctness properties.<p>Reading through the original description of Redlock[1] and your &quot;rebuttal&quot; is interesting. The algorithm described in the spec isn&#x27;t safe if a GC pause or process pause happens between &lt;checking how long it took to acquire a majority&gt; and &lt;doing work and releasing the lock&gt;. You don&#x27;t even touch this argument (pretending to not understand which step is the problem and defending that everything before the gap I just described is safe).<p>You claim that fenced tokens require linearizablity. I don&#x27;t know if this is true, but even if it is all you&#x27;ve proven is that the solution offered isn&#x27;t good enough. The fact that something that tries to fix your system doesn&#x27;t fix it properly doesn&#x27;t mean that your system isn&#x27;t broken.