PIP-0009: typos, minor edits and higher res image

PIP/PIP-0009.md

@@ -7,7 +7,7 @@
   Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0009)
   Status: Proposed
   Created: 2017-12-17
-  Updated: 2017-12-29 (rev2)
+  Updated: 2017-12-29 (rev2), 2018-01-01 (typos)
 </pre>
 
 ## Summary
@@ -23,7 +23,7 @@ PascalCoin is a 100% original Proof-of-Work coin offering a unique value proposi
 
 **It’s an economics issue, not a technical issue**. Since PascalCoin is GPU-friendly PoW coin, it has become a prime candidate for "dual-miners", especially Ethereum-centric Pool-X. Dual-miners are miners who mine two independent coins simultaneously using the same electricity. This works because some coins are memory-hard (Ethereum) and others are not (PascalCoin). When mining memory-hard coins, GPUs have an abundance of idle computational power which can be re-purposed to simultaneously mine a non-memory-hard coin like PascalCoin. Whilst a great technical innovation, the introduction of dual-mining has fundamentally changed the economics and incentive-model of mining for the "secondary coin". 
 
-Ordinarily, a coins mining eco-system grows organically with interest and centralization does not occur. This is due to the "hash-power follows price" law. As price grows organically due to interest, so do the number of miners. If there are too many miners, the coin becomes unprofitable, and some miners leave. This homeostasis between mining, price and ecosystem size is part of the economic formula that makes cryptocurrencies work.
+Ordinarily, a coins mining ecosystem grows organically with interest and centralization does not occur. This is due to the "hash-power follows price" law. As price grows organically due to interest, so do the number of miners. If there are too many miners, the coin becomes unprofitable, and some miners leave. This homeostasis between mining, price and ecosystem size is part of the economic formula that makes cryptocurrencies work.
 
 With dual-mining, this is broken. Dual-mining has led to coins with small user-base to have totally disproportionate number of miners who mine the coin even when "unprofitable". In the case of PascalCoin, miners are primarily on Pool-X to mine Ethereum, not PascalCoin. So the number of PascalCoin miners are a reflection of Ethereum's ecosystem, not PascalCoin's. Also, these miners mine PascalCoin because they have latent computing power, so it technically costs them nothing to mine PascalCoin. As a result, they mine PascalCoin even when it's unprofitable thus forcing out ordinary miners who are not dual-mining. 
 
@@ -31,20 +31,20 @@ With dual-mining, this is broken. Dual-mining has led to coins with small user-b
 
 ## Specification
 
-A low-memory, GPU and ASIC-resistant hash algorithm called **Random Hash** is proposed to resolve and prevent dual-mining centralization. Random Hash, defined first here, is a "high-level cryptographic hash" algorithm that combines other well-known hash primitives in a highly serial manner. The distinguishing feature is that calculations for a nonce are dependent on partial calculations of other nonces, selected at random. This allows a serial hasher (CPU) to re-use these partial calculations in subsequent nonce-mining saving 50% or more of the work-load. Parallel hashers (GPU) cannot benefit from this optimization since the optimal nonce-set cannot be pre-calculated as it is determined on-the-fly. As a result, parallel hashers (GPU) are required to perform the full workload for every nonce. Also, the algorithm results in 10x memory bloat for a parallel implementation. In additio to it's serial nature, it is branch-heavy and recursive making in optimal for CPU-only mining.
+A low-memory, GPU and ASIC-resistant hash algorithm called **Random Hash** is proposed to resolve and prevent dual-mining centralization. Random Hash, defined first here, is a "high-level cryptographic hash" algorithm that combines other well-known hash primitives in a highly serial manner. The distinguishing feature is that calculations for a nonce are dependent on partial calculations of other nonces, selected at random. This allows a serial hasher (CPU) to re-use these partial calculations in subsequent nonce-mining saving 50% or more of the work-load. Parallel hashers (GPU) cannot benefit from this optimization since the optimal nonce-set cannot be pre-calculated as it is determined on-the-fly. As a result, parallel hashers (GPU) are required to perform the full workload for every nonce. Also, the algorithm results in 10x memory bloat for a parallel implementation. In addition to it's serial nature, it is branch-heavy and recursive making in optimal for CPU-only mining.
 
 ### Overview
 
-1. Hashing a nonce requires N iterations (called rounds)
+1. Hashing a nonce requires ```N``` iterations (called rounds)
 2. Each round selects a random hash function from a set of 16 well-known hash algorithms
-3. The input at round x depends on the output from round x-1
-4. The input at round x depends on the output from another previous round 1..x-1, randomly selected
-5. The input at round x depends on the output from round x-1 **of a different nonce**
-6. The input at round x is a compression of (2), (3) and (4) to 100 bytes.
+3. The input at round ```x``` depends on the output from round ```x-1```
+4. The input at round ```x``` depends on the output from another previous round ```1..x-1```, randomly selected
+5. The input at round x depends on the output from round ```x-1``` **of a different nonce**
+6. The input at round ```x``` is a compression of (3), (4) and (5) to ```100 bytes```.
 7. The output of every round is expanded for memory-hardness
