Revert "delete everything" (includes everything non-go-crypto)

This reverts commit 96a3502

docs/spec/consensus/abci.md

@@ -0,0 +1 @@
+[Moved](/docs/spec/software/abci.md)

docs/spec/consensus/bft-time.md

@@ -0,0 +1,56 @@
+# BFT time in Tendermint 
+
+Tendermint provides a deterministic, Byzantine fault-tolerant, source of time. 
+Time in Tendermint is defined with the Time field of the block header. 
+
+It satisfies the following properties:
+
+- Time Monotonicity: Time is monotonically increasing, i.e., given 
+a header H1 for height h1 and a header H2 for height `h2 = h1 + 1`, `H1.Time < H2.Time`. 
+- Time Validity: Given a set of Commit votes that forms the `block.LastCommit` field, a range of 
+valid values for the Time field of the block header is defined only by  
+Precommit messages (from the LastCommit field) sent by correct processes, i.e., 
+a faulty process cannot arbitrarily increase the Time value.  
+
+In the context of Tendermint, time is of type int64 and denotes UNIX time in milliseconds, i.e., 
+corresponds to the number of milliseconds since January 1, 1970. Before defining rules that need to be enforced by the 
+Tendermint consensus protocol, so the properties above holds, we introduce the following definition:
+
+- median of a set of `Vote` messages is equal to the median of `Vote.Time` fields of the corresponding `Vote` messages,
+where the value of `Vote.Time` is counted number of times proportional to the process voting power. As in Tendermint
+the voting power is not uniform (one process one vote), a vote message is actually an aggregator of the same votes whose 
+number is equal to the voting power of the process that has casted the corresponding votes message. 
+
+Let's consider the following example:
+ - we have four processes p1, p2, p3 and p4, with the following voting power distribution (p1, 23), (p2, 27), (p3, 10)
+and (p4, 10). The total voting power is 70 (`N = 3f+1`, where `N` is the total voting power, and `f` is the maximum voting 
+power of the faulty processes), so we assume that the faulty processes have at most 23 of voting power. 
+Furthermore, we have the following vote messages in some LastCommit field (we ignore all fields except Time field): 
+      - (p1, 100), (p2, 98), (p3, 1000), (p4, 500). We assume that p3 and p4 are faulty processes. Let's assume that the 
+      `block.LastCommit` message contains votes of processes p2, p3 and p4. Median is then chosen the following way: 
+      the value 98 is counted 27 times, the value 1000 is counted 10 times and the value 500 is counted also 10 times. 
+      So the median value will be the value 98. No matter what set of messages with at least `2f+1` voting power we 
+      choose, the median value will always be between the values sent by correct processes.   
+
+We ensure Time Monotonicity and Time Validity properties by the following rules: 
+  
+- let rs denotes `RoundState` (consensus internal state) of some process. Then 
+`rs.ProposalBlock.Header.Time == median(rs.LastCommit) &&
+rs.Proposal.Timestamp == rs.ProposalBlock.Header.Time`.
+
+- Furthermore, when creating the `vote` message, the following rules for determining `vote.Time` field should hold: 
+
+    - if `rs.Proposal` is defined then 
+    `vote.Time = max(rs.Proposal.Timestamp + 1, time.Now())`, where `time.Now()` 
+    denotes local Unix time in milliseconds.  
+    
+    - if `rs.Proposal` is not defined and `rs.Votes` contains +2/3 of the corresponding vote messages (votes for the 
+    current height and round, and with the corresponding type (`Prevote` or `Precommit`)), then 
+    
+    `vote.Time = max(median(getVotes(rs.Votes, vote.Height, vote.Round, vote.Type)), time.Now())`,
+    
+    where `getVotes` function returns the votes for particular `Height`, `Round` and `Type`.  
+    The second rule is relevant for the case when a process jumps to a higher round upon receiving +2/3 votes for a higher 
+    round, but the corresponding `Proposal` message for the higher round hasn't been received yet.    
+
+

docs/spec/consensus/consensus.md

