Fix headings, line breaks

8 files changed, 58 insertions, 40 deletions

diff --git a/docs/blockchain_tests/index.rst b/docs/blockchain_tests/index.rst
index 27b8cd76d..6b4ed420f 100644
--- a/docs/blockchain_tests/index.rst
+++ b/docs/blockchain_tests/index.rst
@@ -1,8 +1,7 @@
 .. _blockchain_tests:
 
-################################################################################
 Blockchain Tests
-################################################################################
+================
 
 Found in `/BlockChainTests <https://github.com/ethereum/tests/tree/develop/BlockchainTests>`_,
 the blockchain tests aim is to test the basic verification of a blockchain.
@@ -80,7 +79,7 @@ Basic structure
 
 
 Sections
---------------------------------------------------------------------------------
+--------
 
 * The ``genesisBlockHeader`` section
 
@@ -138,7 +137,7 @@ Sections
 * ``uncleHeaders`` section is a list of block headers which have the same format as descibed in `genesisBlockHeader`.
 
 Optional BlockHeader Sections (Information fields)
---------------------------------------------------------------------------------
+--------------------------------------------------
 
 ``"blocknumber" = "int"`` is section which defines what is the order of this block. 
 It is used to define a situation when you have 3 blocks already imported but then it comes new version of the block 2 and 3 and thus you might have new best blockchain with blocks 1 2' 3' instead previous. If `blocknumber` is undefined then it is assumed that blocks are imported one by one. When running test, this field could be used for information purpose only.
diff --git a/docs/contribute.rst b/docs/contribute.rst
index 02055b463..eab88d00f 100644
--- a/docs/contribute.rst
+++ b/docs/contribute.rst
@@ -1,6 +1,5 @@
 .. _contribute:
 
-==================
 Contribute to Docs
 ==================
 
diff --git a/docs/index.rst b/docs/index.rst
index cfd45916f..5dd1f5518 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -1,8 +1,8 @@
 .. _ethereum_tests:
 
-################################################################################
+##############
 Ethereum Tests
-################################################################################
+##############
 | Common tests for all clients to test against. The `git repo <https://github.com/ethereum/tests>`_ updated regulary with new tests. 
 | This section describes basic test concepts and templates which are created by cpp-client. 
 |
diff --git a/docs/rlp_tests/index.rst b/docs/rlp_tests/index.rst
index 00ba3dc7b..154bd5890 100644
--- a/docs/rlp_tests/index.rst
+++ b/docs/rlp_tests/index.rst
@@ -1,22 +1,26 @@
 .. _rlp_tests:
 
-################################################################################
 RLP Tests
-################################################################################
+=========
 