-8. Randomness is generated using Mersenne Twister algorithm
-9. Randomness is seeded via MurMur3 checksum of previous round
-10. The final round is then hashed again via SHA2_256, in keeping with traditional cryptocurrency approaches.
+8. Randomness is generated using ```Mersenne Twister``` algorithm
+9. Randomness is seeded via ```MurMur3``` checksum of previous round
+10. The final round is then hashed again via ```SHA2_256```, in keeping with traditional cryptocurrency approaches.
 
 ### RandomHash Design
 
@@ -71,8 +71,8 @@ A low-memory, GPU and ASIC-resistant hash algorithm called **Random Hash** is pr
             RadioGatun32
             Whirlpool
         ]
-        N = 5           // Number of hashing rounds required to compute a nonce (verifying = N(N+1)/2, CPU mining = N)
-        M = 10KB        // The memory expansion unit in bytes
+        N = 5           // Number of hashing rounds required to compute a nonce (total rounds = 2^N - 1)
+        M = 10KB        // The memory expansion unit (in bytes)
 
         Function RandomHash(blockHeader : ByteArray)
         begin               
@@ -143,7 +143,7 @@ A low-memory, GPU and ASIC-resistant hash algorithm called **Random Hash** is pr
             Result = output
         end 
 
-        function ChangeNonce(blockHeader : RawBytes, nonce : Integer)
+        function ChangeNonce(blockHeader : ByteArray, nonce : Integer) : ByteArray
         begin
             // changes nonce in blockHeader by knowing offset of nonce
         end
@@ -177,7 +177,7 @@ These methods are iteratively and randomly applied to a hash output in order to
 
 #### CPU Bias
 
-The RandomHash algorithm is inherently biased towards CPU mining due to it's highly serial nature. In addition, RandomHash allows CPU miners to cache the partial calculations of the other nonces and resume them later. This allows CPU miners to save 50% of the work during mining. This is formally proven below, but is easy to grasp as follows - in order to complete a nonce to round N, another nonce needed to be completed to round N-1. The other nonce requires 1 more round to complete, saving 50% of the work. This optimal nonce-set cannot be pre-calculated, and can only be enumerated. As a result, serial mining (CPU) does 50% the work of parallel mining (GPU).
+The RandomHash algorithm is inherently biased towards CPU mining due to it's highly serial nature. In addition, RandomHash allows CPU miners to cache the partial calculations of the other nonces and resume them later. This allows CPU miners to save 50% of the work during mining. This is formally proven below, but is easy to grasp as follows - in order to complete a nonce to round ```N```, another nonce needed to be completed to round ```N-1```. The other nonce requires 1 more round to complete, saving 50% of the work. This optimal nonce-set cannot be pre-calculated, and can only be enumerated. As a result, serial mining (CPU) does 50% the work of parallel mining (GPU).
 
 #### Memory Complexity
 
@@ -189,15 +189,15 @@ GPU performance is generally driven by parallel execution of identical non-branc
 
 As a result, it's expected that GPU performance will at best never exceed CPU performance or at worst perform linearly better (not exponentially as is the case now).
 
-
 #### ASIC Resistance 
 
-ASIC-resistance is fundamentally achieved on an economic basis. Since 16 hash algorithms are employed the R&D costs of a RandomHash ASIC are equivalent to that of 16 ordinary mining ASICS. Furthermore, due to the non-deterministic branching and executive decision making arising from Mersenne Twister random number generation and other aspects, an ASIC implementation will inevitable result in a very dense and highly inter-connected cells, resulting in poor performance. It is the opinion of the author that such an ASIC design would require re-creating a CPU inside the ASIC, defeating its purpose. It is expected that since the costs to develop will far exceed the ROI, no rational economic actor will undertake ASIC development of RandomHash.
+ASIC-resistance is fundamentally achieved on an economic basis. Since 16 hash algorithms are employed the R&D costs of a RandomHash ASIC are equivalent to that of 16 ordinary mining ASICS. Furthermore, due to the non-deterministic branching and executive decision making arising from Mersenne Twister, expansion and contraction, an ASIC implementation will inevitably result in dense highly inter-connected cells, impacting performance. It is the opinion of the author that such an ASIC design would, in some ways, require "re-creating a CPU" inside the ASIC, defeating its purpose. However, fundamentally it is expected that since the costs to develop will far exceed the ROI, no rational economic actor will undertake ASIC development of RandomHash.
 
 #### RandomHash Variations
 
-Variations of RandomHash can be made by varying N (the number of rounds required) and M (the memory expansion). For non-blockchain applications, the dependence on other nonces can be removed, providing a high-entropy general-purpose, albeit slow, secure hasher.
+Variations of RandomHash can be made by varying N (the number of rounds required) and M (the memory expansion). For non-blockchain applications, the dependence on other nonces can be removed, providing a cryptographically secure general-purpose, albeit slow, secure hasher.
 
+It is also possible to change the depdendence graph between nonces. For example, requiring the initial rounds to depend on more than one nonce and the higher rounds on no nonces at all, could allow further CPU vs GPU optimization. Similarly, for memory expansion factors.
 
 ### Formal Proofs
 
