<p><a href="https://eprint.iacr.org/2016/1159.pdf" rel="nofollow noreferrer">The paper</a> explains this:</p>

<blockquote>
  <p>The  “weakness”  of  the  Liveness  property  corresponds  to  the 
  fact  that  we  do  not  guarantee (though  it  is  still  hard  for 
  an  attacker  to  prevent)  a  resolution  in  case  conflicting 
  transactions were published soon one after the other. Contrast this to
  traditional consensus protocols, where all conflicts are required to be
  decided in finite time, a property usually referred to as
  Liveness. Observe, however, that an honest user of the system will
  never publish conflicting transactions,and will transfer money only
  after he robustly accepted the original funds (the inputs)
  himself; payments of honest users are thus guaranteed to meet the
  conditions formalized in Weak Liveness, and  to  be  robustly 
  accepted.  On  the  other  hand,  an  attacker  trying  to  defraud 
  must  keep  his attack secret before publishing the conflict, until the
  victim robustly accepts; but then the victim is  guaranteed  that 
  w.h.p.  his  transaction  will  not  be  reversed.  Therefore,  these 
  two  properties together  ensure  that  payments  of  honest  users 
  will  be  robustly  accepted  in  constant  expected time, and that
  they remain robustly accepted forever, w.h.p.</p>
</blockquote>

CC BY-SA 4.0
2019-10-06T04:35:17.393Z
2019-10-06T04:35:17.393Z
Janus Troelsen
<p>In his article <a href="https://medium.com/@avivzohar/the-spectre-protocol-7dbbebb707b5" rel="nofollow noreferrer">The Spectre Protocol</a>, Aviv Zohar, one of Spectre's authors, mentions that <strong>Spectre</strong> has <strong>weak liveness</strong>.
Why does he mention that Spectre has <strong>"weak"</strong> liveness, and how would <strong>"strong liveness"</strong> differ from that?</p>

CC BY-SA 4.0
2018-11-25T19:10:32.683Z
@KappaDev I think research about better consensus algorithms is very relevant, even if not applicable in the short term. And even if not, this is just a question about the definition of terminology in consensus systems in general.
Pieter Wuille
<protocol><consensus><terminology>
In what way does Spectre have "weak" liveness?
Questioner
# In what way does Spectre have "weak" liveness?

(Asked by: username_0 on 2018-11-25)

In his article [The Spectre Protocol](https://medium.com/@avivzohar/the-spectre-protocol-7dbbebb707b5), Aviv Zohar, one of Spectre's authors, mentions that **Spectre** has **weak liveness**.
Why does he mention that Spectre has **"weak"** liveness, and how would **"strong liveness"** differ from that?

**Tags:** protocol, consensus, terminology

> **Comments:**
> **username_1**: @KappaDev I think research about better consensus algorithms is very relevant, even if not applicable in the short term. And even if not, this is just a question about the definition of terminology in consensus systems in general.  

---

## 1 answers

### Answer by username_2 on 2019-10-06. Score: 1

[The paper](https://eprint.iacr.org/2016/1159.pdf) explains this:

> The “weakness” of the Liveness property corresponds to the
> fact that we do not guarantee (though it is still hard for
> an attacker to prevent) a resolution in case conflicting
> transactions were published soon one after the other. Contrast this to
> traditional consensus protocols, where all conflicts are required to be
> decided in finite time, a property usually referred to as
> Liveness. Observe, however, that an honest user of the system will
> never publish conflicting transactions,and will transfer money only
> after he robustly accepted the original funds (the inputs)
> himself; payments of honest users are thus guaranteed to meet the
> conditions formalized in Weak Liveness, and to be robustly
> accepted. On the other hand, an attacker trying to defraud
> must keep his attack secret before publishing the conflict, until the
> victim robustly accepts; but then the victim is guaranteed that
> w.h.p. his transaction will not be reversed. Therefore, these
> two properties together ensure that payments of honest users
> will be robustly accepted in constant expected time, and that
> they remain robustly accepted forever, w.h.p.


---

