Edit general layout for manual documentation

Author: Seung Woo Kim

docs/asset-management.rst

@@ -161,6 +161,7 @@ Next, we create an output which gives 3000 gold to Bob, and returns 7000 gold to
 
 By using Alice's signature, the 10000 Gold that was first minted can now be transferred to other users like Bob.
 ::
+
     await sendTransaction(transferTx);
     const transferTxInvoice = await sdk.rpc.chain.getTransactionInvoice(transferTx.hash(), 5 * 60 * 1000);
     if (!transferTxInvoice.success) {

docs/asset-transaction.rst

@@ -0,0 +1,21 @@
+.. _asset-transaction:
+
+##############################
+Asset Transactions
+##############################
+When assets are created, there has to be transactions that change ownership of those assets. However, there is a difference between a transaction that involves
+newly minted assets and existing assets.
+
+Asset Mint Transaction
+==============================
+When assets are newly minted, there are a couple of things you must understand. First, the asset's scheme must be defined, since the asset being created must have some
+sort of definition. Second, there must be an owner to this newly minted asset. Thus, when creating assets in CodeChain, an address of the owner is required. A transaction
+that sends fresh minted assets to a user is called the `Asset Mint Transaction <https://codechain.readthedocs.io/en/latest/asset-management.html#minting-creating-new-assets>`_.
+The address used for Asset Mint Transactions should follow the `Address Format <https://codechain.readthedocs.io/en/latest/asset-management.html#address-format>`_.
+
+Asset Transfer Transaction
+==============================
+Once assets have been successfully minted, these assets can now be sent to other users. For instance, let's say that the initial owner of the newly minted assets
+is Alice. If Alice wants to send some assets to Bob, then a transaction must be created. This transaction of sending assets from one user to another is called
+the Asset Transfer Transaction. By using Alice's signature, assets can be send to any user, if their `Asset Address <https://codechain.readthedocs.io/en/latest/asset-management.html#asset-transfer-address-format>`_
+is known.

docs/blakepow.rst

@@ -0,0 +1,8 @@
+.. _blakepow:
+
+#############################
+BlakePoW
+#############################
+BlakePoW follows the Proof-of-Work model of Bitcoin, where a hash is calculated by adding the nonce and the block hash. It is then checked whether
+this added value is less than or equal to the target value over and over again. If you want an algorithm not bound to forms of processing power,
+please use Cuckoo.

docs/configuration.rst

@@ -4,220 +4,8 @@
 Configuration
 ####################
 
-CodeChain can be configured with either CLI options or a config file. When it comes to which options take precedence, it goes from CLI, user's own config.toml file, and config.dev.toml in that order.
+.. toctree::
+    :maxdepth: 2
 
-CLI options can be listed by running the command ``$codechain --help``. By using the CLI options, or custom config files, the user can overwrite config.dev.toml's configurations.
-
-Config File
-===========
-The default preset ``config.dev.toml`` file can be located in ``codechain/config/presets/config.dev.toml``.
-
-Config files can be customized by the user and its location can be designated by using the CLI command ``--config``. Custom config files created by the user must have the proper custom path.
-
-Default config.dev.toml
-=======================
-The following represents the default configuration values of ``config.dev.toml``.
-::
-
-    [codechain]
-    quiet = false
-    db_path = "db"
-    keys_path = "keys"
-    chain = "solo"
-    secret_key = "0x0000000000000000000000000000000000000000000000000000000000000001"
-
-    [mining]
-
-    [network]
-    disable = false
-    port = 3485
-    max_peers = 30
-    min_peers = 10
-    bootstrap_addresses = []
-    sync = true
-    parcel_relay = true
-    discovery = true
-    discovery_type = "unstructured"
-    discovery_refresh = 60000
-    discovery_bucket_size = 10
-
-    [rpc]
-    disable = false
-    port = 8080
-
-    [ipc]
-    disable = false
-    path = "/tmp/jsonrpc.ipc"
-
-    [snapshot]
-    disable = false
-    path = "snapshot"
-
-CodeChain is set to use the Solo consensus algorithm by default. Tendermint is not suitable for solo testing purposes, since it requires a minimum of 4 users to function properly.
-
-In order to test CodeChain alone, you may want to change chain to Solo. To do this, use ``--chain solo``.
-
-CLI Options for CodeChain client
-================================
-    ``--config=[PATH]``
-        Specify the certain config file path that you want to use to configure CodeChain to your needs.
-
-    ``--port=[PORT]``
-        Listen for connections on PORT. (default: 3485)
-
-    ``--bootstrap-addresses=[BOOTSTRAP_ADDRESSES]``
-        Bootstrap addresses to connect.
-
-    ``--no-network``
-        Do not open network socket.
-
-    ``--min-peers=[NUM]``
-        Set the minimum number of connections the user would like. (default: 10)
-
-    ``--max-peers=[NUM]``
-        Set the maximum number of connections the user would like. (default: 30)
-
-    ``--instance-id=[ID]``
-        Specify instance id for logging. Used when running multiple instances of CodeChain.
-
-    ``--quiet``
-        Do not show any synchronization information in the console.
-
-    ``--chain=[CHAIN]``
-        Set the blockchain type out of solo, solo_authority, tendermint or a path to chain spec file. (default: solo)
-
-    ``--db-path=[PATH]``
-        Specify the database directory path.
-
-    ``--keys-path=[PATH]``
-        Specify the path for JSON key files to be found.
-
-    ``snapshot-path=[PATH]``
-        Specify the snapshot directory path.
-
-    ``--no-sync``
-        Do not run block sync extension.
-
-    ``--no-parcel-relay``
-        Do not relay parcels.
-
-    ``--jsonrpc-port=[PORT]``
-        Listen for rpc connections on PORT. (default: 8080)
-
-    ``--no-ipc``
-        Do not run JSON-RPC over IPC service.    
-
-    ``--ipc-path=[PATH]``
-        Specify custom path for JSON-RPC over IPC service
-
-    ``--no-jsonrpc``
-        Do not run jsonrpc.
-
-    ``--secret-key=[KEY]``
-        Secret key used by node.
-
-    ``--author=[ADDRESS]``
-        Specify the block's author (aka "coinbase") address for sending block rewards from 
-        sealed blocks.
-
-    ``--engine-signer=[ADDRESS]``
-        Specify the address which should be used to sign consensus messages and 
-        issue blocks.
-
-    ``--mem-pool-mem-limit=[MB]``
-        Maximum amount of memory that can be used by the mem pool. Setting this parameter to 0 disables limiting.
-
-    ``--mem-pool-size=[LIMIT]``
-        Maximum amount of parcels in the queue (waiting to be included in next block).
-
-    ``notify-work=[URLS]``
-        URLs to which work package notifications are pushed.
-
-    ``force-sealing``
-        Force the node to author new blocks as if it were always sealing/mining.
-
-    ``reseal-min-period=[MS]``
-        Specify the minimum time between reseals from incoming parcels. MS is time measured in milliseconds.
-
-    ``reseal-max-period=[MS]``
-        Specify the maximum time since last block to enable force-sealing. MS is time measured in milliseconds.
-
-    ``work-queue-size=[ITEMS]``
-        Specify the number of historical work packages which are kept cached lest a solution is found for them later. High values take more memory but result in fewer unusable solutions.
-
-    ``--no-discovery``
-        Do not use discovery. No automated peer finding.
-
-    ``--discovery="kademlia" | "unstructured"``
-        Decides which p2p discovery extension to use. Options are `kademlia <https://github.com/CodeChain-io/codechain/wiki/Kademlia-Extension>`_ and unstructured.
-        In a testing environment, an unstructured p2p network is desirable because it is
-        more than sufficient when there are a few users.
-        (default: unstructured)
-
-    ``--discovery-bucket-size=[NUM]``
-        Bucket size for discovery. Choose how many addresses to exchange at a time
-        during discovery.
-
-    ``--discovery-refresh=[ms]``
-        Refresh timeout of discovery (ms). It may conflict with:`` --no-discovery``.
-
-    ``--no-snapshot``
-        Disable snapshots
-
-Logging
-=======
-For logging, run the following to configure:
-``$ RUST_LOG=<level> codechain``
-
-Log Levels
-----------
-CodeChain currently offers five different ``<level>``. They are error, warn, info, debug, and trace.
-
-For example, the log level will be set to debug, if you run the following:
-
-``$ RUST_LOG="debug" codechain``
-
-* The **error** level represents an event where something can be dangerous, but can still run. In the case in which it cannot run anymore, it must crash ASAP instead of logging.
-
-* The **warn** level represents an event which can be potentially dangerous.
-
-* The **info** level represents an event which is not dangerous, but can be useful information for users.
-
-* The **debug** level represents an event that is useful for developers, but not for users.
-
-* The **trace** level is used for tracing.
-
-Log Targets
------------
-
-Log levels can be set differently for each log targets. For example, you can run the following to set ``tx``'s log level as ``trace`` and ``parcel``'s 
-log level as ``info`` with the following code:
-
-``$ RUST_LOG="tx=trace,parcel=info" codechain``
-
-The possible log targets are as follows:
-::
-
-    "blockchain"
-    "client"
-    "discovery"
-    "engine"
-    "external_parcel"
-    "io"
-    "mem_pool"
-    "miner"
-    "net"
-    "netapi"
-    "own_parcel"
-    "poa"
-    "shutdown"
-    "snapshot"
-    "solo_authoirty"
-    "spec"
-    "state"
-    "state_db"
-    "stratum"
-    "sync"
-    "test_script"
-    "trie"
-    "tx"
+    how-to-configure
+    logging

docs/consensus-algorithms.rst

@@ -6,52 +6,12 @@ Consensus Algorithms
 Currently there are five consensus algorithms being used in CodeChain. Conensus algorithms each have their strengths,
 which is why a variety is being offered.
 
-Solo
-==========================
-Used for testing purposes only when there is only one node in the entire network. Solo is not a consensus algorithm.
-
-Tendermint
-==========================
-`Tendermint <https://tendermint.com/>`_ is a Proof-of-Stake algorithm which is designed to tolerate machines that fail in arbitrary ways,
-which is also known as Byzantine fault tolerance(BFT). Tendermint claims that even if 1/3 of the machines fail, it will still operate properly,
-offering a secure and consistent system.
-
-BlakePoW
-==========================
-BlakePoW follows the Proof-of-Work model of Bitcoin, where a hash is calculated by adding the nonce and the block hash. It is then checked whether
-this added value is less than or equal to the target value over and over again. If you want an algorithm not bound to forms of processing power,
-please use Cuckoo.
-
-Cuckoo
-==========================
-Cuckoo aims to be resistant to Bitcoin style hardware arms-races by making its algorithm memory bound. Thus, solution times should be bound to
-memory bandwidth instead of other forms of raw processing power. As a result, Cuckoo should be a viable solution for running on most commodity
-hardware, and require far less energy than other forms of PoW algorithms that are bound to GPU, CPU or ASIC.
-
-PoW Mining Difficulty
-==========================
-Currently, the mining difficulty is adjusted depending on the timestamp differences of the blocks. If the difference is less than 10 seconds,
-the difficulty is adjusted upwards. If the timestamp difference is between 10 to 19 seconds, the difficulty is left unchanged. If greater
-than or equal to 20 seconds, the difficulty is adjusted downwards proportional to the timestamp difference.
-
-RPC API
-==========================
-For examples, please click `here <https://github.com/CodeChain-io/codechain/blob/master/spec/JSON-RPC.md#miner_getwork>`_.
-
-``miner_getWork``
-
-Returns the hash of the current block, the score and the block number.
-
-Params: No parameters
-
-Return Type: work object
-
-``miner_submitWork``
-
-Used for submitting a proof-of-work solution.
-
-Params:
-
-powHash: string
-seal: Array of string
-Return Type: bool
+.. toctree::
+    :maxdepth: 2
+
+    solo
+    tendermint
+    blakepow
+    cuckoo
+    pow-mining-difficulty
+    rpc-api

docs/cuckoo.rst

@@ -0,0 +1,8 @@
+.. _cuckoo:
+
+#############################
+Cuckoo
+#############################
+Cuckoo aims to be resistant to Bitcoin style hardware arms-races by making its algorithm memory bound. Thus, solution times should be bound to
+memory bandwidth instead of other forms of raw processing power. As a result, Cuckoo should be a viable solution for running on most commodity
+hardware, and require far less energy than other forms of PoW algorithms that are bound to GPU, CPU or ASIC.

docs/gateway.rst

@@ -0,0 +1,8 @@
+.. _gateway:
+
+#####################
+Gateway
+#####################
+Gateways are responsible for gathering transactions and grouping them into parcels, which are then added
+to the blockchain. Gateways must have platform accounts that contain :ref:`codechain-coin`, since gateways
+are responsible for paying the transaction fees.