spec: update evidence in blockchain.md (#108)

now evidence reflects the actual evidence present in the tendermint repo

spec/abci/README.md

@@ -10,7 +10,7 @@ _methods_, where each method has a corresponding `Request` and `Response`
 message type. Tendermint calls the ABCI methods on the ABCI application by sending the `Request*`
 messages and receiving the `Response*` messages in return.
 
-All message types are defined in a [protobuf file](https://github.com/tendermint/tendermint/blob/master/abci/types/types.proto).
+All message types are defined in a [protobuf file](https://github.com/tendermint/tendermint/blob/master/proto/abci/types.proto).
 This allows Tendermint to run applications written in any programming language.
 
 This specification is split as follows:

spec/abci/abci.md

@@ -3,7 +3,7 @@
 ## Overview
 
 The ABCI message types are defined in a [protobuf
-file](https://github.com/tendermint/tendermint/blob/master/abci/types/types.proto).
+file](https://github.com/tendermint/tendermint/blob/master/proto/abci/types.proto).
 
 ABCI methods are split across four separate ABCI _connections_:
 

spec/abci/client-server.md

@@ -9,7 +9,7 @@ Applications](./apps.md).
 ## Message Protocol
 
 The message protocol consists of pairs of requests and responses defined in the
-[protobuf file](https://github.com/tendermint/tendermint/blob/master/abci/types/types.proto).
+[protobuf file](https://github.com/tendermint/tendermint/blob/master/proto/abci/types.proto).
 
 Some messages have no fields, while others may include byte-arrays, strings, integers,
 or custom protobuf types.
@@ -49,7 +49,7 @@ If GRPC is available in your language, this is the easiest approach,
 though it will have significant performance overhead.
 
 To get started with GRPC, copy in the [protobuf
-file](https://github.com/tendermint/tendermint/blob/master/abci/types/types.proto)
+file](https://github.com/tendermint/tendermint/blob/master/proto/abci/types.proto)
 and compile it using the GRPC plugin for your language. For instance,
 for golang, the command is `protoc --go_out=plugins=grpc:. types.proto`.
 See the [grpc documentation for more details](http://www.grpc.io/docs/).

spec/blockchain/blockchain.md

@@ -203,22 +203,72 @@ type EvidenceData struct {
 
 ## Evidence
 
-Evidence in Tendermint is implemented as an interface.
-This means any evidence is encoded using its Amino prefix.
-There is currently only a single type, the `DuplicateVoteEvidence`.
+Evidence in Tendermint is used to indicate breaches in the consensus by a validator. 
+It is implemented as the following interface.
 
-```
-// amino name: "tendermint/DuplicateVoteEvidence"
-type DuplicateVoteEvidence struct {
-	PubKey PubKey
-	VoteA  Vote
-	VoteB  Vote
+```go
+type Evidence interface {
+	Height() int64                                     // height of the equivocation
+	Time() time.Time                                   // time of the equivocation
+	Address() []byte                                   // address of the equivocating validator
+	Bytes() []byte                                     // bytes which comprise the evidence
+	Hash() []byte                                      // hash of the evidence
+	Verify(chainID string, pubKey crypto.PubKey) error // verify the evidence
+	Equal(Evidence) bool                               // check equality of evidence
+
+	ValidateBasic() error
+	String() string
 }
 ```
 
-Votes are lexicographically sorted on `BlockID`.
+All evidence can be encoded and decoded to and from Protobuf with the `EvidenceToProto()` 
+and `EvidenceFromProto()` functions. The [Fork Accountability](../consensus/light-client/accountability.md) 
+document provides a good overview for the types of evidence and how they occur.
 
-See the [pubkey spec](./encoding.md#key-types) for more.
+`DuplicateVoteEvidence` represents a validator that has voted for two different blocks 
+in the same round of the same height. Votes are lexicographically sorted on `BlockID`.
+
+```go
+type DuplicateVoteEvidence struct {
+	VoteA  *Vote
+	VoteB  *Vote
+}
+```
+
+`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).
+
+```go
+type AmnesiaEvidence struct {
+	*PotentialAmnesiaEvidence
+	Polc *ProofOfLockChange
+}
+```
+
+`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
+}
+```
+
+`PhantomValidatorEvidence` represents a validator that has signed for a block where it was not part of the validator set. 
+This attack also only applies to Light clients. Phantom validators must still be staked. `LastHeightValidatorWasInSet` 
+indicated the height that they last voted.
+
+
+```go
+type PhantomValidatorEvidence struct {
+	Vote                        *Vote 
+	LastHeightValidatorWasInSet int64
+}
+```
 
 ## Validation