From afc661d360d879e52178e43fc1f9ec3a188eac64 Mon Sep 17 00:00:00 2001 From: diminator Date: Wed, 17 Aug 2016 15:44:32 +0200 Subject: [PATCH] PR review docs --- docs/source/drivers-clients/http-client-server-api.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/source/drivers-clients/http-client-server-api.rst b/docs/source/drivers-clients/http-client-server-api.rst index e622641d..1da816ae 100644 --- a/docs/source/drivers-clients/http-client-server-api.rst +++ b/docs/source/drivers-clients/http-client-server-api.rst @@ -199,16 +199,16 @@ The HTTP API currently exposes two endpoints, one to get information about a spe **Disclaimer** ``CREATE`` transactions are treated differently from ``TRANSFER`` assets. - The reason is that a ``CREATE`` transaction needs to be signed by the federation nodes and not by the client. + The reason is that a ``CREATE`` transaction needs to be signed by a federation node and not by the client. - The following python snippet at the client can be used to generate ``CREATE`` transactions before they can be pushed to the API server: + The following python snippet in a client can be used to generate ``CREATE`` transactions before they can be pushed to the API server: .. code-block:: python from bigchaindb import util tx = util.create_and_sign_tx(my_privkey, my_pubkey, my_pubkey, None, 'CREATE') - When POSTing ``tx`` to the API, the ``CREATE`` transaction will be signed by the federation nodes. + When POSTing ``tx`` to the API, the ``CREATE`` transaction will be signed by a federation node. A ``TRANSFER`` transaction, that takes an existing input transaction to change ownership can be generated in multiple ways: