docs: clarified how block id & signature are calculated

This commit is contained in:
Troy McConaghy 2017-02-16 09:52:00 +01:00
parent 8106fcfbeb
commit f6ebba8389

View File

@ -17,7 +17,7 @@ A block has the following structure:
} }
- ``id``: The hash of the serialized ``block`` (i.e. the ``timestamp``, ``transactions``, ``node_pubkey``, and ``voters``). This is also a database primary key; that's how we ensure that all blocks are unique. - ``id``: The :ref:`hash <Hashes>` of the serialized inner ``block`` (i.e. the ``timestamp``, ``transactions``, ``node_pubkey``, and ``voters``). It's used as a unique index in the database backend (e.g. RethinkDB or MongoDB).
- ``block``: - ``block``:
- ``timestamp``: The Unix time when the block was created. It's provided by the node that created the block. - ``timestamp``: The Unix time when the block was created. It's provided by the node that created the block.
@ -27,7 +27,7 @@ A block has the following structure:
It's the list of federation nodes which can cast a vote on this block. It's the list of federation nodes which can cast a vote on this block.
This list can change from block to block, as nodes join and leave the federation. This list can change from block to block, as nodes join and leave the federation.
- ``signature``: Cryptographic signature of the block by the node that created the block. (To create the signature, the node serializes the block contents and signs it with its private key.) - ``signature``: :ref:`Cryptographic signature <Signature Algorithm and Keys>` of the block by the node that created the block. To generate the signature, the node builds a dict including the ``id``, the inner ``block`` & the ``signature`` (with a value of ``None``), it serializes that dict, and then signs *that* with its private key.
Working with Blocks Working with Blocks