From ef9a574bb5d808e5c07c8510aed083b58150b81d Mon Sep 17 00:00:00 2001 From: troymc Date: Mon, 14 Mar 2016 10:06:42 +0100 Subject: [PATCH 1/3] Mention milesones etc. in ROADMAP.md --- ROADMAP.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/ROADMAP.md b/ROADMAP.md index 9c2ad425..79fadf02 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,5 +1,10 @@ # BigchainDB Roadmap +See also: + +* [Milestones](https://github.com/bigchaindb/bigchaindb/milestones) (i.e. issues to be closed before various releases) +* [Open issues](https://github.com/bigchaindb/bigchaindb/issues) and [open pull requests](https://github.com/bigchaindb/bigchaindb/pulls) + ## BigchainDB Protocols * Validation of other nodes * Fault tolerance From ae97f4b8e1983a10f964e51b4659df2937e23770 Mon Sep 17 00:00:00 2001 From: troymc Date: Mon, 14 Mar 2016 16:54:23 +0100 Subject: [PATCH 2/3] Clarify the meaning of some timestamps in the docs --- docs/source/models.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/source/models.md b/docs/source/models.md index 267a1a84..0a86036f 100644 --- a/docs/source/models.md +++ b/docs/source/models.md @@ -12,7 +12,7 @@ Transactions, blocks and votes are represented using JSON documents with the fol "new_owner": "", "input": "", "operation": "", - "timestamp": "", + "timestamp": "", "data": { "hash": "", "payload": { @@ -34,7 +34,7 @@ A transaction is an operation between the `current_owner` and the `new_owner` ov - `input`: id (sha3 hash) of the transaction in which the content was transfered to the user (similar to input in the blockchain). Right now we will assume that there is only one input per transaction to simplify the prototype. This can be changed in the future to allow multiple inputs per transaction. - `operation`: String representation of the operation being performed (REGISTER, TRANSFER, ...) this will define how the transactions should be validated -- `timestamp`: Time of creation of the transaction in UTC +- `timestamp`: Time of creation of the transaction in UTC. It's provided by the client. - `data`: JSON object describing the asset (digital content). It contains at least the field `hash` which is a sha3 hash of the digital content. - `signature`: Signature of the transaction with the `current_owner` private key @@ -45,7 +45,7 @@ sha3 hash of the digital content. { "id": "", "block": { - "timestamp": "", + "timestamp": "", "transactions": [""], "node_pubkey": "", "voters": [""] @@ -62,7 +62,7 @@ A block contains a group of transactions and includes the hash of the hash of th - `id`: sha3 hash of the contents of `block` (i.e. the timestamp, list of transactions, node_pubkey, and voters). This is also a RethinkDB primary key; that's how we ensure that all blocks are unique. - `block`: The actual block - - `timestamp`: timestamp when the block was created + - `timestamp`: timestamp when the block was created. It's provided by the node that created the block. - `transactions`: the list of transactions included in the block - `node_pubkey`: the public key of the node that create the block - `voters`: list public keys of the federation nodes. Since the size of the From 645430d24dc3b4fa907f8a037e799c138c0ea526 Mon Sep 17 00:00:00 2001 From: troymc Date: Mon, 14 Mar 2016 17:13:04 +0100 Subject: [PATCH 3/3] Clarify meaning of transaction id in docs --- docs/source/models.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/models.md b/docs/source/models.md index 0a86036f..a7b0ae4e 100644 --- a/docs/source/models.md +++ b/docs/source/models.md @@ -28,7 +28,7 @@ Transactions, blocks and votes are represented using JSON documents with the fol A transaction is an operation between the `current_owner` and the `new_owner` over the digital content described by `hash`. For example if could be a transfer of ownership of the digital content `hash` -- `id`: sha3 hash of the transaction. Also the RethinkDB primary key. By using the hash of the transaction as the primary key, we eliminate the problem of duplicated transactions, if for some reason two nodes decide to create the same transaction +- `id`: sha3 hash of the transaction. The `id` is also the DB primary key. - `current_owner`: Public key of the current owner of the digital content with hash `hash` - `new_owner`: Public key of the new owner of the digital content with hash `hash` - `input`: id (sha3 hash) of the transaction in which the content was transfered to the user (similar to input in the blockchain). Right now we will assume that there is only one input per transaction to simplify the prototype. This can be changed in the future to allow multiple inputs per transaction.