-Describes an **RLP** (https://github.com/ethereum/wiki/wiki/RLP) encoding using the .json file.
-The client should read the rlp byte stream, **decode** and check whether the contents match its json representation. Then it should try do it reverse - **encode** json rlp representation into rlp byte stream and check whether it matches the given rlp byte stream.
+Describes an **RLP** (https://github.com/ethereum/wiki/wiki/RLP) encoding using 
+the .json file. The client should read the rlp byte stream, **decode** and check 
+whether the contents match its json representation. Then it should try do it 
+reverse - **encode** json rlp representation into rlp byte stream and check whether 
+it matches the given rlp byte stream.
 
 If it is an invalid RLP byte stream in the test, then 'in' field would contain string 'INVALID'
 
-Some RLP byte streams are expected to be generated by fuzz test suite. For those examples 'in' field would contain string 'VALID' as it means that rlp should be easily decoded.
+Some RLP byte streams are expected to be generated by fuzz test suite. For those 
+examples 'in' field would contain string 'VALID' as it means that rlp should be easily decoded.
 
 RLP tests are located in in ``/RLPTests``
 
-**Note** that RLP tests are testing a single RLP object encoding. Not a stream of RLP objects in one array.
+**Note** that RLP tests are testing a single RLP object encoding. Not a stream of 
+RLP objects in one array.
 
 Basic structure
---------------------------------------------------------------------------------
+---------------
 
 ::
 
@@ -44,7 +48,7 @@ Basic structure
 	}
 
 Sections
---------------------------------------------------------------------------------
+--------
 
 * ``in`` - json object (array, int, string) representation of the rlp byte stream (\*except values 'VALID' and 'INVALID')
 * ``out`` - string of rlp bytes stream
diff --git a/docs/state_tests/index.rst b/docs/state_tests/index.rst
index 978d2542a..a57f3b4c2 100644
--- a/docs/state_tests/index.rst
+++ b/docs/state_tests/index.rst
@@ -1,8 +1,7 @@
 .. _state_tests:
 
-################################################################################
 General State Tests
-################################################################################
+===================
 
 Found in `/GeneralStateTests <https://github.com/ethereum/tests/tree/develop/GeneralStateTests>`_, 
 the state tests aim is to test the basic workings of the state in isolation.
@@ -28,7 +27,7 @@ and ``pre`` then check their results against ``logs``, ``out``, and ``post``.
    integrated in these docs in the future.
 
 Basic structure
---------------------------------------------------------------------------------
+---------------
 
 ::
 
diff --git a/docs/transaction_tests/index.rst b/docs/transaction_tests/index.rst
index ffe65247d..eb06504f6 100644
--- a/docs/transaction_tests/index.rst
+++ b/docs/transaction_tests/index.rst
@@ -1,15 +1,14 @@
 .. _transaction_tests:
 
-################################################################################
 Transaction Tests
-################################################################################
+=================
 
 Describes a complete transaction and its `RLP <https://github.com/ethereum/wiki/wiki/RLP>`_ representation using the .json file.
 The client should read the rlp and check whether the transaction is valid, has the correct sender and corresponds to the transaction parameters.
 If it is an invalid transaction, the transaction and the sender object will be missing.
 
 Basic structure
---------------------------------------------------------------------------------
+---------------
 ::
 
 	{
@@ -37,7 +36,7 @@ Basic structure
 	}
 
 Sections
---------------------------------------------------------------------------------
+--------
 
 * ``rlp`` - RLP encoded data of this transaction
 * ``transaction`` - transaction described by fields
diff --git a/docs/using-testeth.rst b/docs/using-testeth.rst
index 49ef3945a..390225d7f 100644
--- a/docs/using-testeth.rst
+++ b/docs/using-testeth.rst
@@ -1,7 +1,7 @@
 
-*****************************************************
 Using Testeth
-*****************************************************
+=============
+
 Ethereum cpp-client testeth tool for creation and execution of ethereum tests.
 
 To run tests you should open folder (see also `Installing and building <http://www.ethdocs.org/en/latest/ethereum-clients/cpp-ethereum/index.html#installing-and-building>`_
@@ -51,7 +51,7 @@ That's it for test execution. To read more about command line options you may ru
 Now let's see what test cases are available.
 
 Test Cases
---------------------------------------------------------------------------------
+----------
 
 Almost each test case has its filler file available at ``/webthree-umbrella/libethereum/test``
 
diff --git a/docs/vm_tests/index.rst b/docs/vm_tests/index.rst
index 732c4d08b..16716d53b 100644
--- a/docs/vm_tests/index.rst
+++ b/docs/vm_tests/index.rst
@@ -1,23 +1,41 @@
 .. _vm_tests:
 
-################################################################################
 VM Tests
-################################################################################
-
-Found in ``/VMTest``, the VM tests aim is to test the basic workings of the VM in isolation. This is specifically not meant to cover transaction, creation or call processing, or management of the state trie. Indeed at least one implementation tests the VM without calling into any Trie code at all.
-
-It is based around the notion of executing a single piece of code as part of a transaction, described by the ``exec`` portion of the test. The overarching environment in which it is executed is described by the ``env`` portion of the test and includes attributes of the current and previous blocks. A set of pre-existing accounts are detailed in the ``pre`` portion and form the world state prior to execution. Similarly, a set of accounts are detailed in the ``post`` portion to specify the end world state.
-
-The gas remaining (``gas``), the log entries (``logs``) as well as any output returned from the code (``output``) is also detailed.
-
-Because the data of the blockchain is not given, the opcode BLOCKHASH could not return the hashes of the corresponding blocks. Therefore we define the hash of block number n to be SHA3-256("n").
-
-Since these tests are meant only as a basic test of VM operation, the ``CALL`` and ``CREATE`` instructions are not actually executed. To provide the possibility of testing to guarantee they were actually run at all, a separate portion ``callcreates`` details each ``CALL`` or ``CREATE`` operation in the order they would have been executed. Furthermore, gas required is simply that of the VM execution: the gas cost for transaction processing is excluded.
-
-It is generally expected that the test implementer will read ``env``, ``exec`` and ``pre`` then check their results against ``gas``, ``logs``, ``out``, ``post`` and ``callcreates``. If an exception is expected, then latter sections are absent in the test. Since the reverting of the state is not part of the VM tests.
+========
+
+Found in ``/VMTest``, the VM tests aim is to test the basic workings of the VM in
+isolation. This is specifically not meant to cover transaction, creation or call 
+processing, or management of the state trie. Indeed at least one implementation 
+tests the VM without calling into any Trie code at all.
+
+It is based around the notion of executing a single piece of code as part of a transaction, 
+described by the ``exec`` portion of the test. The overarching environment in which it is 
+executed is described by the ``env`` portion of the test and includes attributes 
+of the current and previous blocks. A set of pre-existing accounts are detailed 
+in the ``pre`` portion and form the world state prior to execution. Similarly, a set 
+of accounts are detailed in the ``post`` portion to specify the end world state.
+
+The gas remaining (``gas``), the log entries (``logs``) as well as any output returned 
+from the code (``output``) is also detailed.
+
+Because the data of the blockchain is not given, the opcode BLOCKHASH could not 
+return the hashes of the corresponding blocks. Therefore we define the hash of 
+block number n to be SHA3-256("n").
+
+Since these tests are meant only as a basic test of VM operation, the ``CALL`` and 
+``CREATE`` instructions are not actually executed. To provide the possibility of 
+testing to guarantee they were actually run at all, a separate portion ``callcreates`` 
+details each ``CALL`` or ``CREATE`` operation in the order they would have been executed. 
+Furthermore, gas required is simply that of the VM execution: the gas cost for 
+transaction processing is excluded.
+
+It is generally expected that the test implementer will read ``env``, ``exec`` and ``pre`` 
+then check their results against ``gas``, ``logs``, ``out``, ``post`` and ``callcreates``. 
+If an exception is expected, then latter sections are absent in the test. Since the 
+reverting of the state is not part of the VM tests.
 
 Basic structure
---------------------------------------------------------------------------------
+---------------
 
 ::