|
@@ -140,24 +140,24 @@ However, within the 18 hash algorithms used, some are considered "cryptographica
|
|
|
|
|
|
In order to get a grasp of the minmum security provided by RandomHash2, consider it's high-level algorithmic structure as essentially a set of nested hashes as follows:
|
|
|
```
|
|
|
-RandomHash2(Data) = SHA2_256( H1( H2( .... H_N( SHA2_256(DATA)) ...) )
|
|
|
+RandomHash2(Data) = SHA2_256( H1( H2( .... H_N( SHA2_256( DATA ) ) ...) )
|
|
|
where
|
|
|
H_i = a randomly selected hash function based on the output of H_(i-1)
|
|
|
N = a random number determined by the nonce and neighbouring nonces (indeterminable but bound)
|
|
|
```
|
|
|
|
|
|
-It follows that the weakest possible RandomHash2 for some ```WeakestDigest``` would comprise of 2 levels of evaluation (``MIN_N=2```) with each of those 2 levels having 0 nieghbouring nonce dependencies (```MIN_J```). Also, we assume the hash algorithms are ```MD5``` for all levels, as it is considered weakest of the 18 possible algorithms. In this case,
|
|
|
+It follows that the weakest possible RandomHash2 for some ```WeakestDigest``` would comprise of 2 levels of evaluation (```MIN_N=2```) with each of those 2 levels having 0 neighbouring nonce dependencies (```MIN_J=0```). Also, we assume the hash algorithms used at all levels were ```MD5```, as it is considered weakest of the set of 18 possible algorithms. In this case,
|
|
|
```
|
|
|
RandomHash2(WeakestDigest) = SHA2_256( MD5 ( MD5 ( SHA2_256( WeakestDigest ) ) ) )
|
|
|
```
|
|
|
|
|
|
-Clearly the above is still far stronger than the typical SHA2-256D used in almost all cryptocurrencies
|
|
|
+Clearly the above is still far stronger than the typical SHA2-256D used in Bitcoin and almost all other cryptocurrencies since
|
|
|
+
|
|
|
```pascal
|
|
|
SHA2-256D(WeakestDigest) = SHA2-256 ( SHA2-256 ( WeakestDigest ) )
|
|
|
```
|
|
|
|
|
|
-
|
|
|
-In addition to the above, RandomHash2 internally transforms data using expansions and compressions which are themselves cryptographically secure. As a result, it's clear that RandomHash2's cryptographic strength is at least as strong as Bitcoin's ```SHA2-256D``` with likelihood of being orders of magnitude stronger.
|
|
|
+In addition to the above, RandomHash2 internally transforms data using expansions and compressions which are themselves cryptographically secure. As a result, it's clear that RandomHash2's cryptographic strength is at least as strong as Bitcoin's ```SHA2-256D``` with the likelihood of also being orders of magnitude stronger.
|
|
|
|
|
|
### Nonce Scanning Attack
|
|
|
|
|
@@ -165,9 +165,9 @@ In RandomHash2, the number of levels ```N``` required to mine a nonce is now ran
|
|
|
|
|
|
To thwart this attack, RandomHash2 restricts the range of values ```N``` can take to be between ```MIN_N = 2``` and ```MAX_N = 4```, inclusive.
|
|
|
|
|
|
-By forcing a nonce evaluation to have at least 2 levels of computation, the miner necessarily requires the full algorithm implementation which prevents simplified ASIC miners. Also, since each nonce requires at least 2 levels of evaluation, and each of those levels depends on at least 2 more nonces evaluated to at least 1 level each, the number of computations saved by nonce-scanning is balanced by the higher pre-computed cached nonces a miner has by honestly mining without nonce-scanning (due to higher number of dependent neighboring nonces).
|
|
|
+By forcing a nonce evaluation to have at least 2 levels of computation, the miner necessarily requires the full algorithm implementation which prevents simplified ASIC miners. Also, since each nonce requires at least 2 levels of evaluation, and each of those levels is likely to depend other nonces to 1 level each, the number of computations saved by nonce-scanning must be balanced by the number of pre-computed cached nonces a miner would get if they were honestly mining without nonce-scanning (due to higher number of dependent neighboring nonces).
|
|
|
|
|
|
-In order to determine if this is true, an empirical nonce-scanning attack was conducted. The below table shows empirical results from nonce-scanning ```N=MIN_N``` to ```N=MAX_N```.
|
|
|
+In order to determine if this balance is achieved, an empirical nonce-scanning attack was conducted. The below table shows empirical results from nonce-scanning ```N=MIN_N``` to ```N=MAX_N```.
|
|
|
|
|
|
| N | Mean Hashrate (H/s) | Mean Mem Per Hash (b) | Min Mem Per Hash (b) | Max Mem Per Hash (b) | Sample Std Dev. (b) |
|
|
|
| :------ | :------------------------ | :-------------------- | :------------------- | :------------------- | :------------------ |
|
|
@@ -177,7 +177,7 @@ In order to determine if this is true, an empirical nonce-scanning attack was co
|
|
|
|
|
|
_**Machine**: AMD FX-8150 8 Core 3.60 Ghz utilizing 1 thread_
|
|
|
|
|
|
-As the above table shows, nonce-scanning (via CPU) yields a hashrate penalty, not a benefit. In the opinion of the author, it is unlikely a future implementation optimization would necessarily change this result since it would improve all scanning levels proportionally. However, a line of inquiry is to investigate whether or not the reduced memory-hardness may yield a benefit for GPU-based nonce-scanning.
|
|
|
+As the above table shows, this balance is achieved. Nonce-scanning (via CPU) yields no benefit whatsoever and in fact incurs a hashrate penalty. Also, it is the opinion of the author that any future optimization would change this balance since it would benefit all levels proportionally. However, a line of inquiry is to investigate if whether or not the reduced memory-hardness of nonce-scanning may yield a benefit for GPU-based nonce-scanning attack. In any event, the result of this attack is only to gain higher hashrate and **does not compromise the cryptographic security** of the blockchain whatsoever.
|
|
|
|
|
|
#### CPU Bias
|
|
|
|