@@ -210,13 +210,13 @@ Let ```M``` = the memory unit to expand out a hash's output by
 
 #### Hash Complexity
 
-Let ```F(x)``` denote number of hashes required at round x.
+Let ```F(x)``` denote number of hashes required at round ```x```.
 
-Since the first round just hashes the block header, the base case for F is
+Since the first round just hashes the block header, the base case for ```F``` is
 ```
     F(1) = 1
 ```
-Since a hash at round x is the hash of the previous round **and** of round x-1 of another nonce
+Since a hash at round x is the hash of the previous round **and** of round ```x-1``` of another nonce
 ```
     F(x) = 1 + F(x-1) + F(x-1)  
 ```
@@ -244,19 +244,19 @@ Firstly, after a full RandomHash involving ```N``` rounds, the total count of ha
     TotalHashesAtRound(x) = 2^(N-x)     
 ```
 
-**NOTE**: Use above diagram to visualize and understand this. 
- - pick any row x
+**NOTE**: Use above [diagram](#randomhash-design) to visualize and understand this. 
+ - pick any row ```x```
  - count horizontally 
- - note that N=5 in that diagram
+ - note that ```N=5``` in the [diagram](#randomhash-design)
 
 It follows that the total memory for the round is calculated as follows
 ```
     TotalMemoryAtRound(x) = (N-x) * TotalHashesAtRound(x)
                           = 2^(N-x) * (N-x)
 ```
-This can be seen by observing the memory-expansion factors in the diagram. Notice it starts at N-1 for the first round and decrease every subsequent round. 
+This can be seen by observing the memory-expansion factors in the diagram. Notice it starts at ```N-1``` for the first round and decrease every subsequent round. 
 
-The total memory, G(N) is simply the sum of all the memory at each round
+The total memory, ```G(N)``` is simply the sum of all the memory at each round
 ```
     G(N) = sum(i=1, N) TotalMemoryAtRound(i)
          = sum(i=1, N) 2^(N-i) * (N-i)
@@ -268,14 +268,14 @@ Thus,
     G(N) = 2^N (N-2) + 2
 ```
 
-**NOTE**: For PascalCoin N=5 which means 98 units of memory are required for a single nonce. Choosing memory unit M=10kb means that approximately 1MB will be required. Quite low for a CPU, but bloats quickly for a GPU as mentioned below.
+**NOTE**: For PascalCoin ```N=5``` which means ```98``` units of memory are required for a single nonce. Choosing memory unit ```M=10kb``` means that approximately ```1MB``` will be required. Quite low for a CPU, but bloats quickly for a GPU as mentioned below.
 
 #### CPU Bias
 
 To show that CPU does 50% the hashing work of a GPU consider that
  - N rounds are required to trial a single nonce 
- - After the completion of any nonce, another nonce is known and computed to round N-1
- - Almost all nonce computations resume the previous N-1 nonce, requiring onlY F(N-1) work. This is true for serial mining (CPU), not for parallel mining (GPU)
+ - After the completion of any nonce, another nonce is known and computed to round ```N-1```
+ - Almost all nonce computations resume the previous ```N-1``` nonce, requiring onlY ```F(N-1)``` work. This is true for serial mining (CPU), not for parallel mining (GPU)
 
 Thus the work a CPU does is
  
@@ -310,9 +310,9 @@ Since this is a significant change, the PascalCoin community will be asked to vo
         Account 9876-54 with 0 PASC is considered 1 votes
         Account 1234-56 with 100 PASC is considered 101 votes
 
-### Implementation
+#### Implementation
 
-If after a period of time and consensus is reached, RandomHash will be merged into the PascalCoin codebase by the PascalCoin developers. After thorough testing on TestNet, a suitable activation date will be chosen to allow ecosystem to adopt this mandatory upgrade. A release will be made and notifications provided of activation within the timeframe.
+If after a period of time and consensus is reached, RandomHash will be merged into the PascalCoin code-base by the PascalCoin developers. After thorough testing on TestNet, a suitable activation date will be chosen to allow ecosystem to adopt this mandatory upgrade. A release will be made and notifications provided of activation within the time-frame.
 
 #### Difficulty Reset
 
@@ -328,7 +328,6 @@ Within the scope of changing hash algorithm, other possible hash algorithms like
 
 This PIP is not backwards compatible and requires a hard-fork activation. Previous hashing algorithm must be retained in order to validate blocks mined prior to the hard-fork.
  
-
 ## Reference Implementation
 
 A reference implementation will be provided in the coming weeks.
@@ -336,5 +335,7 @@ A reference implementation will be provided in the coming weeks.
 ## Links
 
 1. [Mersennne Twister Implementation (Lazarus/FPC)][1]
+2. [MurMur3 Implementation (Lazarus/FPC)][2]
 
 [1]: http://wiki.freepascal.org/A_simple_implementation_of_the_Mersenne_twister
+[2]: https://github.com/Xor-el/HashLib4Pascal/blob/master/HashLib/src/Hash32/HlpMurmurHash3_x86_32.pas