s/fulfillments/inputs/g && s/conditions/outputs/g (docs changes)

docs/root/source/immutable.md

@@ -11,7 +11,7 @@ BigchainDB achieves strong tamper-resistance in the following ways:
 1. **Replication.** All data is sharded and shards are replicated in several (different) places. The replication factor can be set by the federation. The higher the replication factor, the more difficult it becomes to change or delete all replicas.
 2. **Internal watchdogs.** All nodes monitor all changes and if some unallowed change happens, then appropriate action is taken. For example, if a valid block is deleted, then it is put back.
 3. **External watchdogs.** Federations may opt to have trusted third-parties to  monitor and audit their data, looking for irregularities. For federations with publicly-readable data, the public can act as an auditor.
-4. **Cryptographic signatures** are used throughout BigchainDB as a way to check if messages (transactions, blocks and votes) have been tampered with enroute, and as a way to verify who signed the messages. Each block is signed by the node that created it. Each vote is signed by the node that cast it. A creation transaction is signed by the node that created it, although there are plans to improve that by adding signatures from the sending client and multiple nodes; see [Issue #347](https://github.com/bigchaindb/bigchaindb/issues/347). Transfer transactions can contain multiple fulfillments (one per asset transferred). Each fulfillment will typically contain one or more signatures from the owners (i.e. the owners before the transfer). Hashlock fulfillments are an exception; there’s an open issue ([#339](https://github.com/bigchaindb/bigchaindb/issues/339)) to address that.
+4. **Cryptographic signatures** are used throughout BigchainDB as a way to check if messages (transactions, blocks and votes) have been tampered with enroute, and as a way to verify who signed the messages. Each block is signed by the node that created it. Each vote is signed by the node that cast it. A creation transaction is signed by the node that created it, although there are plans to improve that by adding signatures from the sending client and multiple nodes; see [Issue #347](https://github.com/bigchaindb/bigchaindb/issues/347). Transfer transactions can contain multiple inputs (fulfillments, one per asset transferred). Each fulfillment will typically contain one or more signatures from the owners (i.e. the owners before the transfer). Hashlock fulfillments are an exception; there’s an open issue ([#339](https://github.com/bigchaindb/bigchaindb/issues/339)) to address that.
 5. **Full or partial backups** of the database may be recorded from time to time, possibly on magnetic tape storage, other blockchains, printouts, etc.
 6. **Strong security.** Node owners can adopt and enforce strong security policies.
 7. **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/root/source/transaction-concepts.md

@@ -18,7 +18,7 @@ That means you can create/register an asset with an initial quantity,
 e.g. 700 oak trees. Divisible assets can be split apart or recombined
 by transfer transactions (described more below).
 
-A CREATE transaction also establishes the conditions that must be met to
+A CREATE transaction also establishes the conditions (outputs) that must be met to
 transfer the asset(s). For example, there may be a condition that any transfer
 must be signed (cryptographically) by the private key associated with a
 given public key. More sophisticated conditions are possible.
@@ -28,19 +28,19 @@ Protocol (ILP)](https://interledger.org/).
 ## TRANSFER Transactions
 
 A TRANSFER transaction can transfer an asset
-by fulfilling the current conditions on the asset.
+by provding inputs which fulfill the current output conditions on the asset.
 It must also specify new transfer conditions.
 
 **Example 1:** Suppose a red car is owned and controlled by Joe.
 Suppose the current transfer condition on the car says
 that any valid transfer must be signed by Joe.
 Joe and a buyer named Rae could build a TRANSFER transaction containing
-Joe's signature (to fulfill the current transfer condition)
-plus a new transfer condition saying that any valid transfer
+an input with Joe's signature (to fulfill the current output condition)
+plus a new output condition saying that any valid transfer
 must be signed by Rae.
 
 **Example 2:** Someone might construct a TRANSFER transaction
-that fulfills the transfer conditions on four
+that fulfills the output conditions on four
 previously-untransferred assets of the same asset type
 e.g. paperclips. The amounts might be 20, 10, 45 and 25, say,
 for a total of 100 paperclips.

docs/server/source/data-models/asset-model.md

@@ -26,6 +26,6 @@ For `TRANSFER` transactions we only keep the asset id.
 - `updatable`: Whether the data in the asset can be updated in the future or not. Defaults to false.
 - `refillable`: Whether the amount of the asset can change after its creation. Defaults to false.
 - `data`: A user supplied JSON document with custom information about the asset. Defaults to null.
-- _amount_: The amount of "shares". Only relevant if the asset is marked as divisible. Defaults to 1. The amount is not specified in the asset, but in the conditions (see next section).
+- _amount_: The amount of "shares". Only relevant if the asset is marked as divisible. Defaults to 1. The amount is not specified in the asset, but in the outputs (see next section).
 
 At the time of this writing, updatable and refillable assets are not yet implemented.

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

@@ -3,7 +3,7 @@ Data Models
 
 BigchainDB stores all data in the underlying database as JSON documents (conceptually, at least). There are three main kinds:
 
-1. Transactions, which contain digital assets, conditions, fulfillments and other things
+1. Transactions, which contain digital assets, inputs, outputs and other things
 2. Blocks
 3. Votes
 

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

@@ -22,8 +22,8 @@ A transaction has the following structure:
     {
         "id": "<hash of transaction, excluding signatures (see explanation)>",
         "version": "<version number of the transaction model>",
-        "fulfillments": ["<list of fulfillments>"],
-        "conditions": ["<list of conditions>"],
+        "inputs": ["<list of inputs>"],
+        "outputs": ["<list of outputs>"],
         "operation": "<string>",
         "asset": "<digital asset description (explained in the next section)>",
         "metadata": "<any JSON document>"
@@ -33,12 +33,12 @@ Here's some explanation of the contents of a :ref:`transaction <transaction>`:
 
 - id: The :ref:`id <transaction.id>` of the transaction, and also the database primary key.
 - version: :ref:`Version <transaction.version>` number of the transaction model, so that software can support different transaction models.
-- **fulfillments**: List of fulfillments. Each :ref:`fulfillment <Fulfillment>` contains a pointer to an unspent asset
+- **inputs**: List of inputs. Each :ref:`input <Input>` contains a pointer to an unspent asset
   and a *crypto fulfillment* that satisfies a spending condition set on the unspent asset. A *fulfillment*
   is usually a signature proving the ownership of the asset.
   See :doc:`./crypto-conditions`.
 
-- **conditions**: List of conditions. Each :ref:`condition <Condition>` is a *crypto-condition* that needs to be fulfilled by a transfer transaction in order to transfer ownership to new owners.
+- **outputs**: List of outputs. Each :ref:`output <Output>` is a *crypto-condition* that needs to be fulfilled by a transfer transaction in order to transfer ownership to new owners.
   See :doc:`./crypto-conditions`.
 
 - **operation**: String representation of the :ref:`operation <transaction.operation>` being performed (currently either "CREATE", "TRANSFER" or "GENESIS"). It determines how the transaction should be validated.
@@ -47,6 +47,6 @@ Here's some explanation of the contents of a :ref:`transaction <transaction>`:
 
 - **metadata**: User-provided transaction :ref:`metadata <metadata>`: Can be any JSON document, or `NULL`.
 
-Later, when we get to the models for the block and the vote, we'll see that both include a signature (from the node which created it). You may wonder why transactions don't have signatures... The answer is that they do! They're just hidden inside the ``fulfillment`` string of each fulfillment. A creation transaction is signed by whoever created it. A transfer transaction is signed by whoever currently controls or owns it.
+Later, when we get to the models for the block and the vote, we'll see that both include a signature (from the node which created it). You may wonder why transactions don't have signatures... The answer is that they do! They're just hidden inside the ``fulfillment`` string of each input. A creation transaction is signed by whoever created it. A transfer transaction is signed by whoever currently controls or owns it.
 
-What gets signed? For each fulfillment in the transaction, the "fullfillment message" that gets signed includes the ``operation``, ``data``, ``version``, ``id``, corresponding ``condition``, and the fulfillment itself, except with its fulfillment string set to ``null``. The computed signature goes into creating the ``fulfillment`` string of the fulfillment.
+What gets signed? For each input in the transaction, the "fullfillment message" that gets signed includes the ``operation``, ``data``, ``version``, ``id``, corresponding ``condition``, and the fulfillment itself, except with its fulfillment string set to ``null``. The computed signature goes into creating the ``fulfillment`` string of the input.

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

@@ -160,14 +160,14 @@ GET /unspents/
 
 .. http:get:: /unspents?owner_after={owner_after}
 
-   Get a list of links to transactions' conditions that have not been used in
-   a previous transaction and could hence be called unspent conditions/outputs
+   Get a list of links to transactions' outputs that have not been used in
+   a previous transaction and could hence be called unspent outputs
    (or simply: unspents).
 
    This endpoint will return a ``HTTP 400 Bad Request`` if the querystring
    ``owner_after`` happens to not be defined in the request.
 
-   Note that if unspents for a certain ``owner_after`` have not been found by
+   Note that if unspents for a certain ``public_key`` have not been found by
    the server, this will result in the server returning a 200 OK HTTP status
    code and an empty list in the response's body.
 
@@ -189,8 +189,8 @@ GET /unspents/
       Content-Type: application/json
 
       [
-        "../transactions/2d431073e1477f3073a4693ac7ff9be5634751de1b8abaa1f4e19548ef0b4b0e/conditions/0",
-        "../transactions/2d431073e1477f3073a4693ac7ff9be5634751de1b8abaa1f4e19548ef0b4b0e/conditions/1"
+        "../transactions/2d431073e1477f3073a4693ac7ff9be5634751de1b8abaa1f4e19548ef0b4b0e/outputs/0",
+        "../transactions/2d431073e1477f3073a4693ac7ff9be5634751de1b8abaa1f4e19548ef0b4b0e/outputs/1"
       ]
 
    :statuscode 200: A list of outputs were found and returned in the body of the response.