Update all docs re/ votes when Tendermint integrated

docs/root/source/decentralized.md

@@ -4,7 +4,7 @@ Decentralization means that no one owns or controls everything, and there is no
 
 Ideally, each node in a BigchainDB cluster is owned and controlled by a different person or organization. Even if the cluster lives within one organization, it's still preferable to have each node controlled by a different person or subdivision.
 
-We use the phrase "BigchainDB consortium" (or just "consortium") to refer to the set of people and/or organizations who run the nodes of a BigchainDB cluster. A consortium requires some form of governance to make decisions such as membership and policies. The exact details of the governance process are determined by each consortium, but it can be very decentralized (e.g. purely vote-based, where each node gets a vote, and there are no special leadership roles).
+We use the phrase "BigchainDB consortium" (or just "consortium") to refer to the set of people and/or organizations who run the nodes of a BigchainDB cluster. A consortium requires some form of governance to make decisions such as membership and policies. The exact details of the governance process are determined by each consortium, but it can be very decentralized.
 
 If sharding is turned on (i.e. if the number of shards is larger than one), then the actual data is decentralized in that no one node stores all the data.
 

docs/root/source/immutable.md

@@ -13,7 +13,7 @@ Blockchain data can achieve immutability in several ways:
 1. **External watchdogs.** A consortium may opt to have trusted third-parties to monitor and audit their data, looking for irregularities. For a consortium with publicly-readable data, the public can act as an auditor.
 1. **Economic incentives.** Some blockchain systems make it very expensive to change old stored data. Examples include proof-of-work and proof-of-stake systems. BigchainDB doesn't use explicit incentives like those.
 1. Data can be stored using fancy techniques, such as error-correction codes, to make some kinds of changes easier to undo.
-1. **Cryptographic signatures** are often used as a way to check if messages (e.g. transactions, blocks or votes) have been tampered with enroute, and as a way to verify who signed the messages. In BigchainDB, each transaction must be signed (by one or more parties), each block is signed by the node that created it, and each vote is signed by the node that cast it.
+1. **Cryptographic signatures** are often used as a way to check if messages (e.g. transactions) have been tampered with enroute, and as a way to verify who signed the messages. In BigchainDB, each transaction must be signed by one or more parties.
 1. **Full or partial backups** may be recorded from time to time, possibly on magnetic tape storage, other blockchains, printouts, etc.
 1. **Strong security.** Node owners can adopt and enforce strong security policies.
 1. **Node diversity.** Diversity makes it so that no one thing (e.g. natural disaster or operating system bug) can compromise enough of the nodes. See [the section on the kinds of node diversity](diversity.html).

docs/server/source/appendices/index.rst

@@ -18,4 +18,3 @@ Appendices
    licenses
    run-with-vagrant
    run-with-ansible
-   vote-yaml

docs/server/source/appendices/vote-yaml.rst

@@ -1,20 +0,0 @@
-The Vote Schema File
-====================
-
-BigchainDB checks all :ref:`votes <The Vote Model>`
-(JSON documents) against a formal schema
-defined in a JSON Schema file named vote.yaml.
-The contents of that file are copied below.
-To understand those contents
-(i.e. JSON Schema), check out
-`"Understanding JSON Schema"
-<https://spacetelescope.github.io/understanding-json-schema/index.html>`_
-by Michael Droettboom or
-`json-schema.org <http://json-schema.org/>`_.
-
-
-vote.yaml
----------
-
-.. literalinclude:: ../../../../bigchaindb/common/schema/vote.yaml
-   :language: yaml

docs/server/source/data-models/index.rst

@@ -9,4 +9,3 @@ Data Models
    inputs-outputs
    conditions
    block-model
-   vote-model

docs/server/source/data-models/vote-model.rst

