spec: remove evidences (#153)

spec/abci/abci.md

@@ -96,6 +96,27 @@ Example:
 }
 ```
 
+## EvidenceType
+
+A part of Tendermint's security model is the use of evidence which serves as proof of
+malicious behaviour by a network participant. It is the responsibility of Tendermint
+to detect such malicious behaviour, to gossip this and commit it to the chain and once
+verified by all validators to pass it on to the application through the ABCI. It is the
+responsibility of the application then to handle the evidence and exercise punishment.
+
+EvidenceType has the following protobuf format:
+
+```proto
+enum EvidenceType {
+  UNKNOWN               = 0;
+  DUPLICATE_VOTE        = 1;
+  LIGHT_CLIENT_ATTACK   = 2;
+}
+```
+
+There are two forms of evidence: Duplicate Vote and Light Client Attack. More
+information can be found [here](https://github.com/tendermint/spec/blob/master/spec/light-client/accountability.md)
+
 ## Determinism
 
 ABCI applications must implement deterministic finite-state machines to be
@@ -570,8 +591,7 @@ via light client.
 ### Evidence
 
 - **Fields**:
-    - `Type (string)`: Type of the evidence. A hierarchical path like
-    "duplicate/vote".
+    - `Type (EvidenceType)`: Type of the evidence. An enum of possible evidence's.
     - `Validator (Validator`: The offending validator
     - `Height (int64)`: Height when the offense occured
     - `Time (google.protobuf.Timestamp)`: Time of the block that was committed at the height that the offense occured
@@ -618,8 +638,6 @@ via light client.
       unbonding period. `MaxAgeNumBlocks` is calculated by dividing the unboding
       period by the average block time (e.g. 2 weeks / 6s per block = 2d8h).
     - `MaxNum (uint32)`: The maximum number of evidence that can be committed to a single block
-    - `ProofTrialPeriod (int64)`: The duration in terms of blocks that an indicted node has to
-      provide proof of correctly executing a lock change in the event of amnesia evidence.
 
 ### ValidatorParams
 

spec/core/data_structures.md

@@ -250,61 +250,6 @@ Valid Duplicate Vote Evidence must adhere to the following rules:
 
 - Time must be equal to the block time
 
-### AmensiaEvidence
-
-`AmnesiaEvidence` represents a validator that has incorrectly voted for another block in a
-different round to the the block that the validator was previously locked on. This form
-of evidence is generated differently from the rest. See this
-[ADR](https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-056-proving-amnesia-attacks.md) for more information.
-
-```go
-type AmnesiaEvidence struct {
- *PotentialAmnesiaEvidence
- Polc *ProofOfLockChange
-}
-```
-
-Valid Amnesia Evidence must adhere to the following rules:
-
-- Validator Address and Height must be the same and the Round must be different.
-
-- The BlockID's must be different and the BlockID of the first vote must not be nil.
-
-- The vote signature must be valid (using the chainID).
-
-- The evidence either must have a complete and valid `ProofOfLockChange` or have stood in the nodes evidence pool for the `ProofTrialPeriod`.
-
-- The validator must have been in the validator set.
-
-- Time must be equal to the corresponding block time.
-
-### LunaticValidatorEvidence
-
-`LunaticValidatorEvidence` represents a validator that has signed for an arbitrary application state.
-This attack only applies to Light clients.
-
-```go
-type LunaticValidatorEvidence struct {
- Header             *Header
- Vote               *Vote  
- InvalidHeaderField string
-
- Timestamp time.Time
-}
-```
-
-Valid Lunatic Validator Evidence must adhere to the following rules:
-
-- Header must have an invalid field compared to the correctly derived header that the node has in either the `ValidatorHash`, `NextValidatorHash`, `ConsensusHash`, `AppHash`, or `LastResultsHash`.
-
-- The vote must be for the incorrect header (BlockID of the vote must match the hash of the header).
-
-- The vote must be correcly signed (using the chainID).
-
-- The validator must have been in a correct validator set within the bonding period.
-
-- Time must be equal to the corresponding block time of the header that the node has (not the incorrect header).
-
 ## Validation
 
 Here we describe the validation rules for every element in a block.

spec/light-client/README.md

@@ -1,4 +1,4 @@
-# Tendermint Light Client Protocol
+# Light Client Protocol
 
 NOTE: This specification is under heavy development and is not yet complete nor
 accurate.

spec/light-client/verification.md

@@ -21,7 +21,7 @@ Given a known bound `TRUSTED_PERIOD`, and a block `b` with header `h` generated
 in `validators(b.Header.NextValidatorsHash)` is correct until time `b.Header.Time + TRUSTED_PERIOD`.
 
 *Assumption*: "correct" is defined w.r.t. realtime (some Newtonian global notion of time, i.e., wall time),
-while `Header.Time` corresponds to the [BFT time](./../bft-time.md). In this note, we assume that clocks of correct processes
+while `Header.Time` corresponds to the [BFT time](../consensus/bft-time.md). In this note, we assume that clocks of correct processes
 are synchronized (for example using NTP), and therefore there is bounded clock drift (`CLOCK_DRIFT`) between local clocks and
 BFT time. More precisely, for every correct light client process and every `header.Time` (i.e. BFT Time, for a header correctly
 generated by the Tendermint consensus), the following inequality holds: `Header.Time < now + CLOCK_DRIFT`,