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

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.
+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.