@@ -0,0 +1,9 @@
+We are working to finalize an updated Tendermint specification with formal
+proofs of safety and liveness.
+
+In the meantime, see the [description in the
+docs](http://tendermint.readthedocs.io/en/master/specification/byzantine-consensus-algorithm.html).
+
+There are also relevant but somewhat outdated descriptions in Jae Kwon's [original
+whitepaper](https://tendermint.com/static/docs/tendermint.pdf) and Ethan Buchman's [master's
+thesis](https://atrium.lib.uoguelph.ca/xmlui/handle/10214/9769).

docs/spec/consensus/light-client.md

@@ -0,0 +1,114 @@
+# Light client
+
+A light client is a process that connects to the Tendermint Full Node(s) and then tries to verify the Merkle proofs 
+about the blockchain application. In this document we describe mechanisms that ensures that the Tendermint light client 
+has the same level of security as Full Node processes (without being itself a Full Node). 
+
+To be able to validate a Merkle proof, a light client needs to validate the blockchain header that contains the root app hash. 
+Validating a blockchain header in Tendermint consists in verifying that the header is committed (signed) by >2/3 of the 
+voting power of the corresponding validator set. As the validator set is a dynamic set (it is changing), one of the 
+core functionality of the light client is updating the current validator set, that is then used to verify the 
+blockchain header, and further the corresponding Merkle proofs. 
+
+For the purpose of this light client specification, we assume that the Tendermint Full Node exposes the following functions over
+Tendermint RPC:
+
+```golang
+Header(height int64) (SignedHeader, error) // returns signed header for the given height
+Validators(height int64) (ResultValidators, error) // returns validator set for the given height
+LastHeader(valSetNumber int64) (SignedHeader, error)   // returns last header signed by the validator set with the given validator set number
+
+type SignedHeader struct {
+    Header        Header 
+    Commit        Commit
+    ValSetNumber  int64 
+}
+
+type ResultValidators struct {
+    BlockHeight   int64              
+    Validators    []Validator 
+    // time the current validator set is initialised, i.e, time of the last validator change before header BlockHeight 
+    ValSetTime    int64               
+}
+```
+
+We assume that Tendermint keeps track of the validator set changes and that each time a validator set is changed it is 
+being assigned the next sequence number. We can call this number the validator set sequence number. Tendermint also remembers 
+the Time from the header when the next validator set is initialised (starts to be in power), and we refer to this time
+as validator set init time.
+Furthermore, we assume that each validator set change is signed (committed) by the current validator set. More precisely,
+given a block `H` that contains transactions that are modifying the current validator set, the Merkle root hash of the next 
+validator set (modified based on transactions from block H) will be in block `H+1` (and signed by the current validator 
+set), and then starting from the block `H+2`, it will be signed by the next validator set.    
+
+Note that the real Tendermint RPC API is slightly different (for example, response messages contain more data and function 
+names are slightly different); we shortened (and modified) it for the purpose of this document to make the spec more 
+clear and simple. Furthermore, note that in case of the third function, the returned header has `ValSetNumber` equals to 
+`valSetNumber+1`.    
+
+
+Locally, light client manages the following state:
+
+```golang
+valSet        []Validator    // current validator set (last known and verified validator set) 
+valSetNumber  int64          // sequence number of the current validator set 
+valSetHash    []byte         // hash of the current validator set
+valSetTime    int64          // time when the current validator set is initialised  
+```
+
+The light client is initialised with the trusted validator set, for example based on the known validator set hash,
+validator set sequence number and the validator set init time.
+The core of the light client logic is captured by the VerifyAndUpdate function that is used to 1) verify if the given header is valid,
+and 2) update the validator set (when the given header is valid and it is more recent than the seen headers). 
+
+```golang
+VerifyAndUpdate(signedHeader SignedHeader):
+  assertThat signedHeader.valSetNumber >= valSetNumber  
+  if isValid(signedHeader) and signedHeader.Header.Time <= valSetTime + UNBONDING_PERIOD then
+    setValidatorSet(signedHeader)
+    return true
+  else
+    updateValidatorSet(signedHeader.ValSetNumber)
+    return VerifyAndUpdate(signedHeader)
+
+isValid(signedHeader SignedHeader):
+  valSetOfTheHeader = Validators(signedHeader.Header.Height)
+  assertThat Hash(valSetOfTheHeader) == signedHeader.Header.ValSetHash
+  assertThat signedHeader is passing basic validation
+  if votingPower(signedHeader.Commit) > 2/3 * votingPower(valSetOfTheHeader) then return true
+  else 
+    return false
+
+setValidatorSet(signedHeader SignedHeader):
+  nextValSet = Validators(signedHeader.Header.Height)
+  assertThat Hash(nextValSet) == signedHeader.Header.ValidatorsHash
+  valSet = nextValSet.Validators
+  valSetHash = signedHeader.Header.ValidatorsHash
+  valSetNumber = signedHeader.ValSetNumber
+  valSetTime = nextValSet.ValSetTime  
+
+votingPower(commit Commit):
+  votingPower = 0
+  for each precommit in commit.Precommits do:
+    if precommit.ValidatorAddress is in valSet and signature of the precommit verifies then
+      votingPower += valSet[precommit.ValidatorAddress].VotingPower
+  return votingPower
+
+votingPower(validatorSet []Validator):
+  for each validator in validatorSet do:
+    votingPower += validator.VotingPower    
+  return votingPower
+  
+updateValidatorSet(valSetNumberOfTheHeader):
+  while valSetNumber != valSetNumberOfTheHeader do
+    signedHeader = LastHeader(valSetNumber)
+    if isValid(signedHeader) then
+      setValidatorSet(signedHeader)
+    else return error
+  return
+```
+
+Note that in the logic above we assume that the light client will always go upward with respect to header verifications,
+i.e., that it will always be used to verify more recent headers. In case a light client needs to be used to verify older
+headers (go backward) the same mechanisms and similar logic can be used. In case a call to the FullNode or subsequent 
+checks fail, a light client need to implement some recovery strategy, for example connecting to other FullNode.  

docs/spec/consensus/wal.md

@@ -0,0 +1 @@
+[Moved](/docs/spec/software/wal.md)