Reorder field in the block

Miners should choose a transaction from the network based on its reward,
not as part of the mining variability.
That's why it's a bad idea to place the transaction as last block element.

Reorder the fields to make less room for harmful mining optimization.

docs/blockchain.md

@@ -14,17 +14,17 @@ ed25519 keys are used to validate transactions.
 
 | content | size (bytes) |
 |---|---|
-| nonce | 8 |
-| timestamp (unix time in seconds, BE) | 8 |
-| previous hash | 32 |
-| message (arbitrary) | 32 |
-| difficulty sum (BE) | 32 |
-| miner pubkey | 32 |
 | transaction (optional) | 148 |
+| message (arbitrary) | 32 |
+| miner pubkey | 32 |
+| previous hash | 32 |
+| timestamp (unix time in seconds, BE) | 8 |
+| difficulty sum (BE) | 32 |
+| nonce | 8 |
 
 If no transaction is included, its 148 bytes are all null.
 
-The first block has block id 0 and a "previous hash" value of 32 null bytes.
+The first block has a "previous hash" value of 32 null bytes.
 
 ## transaction datastructure
 
@@ -51,7 +51,7 @@ If a transaction is included, the following happens additionally:
 
 ## calculating difficulty
 
-The "difficulty sum" field (included in each block) is the cumulative sum of all block difficulty values, beginning with the first block.
+The "difficulty sum" field (included in each block) is the cumulative sum of all block difficulty values. The first block has a "difficulty sum" value of 2^29.
 
 The block difficulty value is not directly stated in each block but can be calculated by subtracting the "difficulty sum" of the previous block from the "difficulty sum" of the current block.
 
@@ -74,9 +74,9 @@ block_difficulty = max(calculated_difficulty, 2^28)
 
 Note the max() operation: A difficulty can never be lower than 2^28 (=268435456). This is a strict lower bound.
 
-For the first block, the "difficulty sum" value is set to 2^29.
+For the first block, the "difficulty sum" value is set to 2^29 but its actual difficulty value is only 2^28.
 
-Early in the chain, when less than 11 blocks have been mined, we make assumptions for blocks "before" the first block:
+Early in the chain, for calculating the "difficulty sum" of the first 10 blocks, we make assumptions for blocks "before" the first block:
 - Each of these "before" blocks had a block difficulty of exactly 2^28
 - The timestamp difference between each two blocks before the first block is exactly 300 seconds.
 
@@ -92,8 +92,8 @@ The "signature" field must be an ed25519 signature over the concatenation of all
 A transaction that is stored in a block must fulfill the following criteria (in addition to the valid signature):
 
 - There was never another transaction with the same ("id", "sender") pair anywhere in the block chain before.
-- Following the balances in the block chain, the "sender" key has enough money for both payments. (amount + transaction fee)  
-  The mining reward of the current block is not counted. A miner can not use his fresh mined money in a transaction in the same block where he mined it, only in the following blocks.
+- Following the balances in the block chain, the "sender" key has enough money for both payments (amount + transaction fee) before the mining reward (1,00 cc + transaction fee) is counted.  
+  This means: A miner cannot create a block that mines money and at the same time contains a transaction that relies on this 1,00 cc reward being available. After mining money in one block, the following block is the earliest possibility to pay this fresh mined money.
 
 ### block
 
@@ -101,7 +101,8 @@ A block is valid if all of the following criteria are fulfilled:
 
 - The "previous hash" field contains a SHA256 hash value of a previous valid block. (Or is completely filled with nullbytes, in case of the first block.)
 - The first block has a public key with the following SHA256 hash value:  
-  88023d392db35f2d3936abd0532003ae0a38b4d35e4d123a0fa28c568c7e3e2f
+  88023d392db35f2d3936abd0532003ae0a38b4d35e4d123a0fa28c568c7e3e2f  
+  The public key that matches this stated hash value will be kept secret until the launch day. Then it will be released along with the first block.
 - The "timestamp" field is greater than the timestamp of the previous block (if there is any). Equal timestamps are not allowed.
 - The "timestamp" field is less than or equal to the current time. This needs to be decided by each node based on the local clock.
 - The "difficulty sum" must be precisely calculated, as specified in `calculating difficulty`

docs/protocol-v0.md

@@ -168,10 +168,10 @@ The node should answer to a "Mining task request" with a "Mining task response"
 | protocol version = 0 (BE) | 2 |
 | capable version = 0 (BE) | 2 |
 | type = 8 (BE) | 1 |
-| timestamp (unix time in seconds, BE) | 8 |
-| previous hash | 32 |
-| difficulty sum (BE) | 32 |
 | transaction (optional) | 148 |
+| previous hash | 32 |
+| timestamp (unix time in seconds, BE) | 8 |
+| difficulty sum (BE) | 32 |
 
 The node tells the miner "timestamp", "previous hash", "difficulty sum" and "transaction" for the new block.