Added PIP-0009

PIP/PIP-0009.md

@@ -0,0 +1,141 @@
+<pre>
+  PIP: PIP-0009
+  Title: RandomHash: GPU & ASIC Resistant Hash Algorithm
+  Type: Protocol
+  Impact: Hard-Fork
+  Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
+  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0009)
+  Status: Draft
+  Created: 2017-12-17
+</pre>
+
+## Summary
+
+A GPU and ASIC resistant hashing algorithm change is proposed in order to resolve the current mining centralisation siutation and to prevent future dual-mining centralisation.
+
+## Motivation
+
+PascalCoin is currently experiencing 99% mining centralisation by a single pool which has severely impacted eco-system growth and adoption. Exchanges are reticent to list PASC due to the risk of double-spend attacks and infrastructure providers are reticent to invest due to low-volume and stunted price-growth. 
+
+### Background
+PascalCoin is a 100% original Proof-of-Work coin offering a unique value proposition focused on scalability. After the initial launch, a healthy decentralised mining community emerged and became active in the coins eco-system, as expected. However, after 9 months a single pool (herein referred to as Pool-X) managed to centralise mining over a short period of time. At the time, it was believed that a technical exploit was being employed by Pool-X, but this possibility was ruled out after exhaustive analysis and review by the developers and 3rd parties. It is now understood why and how this centralisation occured, and how it can be fixed.
+
+**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 centralisation does not occur. This is due to the "hashpower 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 eco-system 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. 
+
+**These mis-aligned economic incentives result in a rapid convergence to 99% centralisation, even though no actor is malicious.**
+
+
+
+## Specification
+
+A GPU and ASIC-resistant hash algorithm called **Random Hash** is proposed to resolve and prevent dual-mining centralisation. Random Hash, defined first here, is a "high-level cryptographic hash" that employs other well-known cryptographic hash functions in multiple rounds in a non-deterministic manner.
+
+### Overview
+
+- A total of 16 cryptographic hash functions are used
+- A total of 16 rounds of hashing are applied
+- The hash function used in round N is randomly selected using the last byte of round N-1 output
+- The input digest for round N is composed of the output of round N-1 salted with the output of a randoml  previous round 1..N
+- The first and last rounds always use SHA2-256
+
+
+### RandomHash pseudo-code
+
+        const
+            HASH_ALGO = [
+                SHA2_256
+                SHA2_384
+                SHA2_512
+                SHA3,
+                RIPEMD160,
+                RIPEMD256,
+                RIPEMD320,
+                Blake2b, 
+                Blake2s,
+                Tiger2,
+                Snerfu,
+                Grindahl512,
+                Haval,
+                MD5
+                RadioGatun32
+                Whirlpool
+            ]
+
+        Function RandomHash(input : RawBytes) : RawBytes;
+        var
+            Values : array[0..15] of TRawBytes;
+            HashFunc : function (bytes: TRawBytes) : RawBytes of object;
+            SaltDigest : RawBytes;
+        begin
+            Values = array[0..15] of RawBytes;
+
+            // Perform 16 rounds of hashing 
+            for i = 0 to 15
+                if i = 0 then                    
+                    HashFunc = HASH_ALGO[0]   // first round is SHA2-256
+                    SaltDigest = []
+                else
+                    input = Values[i - 1]
+                    let random16 = input.LastByte % 16
+                    if i = 15 then
+                        HashFunc = HASH_ALGO[0]   // last round is SHA2-256
+                    else 
+                        HashFunc =  HASH_ALGO[random16] 
+                    SaltDigest = Values[random16 % i]
+
+                // Perform this round of hashing
+                Values[i] = HashFunc(input ++ SaltDigest)
+            end     
+            Result := Values[15]
+        end;
+
+
+### GPU Resistance 
+
+GPU performance is generally driven by duplicating a code-block of sequential, non-branching instructions across many physical computational modules and executing them in parallel. Each duplicated code-block accesses an independent and isolated region of memory without any inter-dependence on another. The fundamental strategy employed by RandomHash to hinder GPU performance is by breaking parallelizability of the code-block. Only the entire RandomHash can be parallelized, not it's vast internal instructions replete with non-deterministic branching and executive decision-making. 
+
+In particular, the hash-path taken by a single RandomHash trial varies for every input and is not known until the path is finished.
+
+<pre>
+Example Hash-Paths:
+RandomHash("input1") = <b>SHA256</b>(SHA3(Blake2s(Whirlpool(....... <b>SHA256</b>(digest))))))))))))))))
+RandomHash("input2") = <b>SHA256</b>(RIPEMD160(Tiger(Snerfu(..... <b>SHA256</b>(digest)))))))))))))))) 
+</pre>
+
+Since each internal hashing round is inter-dependent on the outputs of other rounds, their memory cannot be isolated. As a result, it is expected that a single RandomHash round cannot be decomposed into parallelizable sub-code-blocks. Thus a single code-block loaded into a module will need to contain 16 hashing algoriths, 14 decisions and 14 branches, quite inefficient for a GPU.
+
+Overall, a GPU implementation of RandomHash may still be faster than an CPU implementation, but not by orders of magnitude as is observed in standard cryptocurrency hashing algorithms. 
+
+**An additional step of memory-hardness can also be added if necessary (TBD) in order to further constrict GPU performance** (TBD)
+
+### ASIC Resistance 
+
+ASIC-resistance is fundamentally achieved on a cost-benefit-analysis 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 large number of hashing-paths outlined above, an ASIC implementation will inevitable result in a very high number of cells and inter-connections between them, resulting in poor performance. It is expected that since the costs to develop will far exceed the ROI, no rational economic actor will undertake ASIC development of RandomHash.
+
+### Hard-Fork Activation
+
+- Community nominates block X for hard-fork activation by consensus
+- On and after block X, block header is hashed using RandomHash
+- Before block X, block header is hashed using current SHA2-256D
+
+## Rationale
+
+Aside from a hash algorithm change, the only other known option to resolve 99% mining centralisation is to encourage other large Ethereum mining pools to also dual-mine PascalCoin. Even if this were achieved, it would still price-out ordinary pools and solo-miners, which is undesirable. Efforts to encourage other dual-miners were undertaking by the developers and community and have failed. As a result, this option is no longer considered viable. Changing the hash algorithm is now the only known option to resolve centralisation.
+
+Within the scope of changing hash algorithm, other possible hash algorithms like Equihash were considered. However, these were ruled out due to their excessive memory consumption contradicting. PascalCoin's requirements to run on low-end hardware without voluminous amounts of ast memory available to validate block hashes.
+
+## Backwards Compatibility
+
+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
+
+TBD
+ 
+## Links
+
+TBD

PIP/README.md

@@ -15,4 +15,5 @@ If they wish to continue, copy [this template](PIP-template.md) and ensure your
 | [6](PIP-0006.md)      | Salvage orphaned transactions            | Herman Schoenfeld              | Protocol       | Active   |
 | [7](PIP-0007.md)      | New Wallet GUI                           | Herman Schoenfeld              | Front-End      | Draft    |
 | [8](PIP-0008.md)      | Hook(s) to start external programs       | Preben Björn Biermann Madsen   | Backend        | Draft    |
+| [9](PIP-0009.md)      | RandomHash: GPU & ASIC Resistant Hash Algorithm | Herman Schoenfeld              | Protocol       | Draft    |