@@ -1,120 +0,0 @@
-The Vote Model
-==============
-
-A vote is a JSON object with a particular schema,
-as outlined in this page.
-A vote must contain the following JSON keys
-(also called names or fields):
-
-.. code-block:: json
-
-    {
-        "node_pubkey": "<The public key of the voting node>",
-        "vote": {
-            "voting_for_block": "<ID of the block the node is voting on>",
-            "previous_block": "<ID of the block previous to the block being voted on>",
-            "is_block_valid": "<true OR false>",
-            "invalid_reason": null,
-            "timestamp": "<Vote-creation timestamp>"
-        },
-        "signature": "<Signature of inner vote object>"
-    }
-
-.. note::
-   
-   Votes have no ID (or ``"id"``), as far as users are concerned.
-   The backend database may use one internally,
-   but it's of no concern to users and it's never reported to them via APIs.
-
-
-The JSON Keys in a Vote
------------------------
-
-**node_pubkey**
-
-The public key of the node which cast this vote.
-It's a string.
-For more information about public keys,
-see the `IPDB Transaction Spec <https://github.com/ipdb/ipdb-tx-spec>`_
-section about cryptographic keys and signatures.
-
-
-**vote.voting_for_block**
-
-The block ID that this vote is for.
-It's a string.
-For more information about block IDs,
-see the page about :ref:`blocks <The Block Model>`.
-
-
-**vote.previous_block**
-
-The block ID of the block "before" the block that this vote is for,
-according to the node which cast this vote.
-It's a string.
-(It's possible for different nodes to see different block orders.)
-For more information about block IDs,
-see the page about :ref:`blocks <The Block Model>`.
-
-
-**vote.is_block_valid**
-
-``true`` if the node which cast this vote considered the block in question to be valid,
-and ``false`` otherwise.
-Note that it's a *boolean* (i.e. ``true`` or ``false``), not a string.
-
-
-**vote.invalid_reason**
-
-Always ``null``, that is, it's not being used.
-It may be used or dropped in a future version.
-See `bigchaindb/bigchaindb issue #217
-<https://github.com/bigchaindb/bigchaindb/issues/217>`_ on GitHub.
-
-
-**vote.timestamp**
-
-The `Unix time <https://en.wikipedia.org/wiki/Unix_time>`_
-when the vote was created, according to the node which created it.
-It's a string representation of an integer.
-
-
-**signature**
-
-The cryptographic signature of the inner ``vote``
-by the node that created the vote
-(i.e. the node with public key ``node_pubkey``).
-To compute that:
-
-#. Construct an :term:`associative array` ``d`` containing the contents of the inner ``vote``
-   (i.e. ``vote.voting_for_block``, ``vote.previous_block``, ``vote.is_block_valid``,
-   ``vote.invalid_reason``, ``vote.timestamp``, and their values).
-#. Compute ``signature = sig_of_aa(d, private_key)``, where ``private_key``
-   is the node's private key (i.e. ``node_pubkey`` and ``private_key`` are a key pair).
-   There's pseudocode for the ``sig_of_aa()`` function
-   on the `IPDB Transaction Spec <https://github.com/ipdb/ipdb-tx-spec>`_
-   section about cryptographic keys and signatures.
-
-The Vote Schema
----------------
-
-BigchainDB checks all votes (JSON documents) against a formal schema
-defined in a :ref:`JSON Schema file named vote.yaml <The Vote Schema File>`.
-
-
-An Example Vote
----------------
-
-.. code-block:: json
-
-    {
-        "node_pubkey": "3ZCsVWPAhPTqHx9wZVxp9Se54pcNeeM5mQvnozDWyDR9",
-        "vote": {
-            "voting_for_block": "11c3a3fcc9efa4fc4332a0849fc39b58e403ff37794a7d1fdfb9e7703a94a274",
-            "previous_block": "3dd1441018b782a50607dc4c7f83a0f0a23eb257f4b6a8d99330dfff41271e0d",
-            "is_block_valid": true,
-            "invalid_reason": null,
-            "timestamp": "1509977988"
-        },
-        "signature": "3tW2EBVgxaZTE6nixVd9QEQf1vUxqPmQaNAMdCHc7zHik5KEosdkwScGYt4VhiHDTB6BCxTUzmqu3P7oP93tRWfj"
-    }

docs/server/source/events/websocket-event-stream-api.rst

@@ -69,7 +69,7 @@ All messages sent in a stream are in the JSON format.
 
     For simplicity, BigchainDB initially only provides a stream for all
     validated transactions. In the future, we may provide streams for other
-    information, such as new blocks, new votes, or invalid transactions. We may
+    information. We may
     also provide the ability to filter the stream for specific qualities, such
     as a specific ``output``'s ``public_key``.
 
@@ -99,8 +99,4 @@ Example message:
 .. note::
 
     Transactions in BigchainDB are validated in batches ("blocks") and will,
-    therefore, be streamed in batches. Each block can contain up to a 1000
-    transactions, ordered by the time at which they were included in the block.
-    The ``/valid_transactions`` stream will send these transactions in the same
-    order that the block stored them in, but this does **NOT** guarantee that
-    you will recieve the events in that same order.
+    therefore, be streamed in batches.

docs/server/source/http-client-server-api.rst

@@ -518,9 +518,6 @@ a certain transaction with ``transaction_id`` occured in (a transaction can occu
 either gets rejected or validated by the system). This endpoint gives the ability to drill down on the lifecycle of a
 transaction
 
-The `votes endpoint <#votes>`_ contains all the voting information for a specific block. So after retrieving the
-``block_id`` for a given ``transaction_id``, one can now simply inspect the votes that happened at a specific time on that block.
-
 
 Blocks
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~