BFT requires _less than_ 1/3 faulty validators (#228)

Thanks fo spotting the imprecision in the text, @shahankhatch !

spec/light-client/accountability.md

@@ -9,12 +9,12 @@ Tendermint consensus guarantees the following specifications for all heights:
 * termination -- all correct full nodes eventually decide,
 
 if the
-faulty validators have at most 1/3 of voting power in the current validator set. In the case where this assumption
+faulty validators have less than 1/3 of voting power in the current validator set. In the case where this assumption
 does not hold, each of the specification may be violated.
 
 The agreement property says that for a given height, any two correct validators that decide on a block for that height decide on the same block. That the block was indeed generated by the blockchain, can be verified starting from a trusted (genesis) block, and checking that all subsequent blocks are properly signed.
 
-However, faulty nodes may forge blocks and try to convince users (light clients) that the blocks had been correctly generated. In addition, Tendermint agreement might be violated in the case where more than 1/3 of the voting power belongs to faulty validators: Two correct validators decide on different blocks. The latter case motivates the term "fork": as Tendermint consensus also agrees on the next validator set, correct validators may have decided on disjoint next validator sets, and the chain branches into two or more partitions (possibly having faulty validators in common) and each branch continues to generate blocks independently of the other.
+However, faulty nodes may forge blocks and try to convince users (light clients) that the blocks had been correctly generated. In addition, Tendermint agreement might be violated in the case where 1/3 or more of the voting power belongs to faulty validators: Two correct validators decide on different blocks. The latter case motivates the term "fork": as Tendermint consensus also agrees on the next validator set, correct validators may have decided on disjoint next validator sets, and the chain branches into two or more partitions (possibly having faulty validators in common) and each branch continues to generate blocks independently of the other.
 
 We say that a fork is a case in which there are two commits for different blocks at the same height of the blockchain. The proplem is to ensure that in those cases we are able to detect faulty validators (and not mistakenly accuse correct validators), and incentivize therefore validators to behave according to the protocol specification.
 
@@ -22,7 +22,7 @@ We say that a fork is a case in which there are two commits for different blocks
 
 **Q:** Should we distinguish agreement for validators and full nodes for agreement? The case where all correct validators agree on a block, but a correct full node decides on a different block seems to be slightly less severe that the case where two correct validators decide on different blocks. Still, if a contaminated full node becomes validator that may be problematic later on. Also it is not clear how gossiping is impaired if a contaminated full node is on a different branch.
 
-*Remark.* In the case more than 1/3 of the voting power belongs to faulty validators, also validity and termination can be broken. Termination can be broken if faulty processes just do not send the messages that are needed to make progress. Due to asynchrony, this is not punishable, because faulty validators can always claim they never received the messages that would have forced them to send messages.
+*Remark.* In the case 1/3 or more of the voting power belongs to faulty validators, also validity and termination can be broken. Termination can be broken if faulty processes just do not send the messages that are needed to make progress. Due to asynchrony, this is not punishable, because faulty validators can always claim they never received the messages that would have forced them to send messages.
 
 ## The Misbehavior of Faulty Validators
 
@@ -40,7 +40,7 @@ Forks are the result of faulty validators deviating from the protocol. In princi
 
 2. spurious messages: In Tendermint consensus most of the message send instructions are guarded by threshold guards, e.g., one needs to receive *2f + 1* prevote messages to send precommit. Faulty validators may send precommit without having received the prevote messages.
 
-Independently of a fork happening, punishing this behavior might be important to prevent forks altogether. This should keep attackers from misbehaving: if at most 1/3 of the voting power is faulty, this misbehavior is detectable but will not lead to a safety violation. Thus, unless they have more than 1/3 (or in some cases more than 2/3) of the voting power attackers have the incentive to not misbehave. If attackers control too much voting power, we have to deal with forks, as discussed in this document.
+Independently of a fork happening, punishing this behavior might be important to prevent forks altogether. This should keep attackers from misbehaving: if less than 1/3 of the voting power is faulty, this misbehavior is detectable but will not lead to a safety violation. Thus, unless they have 1/3 or more (or in some cases more than 2/3) of the voting power attackers have the incentive to not misbehave. If attackers control too much voting power, we have to deal with forks, as discussed in this document.
 
 ## Two types of forks
 
@@ -119,7 +119,7 @@ contaminated by an attack if the blockchain itself violates its invariant (one b
 ### Equivocation based attacks
 
 In case of equivocation based attacks, faulty validators sign multiple votes (prevote and/or precommit) in the same
-round of some height. This attack can be executed on both full nodes and light clients. It requires more than 1/3 of voting power to be executed.
+round of some height. This attack can be executed on both full nodes and light clients. It requires 1/3 or more of voting power to be executed.
 
 #### Scenario 1: Equivocation on the main chain
 
@@ -128,7 +128,7 @@ Validators:
 * CA - a set of correct validators with less than 1/3 of the voting power
 * CB - a set of correct validators with less than 1/3 of the voting power
 * CA and CB are disjoint
-* F - a set of faulty validators with more than 1/3 voting power
+* F - a set of faulty validators with 1/3 or more voting power
 
 Observe that this setting violates the Tendermint failure model.
 
@@ -177,7 +177,7 @@ In order to detect such (equivocation-based attack), the light client would need
 
 *Remark.* The light client would be able to create evidence of misbehavior, but this would require to pull potentially a lot of data from correct full nodes. Maybe we need to figure out different architecture where a light client that is attacked will push all its data for the current unbonding period to a correct node that will inspect this data and submit corresponding evidence. There are also architectures that assumes a special role (sometimes called fisherman) whose goal is to collect as much as possible useful data from the network, to do analysis and create evidence transactions. That functionality is outside the scope of this document.
 
-*Remark.* The difference between LCS and LCB might only be in the amount of voting power needed to convince light client about arbitrary state. In case of LCB where security threshold is at minimum, an attacker can arbitrarily modify application state with  more than 1/3 of voting power, while in case of LCS it requires more than 2/3 of the voting power.
+*Remark.* The difference between LCS and LCB might only be in the amount of voting power needed to convince light client about arbitrary state. In case of LCB where security threshold is at minimum, an attacker can arbitrarily modify application state with 1/3 or more of voting power, while in case of LCS it requires more than 2/3 of the voting power.
 
 ### Flip-flopping: Amnesia based attacks
 
@@ -187,7 +187,7 @@ In case of amnesia, faulty validators lock some value *v* in some round *r*, and
 
 Validators:
 
-* a set F of faulty validators with more than 1/3 but at most 2/3 of the voting power
+* a set F of faulty validators with 1/3 or more but at most 2/3 of the voting power
 * a set C of correct validators
 
 Execution:
@@ -203,7 +203,7 @@ Execution:
 
 Detecting faulty validators in the case of such an attack can be done by the fork accountability mechanism described in: <https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit?usp=sharing>.
 
-If a light client is attacked using this attack with more than 1/3 of voting power (and less than 2/3), the attacker cannot change the application state arbitrarily. Rather, the attacker is limited to a state a correct validator finds acceptable: In the execution above, correct validators still find the value acceptable, however, the block the light client trusts deviates from the one on the main chain.
+If a light client is attacked using this attack with 1/3 or more of voting power (and less than 2/3), the attacker cannot change the application state arbitrarily. Rather, the attacker is limited to a state a correct validator finds acceptable: In the execution above, correct validators still find the value acceptable, however, the block the light client trusts deviates from the one on the main chain.
 
 #### Scenario 4: More than 2/3 of faults
 
@@ -211,8 +211,8 @@ In case there is an attack with more than 2/3 of the voting power, an attacker c
 
 Validators:
 
-* a set F1 of faulty validators with more than 1/3 of the voting power
-* a set F2 of faulty validators with at most 1/3 of the voting power
+* a set F1 of faulty validators with 1/3 or more of the voting power
+* a set F2 of faulty validators with less than 1/3 of the voting power
 
 Execution
 
@@ -238,10 +238,10 @@ In this kind of attack, faulty validators take advantage of the fact that they d
 
 Validators:
 
-* C1 -  a set of correct validators with 1/3 of the voting power
+* C1 -  a set of correct validators with over 1/3 of the voting power
 * C2 - a set of correct validators with 1/3 of the voting power
 * C1 and C2 are disjoint
-* F - a set of faulty validators with 1/3 voting power
+* F - a set of faulty validators with less than 1/3 voting power
 * one additional faulty process *q*
 * F and *q* violate the Tendermint failure model.