Clarifications to SHA3 hash and addition of progress-freeness concept in Pooling Capacity (#72)

doc/pow/pow.md

@@ -85,13 +85,13 @@ a more difficult exercise as the size of a graph grows. It also becomes easier a
 The Cuckoo Cycles algorithm is a specialised algorithm designed to solve exactly this problem, and it does
 so by inserting values into a structure called a 'Cuckoo Hashtable' according to a hash which maps nodes
 into possible locations in two separate arrays. This document won't go into detail on the base algorithm, as
-it's outlined in plain enough detail in section 5 of the 
+it's outlined plainly enough in section 5 of the 
 [white paper](https://github.com/tromp/cuckoo/blob/master/doc/cuckoo.pdf). There are also several
 variants on the algorithm that make various speed/memory tradeoffs, again beyond the scope of this document. 
 However, there are a few details following from the above that we need to keep in mind before going on to more 
-technical details of Grin's proof-of-work.
+technical aspects of Grin's proof-of-work.
  
-* The 'random' graphs, as detailed above, are not actually random but are generated by putting nodes through a
+* The 'random' graphs demonstrated above are not actually random but are generated by putting nodes through a
 seeded hashing function, SIPHASH, generating two potential locations (one in each array) for each node in the graph.
 The seed will come from a hash of a block header, outlined further below. 
 * The 'Proof' created by this algorithm is a set of nonces that generate the cycle, which can be trivially validated by other nodes.
@@ -113,7 +113,7 @@ The Cuckoo Cycle outlined above forms the basis of Grin's mining process, howeve
 In order to provide additional difficulty control in a manner that meets the needs of a network with constantly evolving hashpower
 availability, a further Hashcash-based difficulty check is applied to potential solution sets as follows: 
 
-If the SHA256 hash
+If the SHA3-256 (Keccak) hash
 of a potential set of solution nonces (currently an array of 42 u32s representing the cycle nonces,) 
 is less than an evolving difficulty target T, then the solution is considered valid. More precisely, 
 the proof difficulty is calculated as the maximum target hash (2^256) divided by the current hash, 
@@ -129,12 +129,14 @@ keeping the average block solution time within range of a target (currently 60 s
 to change). 
 
 The difficulty calculation is based on both Digishield and GravityWave family of difficulty computation, 
-coming to something very close to Zcash. The refence difficulty is an average of the difficulty over a window of
+coming to something very close to ZCash. The refence difficulty is an average of the difficulty over a window of
 23 blocks (the current consensus value). The corresponding timespan is calculated by using the difference between 
 the median timestamps at the beginning and the end of the window. If the timespan is higher or lower than a certain
 range, (adjusted with a dampening factor to allow for normal variation,) then the difficulty is raised or lowered
 to a value aiming for the target block solve time.
 
+The minimum difficuly is 10, as defined in the consensus MINIMUM_DIFFICULTY value.
+
 ### The Mining Loop
 
 All of these systems are put together in the mining loop, which attempts to create 
@@ -161,11 +163,11 @@ valid Proofs-of-Work to create the latest block in the chain. The following is a
                 of a solution appearing in the graph
             * The Cuckoo Cycle detection algorithm tries to find a solution (i.e. a cycle of length 42) within the generated
             graph. 
-            * If a cycle is found, a SHA256 hash of the proof is created and is compared to the current target
+            * If a cycle is found, a SHA3-256 hash of the proof is created and is compared to the current target
             difficulty, as outlined in [Additional Difficulty Control](#additional-difficulty-control) above.
-            * If the SHA256 Hash difficulty is greater than or equal to the target difficulty, the block is sent to the
+            * If the SHA3-256 Hash difficulty is greater than or equal to the target difficulty, the block is sent to the
             transaction pool, propogated amongst peers for validation, and work begins on the next block.
-            * If the SHA256 Hash difficulty is less than the target difficulty, the proof is thrown out and the timed loop continues.
+            * If the SHA3-256 Hash difficulty is less than the target difficulty, the proof is thrown out and the timed loop continues.
             * If no solution is found, increment the nonce in the header by 1, and update the header's timestamp so the next iteration
             hashes a different value for seeding the next loop's graph generation step.
             * If the loop times out with no solution found, start over again from the top, collecting new transactions and creating
@@ -200,9 +202,24 @@ to be changed as faster and more optimised Cuckoo Cycle algorithms are put in pl
 
 ### Pooling Capability
 
-[More detail needed here] Note that contrary to some concerns about the ability to effectively pool Cuckoo Cycle mining, pooling Grin's POW
-as outlined above is relatively straightforward. Members of the pool are able to prove they're working on a solution
-by submitting valid proofs that simply fall under the current network target difficulty.
+Contrary to some existing concerns about Cuckoo Cycle's poolability, the POW implementation in Grin as described above
+is perfectly suited to a mining pool. While it may be difficult to prove efforts to solve a single graph in isolation,
+the combination of factors within Grin's proof-of-work combine to enforce a notion called 'progress-freeness', which
+enables 'poolability' as well as a level of fairness among all miners. 
+
+#### Progress Freeness
+
+Progress-freeness is central to the 'poolability' of a proof-of-work, and is simply based on the idea that a solution 
+to a POW problem can be found within a reasonable amount of time. For instance, if a blockchain
+has a one minute POW time and miners have to spend one minute on average to find a solution, this still satisfies the POW
+requirement but gives a strong advantage to big miners. In such a setup, small miners will generally lose at least one minute
+every time while larger miners can move on as soon as they find a solution. So in order to keep mining relatively progress-free,
+a POW that requires multiple solution attempts with each attempt taking a relatively small amount of time is desirable.
+
+Following from the this, Grin's progress-freeness is due to the fact that a solution to a Cuckoo with Grin's default parameters
+can typically be found in under a second on most GPUs, and there is the additional requirement of the SHA3-256 difficulty check
+on top of that. Members of a pool are thus able to prove they're working on a solution to a block by submitting valid Cuckoo solutions
+(or a small bundle of them) that simply fall under the current network target difficulty.