Merge upstream

PIP/PIP-0009.md

@@ -5,128 +5,332 @@
   Impact: Hard-Fork
   Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
   Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0009)
-  Status: Draft
+  Status: Proposed
   Created: 2017-12-17
+  Updated: 2017-12-29 (rev2), 2018-01-01 (typos), 2018-02-06 (rev3)
 </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.
+A GPU and ASIC resistant hashing algorithm change is proposed in order to resolve the current mining centralization situation and to prevent future dual-mining centralization.
 
 ## 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. 
+PascalCoin is currently experiencing 99% mining centralization by a single pool which has severely impacted ecosystem growth and adoption. Exchanges are reticent to list PASC due to the risk of double-spend attacks and infrastructure providers are reticent to invest further 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.
+PascalCoin is a 100% original Proof-of-Work coin offering a unique value proposition focused on scalability. After the initial launch, a healthy decentralized mining community emerged and became active in the coins ecosystem, as expected. However, after 9 months a single pool (herein referred to as Pool-X) managed to centralize 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 centralization occurred, 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.**
+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 having 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 unprofitable thus forcing out ordinary miners who are not dual-mining. 
 
+**These mis-aligned economic incentives result in a rapid convergence to 99% centralization, 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.
+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 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
 
-- 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
+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 round ```x-1```
+4. The input at round x depends on round ```x-1``` **of a different nonce** determined based on the output from round ```x-1``` for the current nonce
+5. The input at round ```x``` is a compression of the outputs of every contributing stage to ```100 bytes```
+6. The output of every round is expanded for memory-hardness
+7. Randomness is generated using ```Mersenne Twister``` algorithm
+8. Randomness is seeded via ```MurMur3``` checksum of previous round
+9. The final round is then hashed again via ```SHA2_256```, in keeping with traditional cryptocurrency approaches.
 
+### RandomHash Design
 
+![Random Hash Design](resources/PIP-0009/randomhash.png)
+ 
 ### RandomHash pseudo-code
+```pascal
+    const
+        HASH_ALGO = [
+            SHA2_256
+            SHA2_384
+            SHA2_512
+            SHA3,
+            RIPEMD160,
+            RIPEMD256,
+            RIPEMD320,
+            Blake2b, 
+            Blake2s,
+            Tiger2,
+            Snerfu,
+            Grindahl512,
+            Haval,
+            MD5
+            RadioGatun32
+            Whirlpool
+        ]
+        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
+            let AllOutputs = RandomHash( blockHeader, N)
+            seed = Checksum(neighborOutputs[Length(AllOutputs) - 1])
+            Result := SHA2_256( Compress(AllOutputs, RandomNumberGenerator(seed)) )
+        end
+
+        Function RandomHash(blockHeader : ByteArray, Round : Integer) : list of ByteArray
+        begin
+            let RoundOutputs = list of ByteArray;
+            
+            if Round = 1 then
+                let seed = Checksum(blockHeader)      // can hash blockHeader first, but not required
+                let gen = RandomNumberGenerator(seed)
+                let input = blockHeader
+            else
+                let parentOutputs = RandomHash(blockHeader, Round - 1)
+                RoundOutputs.addAll(parentOutputs)
+                let seed = Checksum(neighborOutputs[Length(neighborOutputs) - 1])
+                let gen = RandomNumberGenerator(seed)
+                
+                let otherNonceHeader = ChangeNonce(blockHeader, gen.NextDWord)
+                let neighborOutputs = RandomHash(blockHeader, Round - 1)
+                RoundOutputs.addAll(neighborOutput)
+                
+                // re-seed RNG based on random other nonce output
+                seed = Checksum(neighborOutputs[Length(neighborOutputs) - 1])
+                gen = RandomNumberGenerator(seed)
+                let input = Compress(RoundOutputs, gen)
+            
+            let hashFunc = HASH_ALGO[gen.NextDWord % 16]   
+            let output = hashFunc(input)                
+            output = Expand( output, N - i, gen )
+            RoundOutputs.add(output)
+
+            Result := RoundOutputs
+        end
+
+
+        function Expand(input : ByteArray, ExpansionFactor : Integer, gen : RandomNumberGenerator) : ByteArray
+        begin
+            let Size = Length(input) + ExpansionFactor*M;
+            let output = input.Clone
+            let bytesToAdd = Size - Length(input)
+            while output < Size do
+                let nextChunk = output.Clone
+                if Length(output) + Length(nextChunk) > Size then
+                    SetLength(nextChunk, Size - Length(output))
+
+                let random = gen.NextDWord
+                case random % 8 do
+                    0: output = output ++ MemTransform1(nextChunk)
+                    1: output = output ++ MemTransform2(nextChunk)
+                                .
+                                .
+                                .
+                    7: output = output ++ MemTransform8(nextChunk)
+
+            Result = output
+        end
+
+        function Compress(inputs : list of ByteArray, gen : RandomNumberGenerator) : ByteArray
+        begin
+            let output = Byte[0..99]
 
-        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;
+            for i = 0 to 99 do
+                let source = inputs[ gen.NextDWord % Length(inputs) ]
+                output[i] = source[ gen.NextDWord % Length(source) ]
+
+            Result := output
+        end 
+
+        function ChangeNonce(blockHeader : ByteArray, nonce : Integer) : ByteArray
+        begin
+            // changes nonce in blockHeader by knowing offset of nonce
+        end
+
+
+        Function Checksum(input : ByteArray) : DWord
         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]
+            // standard MurMu3 algorithm
+        end
+
+        Function RandomNumberGenerator(seed : DWord) : TMersenneTwister
+            // standard Mersenne Twister random number generator (or other suitably chosen algorithm)
         end;
+```
 
+#### Memory transform methods
 
-### GPU Resistance 
+These methods are iteratively and randomly applied to a hash output in order to rapidly expand it for compression in the next round
+```
+     - Method 1: No-Op         (e.g. input = 123456   output = 123456)
+     - Method 2: Swap-LR       (e.g. input = 123456   output = 456123)   
+     - Method 3: Reverse       (e.g. input = 123456   output = 654321)  
+     - Method 4: L-Interleave  (e.g. input = 123456   output = 142536)
+     - Method 5: R-Interleave  (e.g. input = 123456   output = 415263)
+     - Method 6: L-XOR         (e.g. input = 123456   output = XOR(1,2), XOR(3,4), XOR(5,6), XOR(1,6), XOR(2,5), XOR(3,4)
+     - Method 7: ROL-ladder    (e.g. input = ABCDEF   output = ROL(A, 0), ROL(B, 1), ... , ROL(F, 5)
+     - Method 8: ROR-ladder    (e.g. input = ABCDEF   output = ROR(A, 0), ROR(B, 1), ... , ROR(F, 5)
+```
 
-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. 
+### RandomHash Analysis
 
-In particular, the hash-path taken by a single RandomHash trial varies for every input and is not known until the path is finished.
+#### CPU Bias
 
-<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>
+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
+
+RandomHash is memory-light in order to support low-end hardware.  A CPU will only need 1MB of memory to verify a hash. During mining, it will need 2MB (if it intends to utilize 50% bias mentioned above) - an easy requirement. It's important to note that RandomHash consumes most of the memory in the initial rounds and little in the final rounds. This is deliberate in order to hinder GPU mining.  For example, suppose a GPU has 1GB of memory. A naive hasher could attempt to batch 1000 nonces since each nonce only requires 1MB. However, since each nonce depends on 15 other nonces and most of the 1MB is consumed in the early rounds, the GPU will run out of memory quickly. The batch size needs to be divided by 15 in order to utilize 1GB which  means most of the GPU memory is wasted partial-nonce calculations. The GPU could only effectively compute 100 nonces per 1GB. Note, a CPU could easily compete with this memory requirement and implement intelligent parallel mining (by using other threads to mine less-partially calculated nonces). This would give a CPU >> 50% advantange, but needs further research.
+
+#### GPU Resistance 
+
+GPU performance is generally driven by parallel execution of identical non-branching code-blocks across private regions of memory. Due to the inter-dependence between hashing rounds, the slower global memory will need to be used. Also, due to the highly serial nature of RandomHash's algorithm, GPU implementations will be inherently inefficient. In addition, the use of Mersenne Twister to generate random numbers and the use of recursion will result in executive decision making further degrading GPU performance.  Most importantly, since nonce's are inter-dependent on other random nonces, attempts to buffer many nonces for batch hashing will result in high memory-wastage and 200% more work than a CPU. This occurs because each buffered nonce will require calculation of many other unbuffered dependent nonces, rapidly consuming the available memory. A CPU implementation does not suffer this since the optimal nonce-set to mine is enumerated on-the-fly as each nonce completes. Another important feature is the pattern of memory expansion factors chosen for each round. These were deliberately chosen to hinder GPUs by amplifying the memory needed for their wasted calculations.
+
+As a result, it's expected that GPU performance will at best never exceed CPU performance or at worst perform only linearly better (not exponentially as is the case now with SHA2-256D).
+
+#### 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, expansion and contraction, an ASIC implementation will inevitably result in densr and 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" wihtin 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 cryptographically secure general-purpose, albeit slow, secure hasher.
+
+It is also possible to change the dependence graph between nonces for stronger CPU bias. For example, requiring the lower rounds to depend on more than one nonce and the upper rounds on no nonces at all, may allow further CPU vs GPU optimization. Similarly, for memory expansion factors.
+
+Extra, albeit unnecessary, strengethening can be added in the initial rounds of hashing by using the hash of the blockheader for seeding, instead of the blockheader itself. In the analysis of the author, this is unnecessary and has subsequently been removed.
+
+### Formal Proofs
+
+This section proves some of the claims made in this PIP. 
+
+Let ```N``` = the number of rounds required to complete a single RandomHash
+
+Let ```M``` = the memory unit to expand out a hash's output by
 
-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. 
+#### Hash Complexity
 
-**An additional step of memory-hardness can also be added if necessary (TBD) in order to further constrict GPU performance** (TBD)
+Let ```F(x)``` denote number of hashes required at round ```x```.
 
-### ASIC Resistance 
+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
+```
+    F(x) = 1 + F(x-1) + F(x-1)  
+```
+
+**NOTE** 
+The dependence on a previous random round 1..x-1 is omitted above since it's computationally inconsequential as this is always know for all x. It's only a salt needed to prevent certain GPU optimizations, and does not change the number of hashes in ```F```. 
+
+Simplifying
+```
+    F(x) = 1 + 2 F(x-1) 
+         = 1 + 2(1 + 2 F(x-2)) 
+         = 1 + 2^1 + 2^2 + 2^3 + ... + 2^(x-1)
+         = SUM(i=0, x-1) 2^i
+         = 2^x - 1
+```
+
+Thus
+```
+    F(x) = 2^x - 1
+```
+
+#### Memory Consumption
+
+Let ```G(N)``` denote the minimum amount of memory required for a RandomHash of a single nonce. Here ```N``` denotes the number of rounds required in RandomHash.
+
+Firstly, after a full RandomHash involving ```N``` rounds, the total count of hashes at any round ```x``` is
+```
+    TotalHashesAtRound(x) = 2^(N-x)     
+```
+
+**NOTE**: Use above [diagram](#randomhash-design) to visualize and understand this. 
+ - pick any row ```x```
+ - count horizontally 
+ - 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 decreases every subsequent 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)
+         = 2^N (N-2) + 2
+```
+
+Thus,
+```
+    G(N) = 2^N (N-2) + 2
+```
+
+**NOTE**: For PascalCoin, ```N=5``` which results ```98``` units of memory for every single nonce. Choosing memory unit ```M=10kb``` results in approximately ```1MB``` per nonce. 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 complete a single nonce 
+ - After the completion of any nonce, another nonce is known and pre-computed to round ```N-1```
+ - For serial mining (CPU), almost all nonce hashing are simply the resumption of a previous pre-computed nonce to ```N-1```. Thus it only does ```F(N-1)``` the work.  
+ - For parallel mining (GPU), all the work ```F(N)``` must be performed for every nonce.
+
+Thus the work a CPU does is
+ 
+    CPU Work = F(N-1) 
+             = 2^(n-1) - 1
+
+However GPU does the entire work for every nonce
+
+    GPU Work = F(N)
+             = 2^n - 1
+
+The efficiency is 
+
+    Efficiency = (CPU Work) / (GPU Work)
+               = (2^(N-1)-1) / (2^N - 1)
+
+Taking the limit as N approaches +inf
+                = 0.5
+
+Thus a CPU does 50% the work of a GPU.
 
-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
+The PIP requires a hard-fork activation involving various aspects discussed below.
+
+#### Consensus
+
+Since this is a significant change, the PascalCoin community will be asked to vote on this proposal by changing their account types to numbers which correspond to YES or NO votes respectively. All other numbers will be considered ABSTAIN. The total PASC and PASA will be tallied.
+
+    Example:
+        Account 9876-54 with 0 PASC is considered 1 votes
+        Account 1234-56 with 100 PASC is considered 101 votes
+
+#### Implementation
+
+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 the ecosystem to adopt this mandatory upgrade. A release will be made and notifications provided of activation within the time-frame.
+
+#### Difficulty Reset
+
+On activation, the block difficulty will be reset to an appropriately low number. During this period, the block times will be highly unstable but will stabilize over approximately 200 blocks. Exchanges are recommended to pause deposits and withdrawals 1 hour before activation and 10 hours after.
 
 ## 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.
+Aside from a hash algorithm change, the only other known option to resolve 99% mining centralization is to encourage other large Ethereum mining pools to duplicate Pool-X's features thus incentivizing decentralized ETH-PASC dual-mining. Even if this were achieved, it would still price-out ordinary PASC-pools and solo-miners, which is undesirable. It would also fundamentally link the two ecosystems together for no good reason. Efforts to encourage other dual-miners were undertaken but have failed. As a result, this option is no longer considered viable. Changing the hash algorithm is now the only known option to resolve this centralization.
 
-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.
+Within the scope of changing the hash algorithm, other hash algorithms were considered like Equihash. However, these were ruled out due to their excessive memory consumption contradicting PascalCoin's vision of globally decentralized network that runs fine on low-end hardware available anywhere on this world. Requiring voluminous amounts of fast memory to validate blocks is not consistent with this vision.
 
 ## Backwards Compatibility
 
@@ -134,8 +338,15 @@ This PIP is not backwards compatible and requires a hard-fork activation. Previo
  
 ## Reference Implementation
 
-TBD
+A reference implementation will be provided in the coming weeks.
+ 
+## Acknowledgements
+Refinements to improve GPU-hardness were provided by Ian Muldoon.
  
 ## Links
 
-TBD
+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 

PIP/PIP-0010.md

@@ -0,0 +1,115 @@
+<pre>
+  PIP: PIP-0010
+  Title: 50% Inflation Reduction
+  Type: Protocol
+  Impact: Hard-Fork
+  Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
+  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0010)
+  Status: Proposed
+  Created: 2018-01-01
+</pre>
+
+## Summary
+
+A 50% reduction in the PASC inflation schedule is proposed. This change can be introduced immediately by changing a single line-of-code and with unnoticeable impact to existing infrastructure.
+
+## Motivation
+
+Due to the negative impact arising from mining centralization, PascalCoin has experienced stunted adoption. By some estimates, PascalCoin's user-base is half the size it would have been without this centralization. It follows from Metcalf's law that the PASC price is subsequently 25% of what it would have been without the centralization.  This PIP intends to compensate the existing ecosystem for the damage it has incurred. Additionally, and in combination with other [PIPs][1] that resolve the centralization, this change intends to re-ignite the interest in PascalCoin's technology present prior to the centralization. 
+
+## Specification
+
+PASC is currently issued into existence as miner rewards at a rate of 100 per block. After four years (an epoch), this reward is halved. This 4-year halving cycle repeats until a minimum of 1 PASC is rewarded in perpetuity for every minted block (tail-emission). The proposal here is to change the epoch period from four years to two resulting in a 50% inflation reduction with virtually unnoticeable impact to the ecosystem and the code-base.
+
+### Code Changes
+
+Change constant
+```pascal
+    CT_NewLineRewardDecrease: Cardinal = 420480;
+```
+
+to
+```pascal
+    CT_NewLineRewardDecrease: Cardinal = 210240;
+```
+
+No other changes will be required if this is activated **on or before** block 210240.
+
+
+### Formal Proofs
+
+Definitions
+```
+    let InitialReward = the initial miner reward (100)
+    let BlocksPerEpoch = the number of blocks minted before reward halves (currently 420480 which is ~4 years)
+    let TailEmission = the minimum reward per block
+```
+
+The determine the epoch a random block ```x``` belongs to, use this equation
+```
+(1)    let Epoch(x) = x div BlocksPerEpoch
+```
+
+noting that the first epoch is 0, the second 1 and so on.
+
+To calculate the reward for block x (prior to tail emission), the following equation can be used
+```
+(2)    let BlockReward(x) = InitialReward / 2^Epoch(x)
+```
+
+Since tail-emission begins on the first block ```y``` such that ```BlockReward(y) < 1```, the general form of (2) becomes
+```
+(3)     BlockReward(x) = MAX( InitialReward / 2^Epoch(x), TailEmission)
+```
+
+To calculate the last epoch before tail emission begins, use
+```
+(4)     LastEpoch = FLOOR( LOG2( BlockReward ) )
+```
+
+To calculate the block number where tail emission starts
+```
+(5)     TailStart = (LastEpoch + 1) * BlocksPerEpoch
+```
+
+To measure the supply up and until tail emission
+```
+(6)     TotalSupply = SUM(i=0..LastEpoch) InitialReward / 2^i * BlocksPerEpoch
+```
+
+For the current protocol,
+```
+    InitialReward = 100
+    BlocksPerEpoch = 420480   ; ~4 years
+    LastEpoch = 6
+    Total Supply = 83,439,000
+```
+
+For the new protocol (assuming this change activated in epoch 0),
+```
+    InitialReward = 100
+    BlocksPerEpoch = 210240  ; ~2 years
+    LastEpoch = 6
+    Total Supply = 41,719,500
+```
+
+The inflation change is thus
+```
+    (New Total Supply) / (Old Total Supply)
+```
+
+which equals 50%. 
+
+## Rationale
+
+Other approaches to modify inflation were considered but deemed undesirable due the alteration of consensus rules which have already transformed/validated existing data on Blockchain and SafeBox. Such approaches would burden future protocol implementations with the legacy inflation algorithm which would be needed to validate existing data. The proposed approach avoids such complications and is the simplest most elegant solution.
+
+## Backwards Compatibility
+
+Despite requiring a hard-fork activation, this change is low-impact and unnoticeable to the ecosystem at large since the PascalCoin network is till minting blocks in epoch 0 (and will continue to for approximately 5 months). The effects of this proposal will emerge on and after epoch 1 (block 210241). It is the view of the author that if a change to the inflation schedule is made, it should made within epoch 0 or never at all. 
+
+## Links
+
+1. [PIP-0009 RandomHash: GPU & ASIC Resistant Hash Algorithm][1]
+
+[1]: https://github.com/PascalCoin/PascalCoin/blob/master/PIP/PIP-0009.md

PIP/PIP-0011.md

@@ -0,0 +1,84 @@
+<pre>
+  PIP: PIP-0011
+  Title: 20% Developer Reward
+  Type: Protocol
+  Impact: Hard-Fork
+  Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
+  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0011)
+  Status: Proposed
+  Created: 2018-01-02
+</pre>
+
+## Summary
+
+It is proposed that 20% of the block-reward be portioned and allocated to the developers for the purposes of rapidly delivering the roadmap and supporting the project at large. The funding can be used for layer-1 protocol development, layer-2 development, anonymity R&D and implementation, marketing, infrastructure support and exchange listings. In practice, budgets will be proposed by and voted on by the community itself.
+
+## Motivation
+
+With the recent addition of well-funded ICOs into the cryptocurrency sector, it has become necessary to rely on commercial time and material in order to realistically compete for adoption. By introducing a developer reward, funds can be provisioned for all aspects of the PascalCoin project including much needed exchange listings. This concept has already been successfully pioneered by other cryptocurrencies such DASH and DCR and is expected to significantly boost the current PascalCoin ecosystem size and value. As a result, even though miners will earn 20% less, the capital gain of the remaining 80% is expected to exponentially exceed the value they would otherwise have, which is fair compensation. Another major benefit is the ability for the developers to dispense accounts to new users in order to facilitate smooth adoption.
+
+## Specification
+
+PascalCoin block rewards comprise of 5 new accounts awarded to the miner with the first containing the PASC reward. It is proposed that account 5 be instead awarded to the developers, and the PASC reward be split 80% - 20% respectively.
+
+### SafeBox transaction rule change
+
+In the current protocol, when PascalCoin encounters a valid block X, a corresponding Account Segment X is appended to the SafeBox structured as follows:
+
+**Account Segment X**
+```
+[Header]
+[Account No: X+0, Key: Block.MinerKey, Balance: BLOCKREWARD]
+[Account No: X+1, Key: Block.MinerKey, Balance: 0]
+[Account No: X+2, Key: Block.MinerKey, Balance: 0]
+[Account No: X+3, Key: Block.MinerKey, Balance: 0]
+[Account No: X+4, Key: Block.MinerKey, Balance: 0]
+```
+
+It is proposed that after activation, Account Segments be structured as follows:
+
+**Account Segment X**
+```
+[Header]
+[Account No: X+0, Key: Block.MinerKey, Balance: ROUND(BLOCKREWARD * 0.8, 4-decimal-places)]
+[Account No: X+1, Key: Block.MinerKey, Balance: 0]
+[Account No: X+2, Key: Block.MinerKey, Balance: 0]
+[Account No: X+3, Key: Block.MinerKey, Balance: 0]
+[Account No: X+4, Key: SafeBox.Account[0].Key, Balance: ROUND(BLOCKREWARD * 0.2, 4-decimal-places)]
+```
+
+**NOTE**: the developer key is simply attained by copying the key from account ```0-10```.
+
+No other changes are required. 
+
+## Social Contract
+
+As part of this proposal, the developers are committed to openness and engagement with the community with respect to allocation of these funds. During a financial quarter, the following work-flow will be executed:
+1. Developers (and community) propose budgets at any time during the quarter
+2. Users vote on budget proposals at any time during the quarter
+3. On first day of the next quarter, the current majority-voted budget is adopted for the quarter
+4. Goto 1
+
+Users will be able to vote on proposals by simply changing their Account.Type to the corresponding budget number. The total PASC and PASA will be tallied as follows:
+```
+1 PASC = 1 VOTE
+1 PASA = 5 VOTES
+```
+
+## Rationale
+
+Other developer reward approaches were considered but deemed undesirable since the proposed approach is the simplest and most elegant. For example, it is possible to hard-code the developer key instead of copying it from 0-10, but this introduces high-risk attack vectors. By copying the key, developers can ensure cold-wallet security at all times. Also, the reward mechanism could have been a new Operation type, but this would require much more development which adds hard-fork risk, for little gain. The current approach is easy and low-impact since it technically does not require new consensus rules. Consensus is achieved simply by the fact that if a node does not implement the above rule, it's subsequent SafeBox hash will be totally out-of-consensus with the majority network.
+
+## Backwards Compatibility
+
+This proposal is not backwards compatible and requires a hard-fork activation.
+
+## Acknowledgements
+
+Thanks to Dr. Muhammad Amer for providing [projection estimates][1]
+
+## Links
+
+1. [Excel developer reward projections for various models][1]
+
+[1]: resources/PIP-0011/projection.xlsx

PIP/PIP-0012.md

@@ -0,0 +1,53 @@
+<pre>
+  PIP: PIP-0012
+  Title: Change account recovery to 10 years
+  Type: Protocol
+  Impact: Hard-Fork
+  Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
+  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0012)
+  Status: Proposed
+  Created: 2018-01-03
+</pre>
+
+## Summary
+
+It is proposed that the RECOVER operation be changed from 4 years to 10 and to include the account itself in the recovery.
+
+## Motivation
+
+Coinrot is a serious economic issue afflicting almost all other cryptocurrencies. Coinrot is the phenomenon of coins being permanently lost due to lost/corrupted keys and/or natural death. It is estimated that 20% of Bitcoins have already rotted. PascalCoin solves this problem by allowing PASC to be transferred from an account, without owners signature, after an inactivity period of 4 years. Whilst this is a good start, it does not solve the problem of PASA-rot, which is a far more limited (and important) resource than PASC. Also, community has expressed discomfort with the 4 year period, pointing out long-term savers could be seriously afflicted.
+
+## Specification
+
+The proposal here is to simply to change RECOVER operation inactivity period from 4 years to 10 **and** to simply update the key of the recovered account rather than transferring it's balance. This allows both the PASA and PASC to be recovered in a single operation, with minimal code changes.
+
+### Definitions 
+
+let RecoverOperation denote the recovery operation.
+
+let RecoverOperation.InactiveAccount denote the account being recovered
+
+let RecoverOperation.NewOwnerAccount denote the destination account to transfer the recovered PASC to.
+
+### Current Algorithm
+
+1. Verify RecoverOperation in similar way to TRANSACTION operations
+2. Verify ( SafeBox.LastBlockNumber - SafeBox.Accounts[ RecoverOperation.InactiveAccount].LastUpdatedBlock ) >= 420480
+3. Transfer balance from RecoverOperation.InactiveAccount to RecoverOperation.NewOwnerAccount
+
+### Proposed Algorithm
+
+let RecoverOperation.NewOwnerKey denote the new owners account key.
+
+1. Verify RecoverOperation in similar manner to CHANGE KEY operation
+2. Verify ( SafeBox.LastBlockNumber - SafeBox.Accounts[ RecoverOperation.InactiveAccount ].LastUpdatedBlock ) >= 1051200 
+3. Change key of InactiveAccount to RecoverOperation.NewOwnerKey
+
+
+## Rationale
+
+Other approaches were considered such as allowing partial recovery of funds every sub-period. For example, allowing 10% of the balance to be recovered every 2 weeks, after 4 years of inactivity. All such approaches were significantly more complicated and required much more development, which adds hard-fork risk (especially when combined with other PIPs in V3 release). As a result, the simplest most elegant solution was chosen.
+
+## Backwards Compatibility
+
+This proposal is not backwards compatible and requires a hard-fork activation. However, since PascalCoin has not been around for 4 years, the old RECOVER algorithm can safely be discarded from the protocol.

PIP/PIP-0013.md

@@ -0,0 +1,85 @@
+<pre>
+  PIP: PIP-0013
+  Title: Allow nodes to pull pending operations
+  Type: Protocol
+  Impact: Soft-Fork
+  Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
+  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0013)
+  Status: Proposed
+  Created: 2018-01-03
+</pre>
+
+## Summary
+
+A new network operation called NET_OP_PULL_PENDING is proposed that allows nodes to pull some or all of the pending operations from other connected peers.
+
+## Motivation
+
+Currently a node receives new operations as they flood-fill the network when created and during block propagation. Whilst this is extremely efficient, if a node restarts it loses the current pending pool and is required to wait until the next block in order to become aware of pending/minted operations. This situation can lead to out-of-sequence N_OPERATION errors since a node can forget the correct N_OPERATION of an owned account due to recent pending operations it lost during the resetart. This has led to withdrawal failures at exchanges from Poloniex, a serious user-experience issue.  Whilst this can be mitigated client-side by persisting the pending pool, a comprehensive solution is proposed here. The proposal also benefits mobile and light-clients by allowing them to poll peers for pending operations, as well as other layer-2 scenarios.
+
+## Specification
+
+The proposal here is to add a new network operation. 
+
+### NET_OP_PULL_PENDING
+
+**Arguments** 
+- N : DWord  - the number of parameter keys in parameters  
+- KeyHash_1 : Bytes[20] - the RIPEMD160 of the first key
+
+  .
+  .
+  .
+ 
+- KeyHash_N : Bytes[20] - the RIPEMD160 hash of the N'th key
+
+**Output**
+- M : DWord - the number of pending operations being returned
+- OP_1_SIZE : DWord - the byte length of OP_1
+- OP_1 - ByteArray[OP_1_SIZE] - the first pending operation
+
+  .
+  .
+  .
+ 
+- OP_M_SIZE : DWord - the byte length of OP_M
+- OP_M - ByteArray[OP_M_SIZE] - the M'th pending operation
+
+**PSEUDO-CODE**
+```pascal
+let output = list of operations 
+if N = 0 then
+  output = PendingPool
+else
+   for all O in PendingPool
+     for all k in (Argument Keys)
+       let senderAccount = SafeBox.Accounts[O.Sender]
+       let receiverAccount = SafeBox.Accounts[O.Receiver]
+       let feePayerAccount = SafeBox.Accounts[O.Signer]
+       
+       if RIPEMD160(senderAccount.Key) = k OR RIPEMD160(receiverAccount.Key) = k OR RIPEMD160(feePayerAccount.Key) = k then
+         output.Add(O)
+       else
+          if O is ChangeKeyOperation AND RIPEMD160(O.NewKey) = k then
+            output.Add(O)
+          else if O is BuyAccountOperation and RIPEMD160(O.NewKey) = k then
+            output.Add(O)
+           else ....
+            
+return FORMAT(output)
+```
+
+**NOTE** the above pseudo-code is only a guide and actual implementation will more scenarios. It is left to the implementor to determine all the scenarios correctly. Errors in implementation will never result in out-of-consensus issues, since this is a non-critical network operation.
+ 
+### DoS Protection
+
+Since this network operation could be used to DoS a peer, peers should include the following protection:
+- If 2 NET_OP_PULL_PENDING is received from the **same peer** within 5 seconds, blacklist that peer.
+
+## Rationale
+
+Other approaches were considered involving Bloom Filtering and bit-vectors, but these changes cannot be introduced within the V3 timeline. The above proposal is elegant and simple to implement, and achieves the job until later date. Argument keys are hashed for network efficiency, which is paid for client-side computationally. This is why DoS protection is necessary for this network operation. 
+
+## Backwards Compatibility
+
+This proposal is backwards compatible and can be introduced as a soft-fork.

PIP/PIP-0014.md

@@ -0,0 +1,72 @@
+<pre>
+   PIP: PIP-0014
+   Title: New operation to certify accounts for extended recovery period
+   Type: Protocol
+   Impact: Hard-Fork
+   Author: Dr. Muhammad Amer <i>&lt;[email protected]&gt;</i>
+   Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0014)
+   Status: Proposed
+   Created: 2018-01-04
+ </pre>
+ 
+ ## Summary
+ 
+It is proposed to pay a fee to the development fund by an account holder in order to keep the account active for an extended period of time (20 years). 
+ 
+ ## Motivation
+ 
+ Coinrot is a serious economic issue afflicting almost all other cryptocurrencies. Coinrot is the phenomenon of coins being permanently lost due to lost/corrupted keys and/or natural death. It is estimated that 20% of Bitcoins have already rotted. PascalCoin solves this problem by allowing PASC to be transferred from an account, without owners signature, after an inactivity period of 4 years. Although this solves the coinrot problem at the same time many users want to keep PascalCoin in their wallet for longer period of time without fear of forgetting to do transaction and losing funds within these 4 years. Community has expressed discomfort over this as funds cannot be saved for longer period of time.
+ 
+ ## Specification
+
+A new operation called Certify Account is proposed which allows an account to prevent recovery for 20 years and which pays 1 PASC to account 0-10.
+
+### New Operation: CERTIFY ACCOUNT
+
+This operation will be composed of the following fields:
+
+- **Account**: the account which is to be certified
+- **Fee**: the network fee paid to miner
+- **Developer Fee**: the fee to pay developers
+- **Signer**: the account which pays both fees
+- **Signature**: ECDSA signature of entire operation
+
+**Consensus Rules**
+- The Developer Fee must equal 1 PASC
+- The Signer Account balance must greater than or equal to (Fee + Developer Fee)
+- The public keys for Signer Account and Account must be identical
+- The Signature must be well-formed ECDSA signature verifiable using Signer Account's public key
+
+**Mutation Rules**
+- Account.State is changed to new state called ```CERTIFIED```
+- Account.LockedUntilBlock field is changed to ```CURRENT BLOCK NUMBER + 2102400```, which is 20 years from the date minted into a block.
+- The Developer Fee is transferred from Signer Account to account 0-10
+
+### Update Operation: RECOVER ACCOUNT
+
+In order to support Certified Accounts, the RECOVER ACCOUNT operation must add the following consensus rule:
+
+```pascal
+If (Account.State = CERTIFIED) AND (CURRENT_BLOCK_NUMBER >= Account.LockedUntilBlock) then
+   // proceed to next step of existing RECOVER ACCOUNT consensus rules
+else 
+   Error('Cannot RECOVER an unexpired certified account')
+```
+
+ ## Rationale
+ 
+As there is already a [PIP][1] in place to extend the recover operation from 4 years to 10, by adopting this PIP, the user can also make an informed decision to get his account maintained for longer period of time without fear of losing funds and account. The fee will be paid to Developer Fund which will be beneficial for the growth of PascalCoin.
+ 
+ ## Backwards Compatibility
+ 
+ This proposal is not backwards compatible and requires a hard-fork activation. 
+ 
+ ## Acknowledgements
+
+ The technical specification was provided by Herman Schoenfeld based on the concepts provided in this PIP.
+ 
+## Links
+
+1. [PIP-0012: Change account recovery to 10 years][1]
+
+[1]: https://github.com/PascalCoin/PascalCoin/blob/master/PIP/PIP-0012.md

PIP/PIP-0015.md

@@ -0,0 +1,120 @@
+<pre>
+  PIP: PIP-0015
+  Title: Fast Block Propagation
+  Type: Protocol
+  Impact: Soft-Fork
+  Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
+  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0015)
+  Status: Proposed
+  Created: 2018-01-04
+</pre>
+
+## Summary
+
+A method to rapidly propagate blocks is proposed in order to minimize orphan rates. It involves propagating a block skeleton rather than the full block, reducing network traffic by 95%. Nodes can rebuild the full block by plugging operations from the Pending Pool into the skeleton.
+
+## Motivation
+
+Due to slow block propagation and expensive SafeBox rollbacks, PascalCoin tends to experience high orphan rates when mining community becomes highly decentralized. Due to the current centralization, this has not been noticable. However, once decentralization is resolved [as has been proposed][1], this issue will re-emerge. As a result, a solution is required in combination with centralization resolution.
+
+## Specification
+
+### Block Propagation Change
+
+Currently, when a peer is notified of a new block the entire block is sent. In this proposal only a Block Skeleton is sent, structured as follows: 
+
+### Block Skeleton
+
+```
+[BLOCK HEADER]  (~200 bytes)
+[NUM OPERATIONS] (4 bytes)
+[OP_REF_1] (8 bytes)
+....
+[OP_REF_N] (8 bytes)
+```
+
+The skeleton does not contain full operation data, only a reference to the operation. The reference is a 64bit value composed of the ```AccountNumber``` and the ```N_OPERATION``` of the account authoring the operation.
+
+```pascal
+function GetOpRef(operation : Operation) : QWord
+begin
+  let accountNumber = operation.Account
+  let n_operation = operation.n_operation
+  Result = (QWord(accountNumber) SHL 31) BIT-OR QWord(n_operation))
+end
+```
+
+The concept of OP_REF is already in PascalCon as part of Albert Molina's OPHASH algorithm:
+
+```
+OPHASH = OP_BLOCK_ID ++ OP_REF ++ RIPEMD160(OP_RAW_DATA)
+```
+
+
+### Block Construction From Skeleton
+
+The receiving node is required to rebuild the full block from the skeleton it has received as follows:
+
+```pascal
+Function ReconstructBlock(skeleton : BlockSkeleton) : Block
+begin
+    let missing = List<QWord>.Create
+    let block = Block.Create
+    block.Header = skeleton.Header
+    for i = 0 to skeleton.NumOperations - 1 do
+        let opRef = skeleton.Operations[i]
+        if PendingPool.Contains(opRef) then
+            block.Operations[i] = PendingPool.GetByOpRef(opRef)
+        else
+            missing.Add(opRef)
+
+        if missing.Length > 0 then
+            PendingPool.AddMany( NET_OP_PULL_ACCOUNT_OPS(missing) )
+            Result := ReconstructBlock(skeleton)
+        else
+            Result := block
+end
+
+```
+
+**NOTE** Care must be taken to ensure endianess correctness in OP_REF as done now in PascalCoin OPHASH calculations.
+
+### New Network Operation: NET_OP_PULL_ACCOUNT_OPS
+
+This network operation allows a node to fetch specific operations from other nodes that it does not have. It is used when rebuilding the block from the block skeleton. If the node does not have the operations referenced in the skeleton, it uses this network operation to fetch them from other peers. This operation will be used sparingly since most nodes will already have most of the operations most of the time.
+
+**Arguments**
+- N: DWord - the number of operations being requested
+- OP_REF_1: QWord - the first operation being requested
+
+    .
+    .
+    .
+    
+- OP_REF_N: QWord - the N'th operation being requested
+
+**Output**
+- M: DWord - the number of operations being returned
+- OP_SIZE_1 : DWord - the size of first operation being returned
+- OP_1 : ByteArray[OP_SIZE_1] -- the raw data of first operation being returned
+
+    .
+    .
+    .
+    
+- OP_SIZE_M : DWord - the size of the M'th operation being returned
+- OP_M - the raw data of M'th operation being returned
+
+## Rationale
+
+This provides a 95% reduction in the block data being transmitted increasing propagation efficiency. As a result, orphan rates are expected to proportionally reduce resulting a dramatically less number of orphans. In combination with other PIPs that improve SafeBox rollback efficiency, PascalCoin will be able to seamlessly support CPU-mining such as proposed in [PIP-0009][1].
+
+## Backwards Compatibility
+
+This change is backwards compatible and can be introduced as a soft-fork. 
+ 
+ ## Links
+
+1. [PIP-009: RandomHash: GPU & ASIC Resistant Hash Algorithm][1]
+
+[1]: https://github.com/PascalCoin/PascalCoin/blob/master/PIP/PIP-0009.md

PIP/PIP-0016.md

@@ -0,0 +1,54 @@
+<pre>
+  PIP: PIP-0016
+  Title: Layer-2 protocol support
+  Type: Protocol
+  Impact: Hard-Fork
+  Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
+  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0016)
+  Status: Proposed
+  Created: 2018-01-04
+</pre>
+
+## Summary
+
+A new operation DATA is propose to facilitate data exchange between accounts. This will allow clean enveloping of Layer-2 protocols inside Layer-1 much in the same way HTTP lives inside TCP.
+
+## Motivation
+
+Currently, PascalCoin can facilitate Layer-2 protocols by allowing them to be enveloped within the Layer-1 Transaction operations. This is achieved by using the Payload field inside operations. Whilst this is useful, it has some drawbacks such as requiring double the fee and hard to distinguish between payments and data exchange. Whilst it's possible to send BLOB data over many 256 bytes payloads, it's hard for receiver to sequence these operations since some may payloads may be PASC others part of Layer-2 protocol. As a result, a new operation is required to cleanly support Layer-2 protocol eveloping. As a result, Layer-2 applications can quickly aggregate messages without needing to inspect every payload of every message and ordinary nodes can discard these Data messages after 100 blocks without any further burden.
+
+## Specification
+
+A new operation called DATA is proposed that allows accounts to send data to another account.
+
+### New Operation: DATA
+
+- **ID**: 16 bytes - this is a GUID created by the sender
+- **Type**: Word - this is used by Layer-2 protocol to distinguish different types of messages (i.e. 0 - CHAT MESSAGE, 1 - PRIVATE MESSAGE, 2 - FILE, etc)
+- **Sequence**: this is used by Layer-2 protocol to envelope it's message into many Layer-1 messages, just as HTTP response is enveloped over many TCP messages. 
+- **Account**: this is the account authoring the operation
+- **Destination**: this is the account receiving the operation
+- **Fee**: the network fee payable to miner
+- **Payload**: the 256 byte operation payload containing Layer-2 data
+- **Signer**: this is the signer account which pays the fee
+- **Signature**: ECDSA signature of entire operation
+ 
+**Consensus Rules**
+- The Signer Account balance must greater than or equal to Fee
+- The public keys for Signer Account and Account must be identical
+- The Signature must be well-formed ECDSA signature verifiable using Signer Account's public key
+
+**Mutation Rules**
+- Only the usual N_OPERATION and Fee mutations are made to Account and Signer.
+- Destination account state is **not changed**.
+
+**NOTE**
+It's important to note that this operation only transfers data between accounts, not PASC or PASA. Since nodes delete these operations after 100 blocks, it's up to Layer-2 applications to ensure they are persisted separately. 
+
+## Rationale
+
+As mentioned in Motivation section, enveloping layer-2 protocols inside layer-1 can be achieved without this operation however it introduces many unncessary complexities. Also, by segregating DATA operations from PASC transactions, nodes can quickly filter Layer-2 protocols without expensive introspection of every Transaction.
+
+## Backwards Compatibility
+
+This change is not backwards compatible and requires a hard-fork activation.

PIP/PIP-0017.md

@@ -0,0 +1,135 @@
+<pre>
+  PIP: PIP-0017
+  Title: Anonymity via Transaction Mixing (phase-1)
+  Type: Protocol
+  Impact: Hard-Fork
+  Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
+  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0017)
+  Status: Proposed
+  Created: 2018-01-04
+</pre>
+
+## Summary
+
+A new operation called MULTI-TRANSACTION is proposed that allows a transfer of funds from N accounts to M accounts within in a single operation. This will immediately provide DASH-level anonymity and serve as foundational component for subsequent full anonymity. 
+
+## Motivation
+
+Currently, PascalCoin transactions occur between publically visible accounts. Of all the cryptocurrencies, PascalCoin is the least anonymous. Anonymity is intrinsically connected to fungibility, a crucial aspect of any currency. Without fungibility, adoption will be stunted. This proposal immediately delivers DASH-level anonymity into the protocol, and will allow users to perform:
+
+**Client-Server Mixing**
+
+Use a web-driven mixer UI similar similar to how Bitcoin Cash transactions are mixed today (but not Bitcoin Core, due to high fees).
+
+**Network-protocol Mixing**
+
+As phase-2 of anonymity, the network protocol will be upgraded via soft-fork to support mixing directly between wallet-to-wallet, in a virtually seamless manner as sending a transaction now.
+
+**Chaining Multi-Transactions**
+
+Immediately and improved in phase-2, users will be able to chain multiple Multi-Transactions together delivering indecipherable complexity between transfers.
+
+**Monetized-API Mixing**
+
+As a CPU-mining community arises from [PIP-0009][1], those node operators will be able to earn extra income by running a **Layer-2 node** (similar to a Masternode in DASH), that can participate in totally secure phase-2 anon, among various other Layer-2 applications such as smart-contract and marketplace platforms.
+
+## Specification
+
+A new operation called MULTI-TRANSACTION is proposed as follows:
+
+### New Operation: MULTI-TRANSACTION
+
+- SenderCount: Word - number of sender accounts (N)
+- SenderAccount_1: DWord - first sender account
+- SenderQuantity_1: QWord - amount first sender is sending
+- SenderNOperation: DWord - the new N_OPERATION value of first senders account
+
+    .
+    .
+    .
+
+- SenderAccount_N : DWord - N'th sender account
+- SenderQuantity_N : DWord - amount N'th sender is sending
+- SenderNOperation_N: DWord - the new N_OPERATION value of N'th senders account 
+- RecipientCount: Word - number of recipient accounts (M)
+- RecipientAccount_1: DWord - first recipient account
+- RecipientQuantity_1 : QWord - amount first recipient is receiving
+
+    .
+    .
+    .
+
+- RecipientAccount_M : DWord - M'th recipient
+- RecipientQuantity_M : QWord - amount M'th recipient is receiving
+- SenderFee: network fee payable to miners **per sender**
+- Payload: operation payload
+- SenderSignature_1: signature of first sender
+
+    .
+    .
+    .
+
+- SenderSignature_N: signature of N'th sender
+
+**Consensus Rules**
+- Ensure fee per sender is non-zero
+```
+SenderFee > 0
+```
+
+- Ensure at least 1 sender
+```
+SenderCount > 0
+```
+
+- Ensure at least 1 recipient
+```
+RecipientCount > 0
+```
+
+- Ensure all senders have enough to send and pay fee
+```
+for-all s in Senders 
+    SafeBox.Accounts[s.Account].Balance >= s.Quantity + SenderFee
+```
+
+- Ensure the amount being spent balances the amount being received
+```
+SUM( select Quantity from Senders ) = SUM( select Quantity from Recipients ) + Count( Senders ) * SenderFee
+```
+
+- Ensure the sender N_OPERATION values are correct 
+```
+for-all s in Senders
+    s.NOperation = SafeBox.Accounts[s.Account].NOperation + 1
+```
+
+- Ensure that all senders sign the entire message **except the signature portion**
+```
+let signedPortion = select bytes from (SenderCount...Payload) of Multi-Transaction
+for-all s in Senders    
+    ECDSA_VerifySignature(s.Signature, signedPortion, SafeBox[s.Account].PublicKey) = True 
+```
+
+#### Segregated Signatures during OPHASH ###
+
+In order to allow a sender to know the OPHASH of the Multi-Transaction before the **next sender** signs, it's important that the signature portion of the Multi-Transaction be omitted from the RIPEMD160-portion of the OPHASH calculation
+```
+OPHASH(MultiTransaction) = RIPEMD160 ( select bytes (SenderCount...Payload)  from MultiTransaction ) 
+```
+
+Otherwise it will not be possible for a Sender to determine the OPHASH until it finally reaches a block. This will break high-frequency mixing.
+
+## Rationale
+
+Other methods of anonymity are in development and will either rely or benefit from this proposal. As a result, implementing this PIP delivers an overwhelming gain for virtually zero costs. 
+
+## Backwards Compatibility
+
+This change is not backwards compatible and requires a hard-fork activation.
+
+## Links
+
+1. [PIP-009: RandomHash: GPU & ASIC Resistant Hash Algorithm][1]
+
+[1]: https://github.com/PascalCoin/PascalCoin/blob/master/PIP/PIP-0009.md

PIP/PIP-0018.md

@@ -0,0 +1,54 @@
+<pre>
+  PIP: PIP-0018
+  Title: 10% funding allocation for Lazarus/FPC
+  Type: Process
+  Impact: Funding
+  Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
+  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0018)
+  Status: Proposed
+  Created: 2018-01-05
+</pre>
+
+## Summary
+
+It is proposed that, if and when [PIP-0011: 20% Developer Reward][1] or a variant passes, that a portion of the funding be allocated towards development of [Lazarus/FPC][2] project so that the two ecosystems can mutually-benefit.
+
+## Motivation
+
+If and when [PIP-0011][1] passes, PascalCoin will grow into a multi-billion dollar project yet the base tooling from which it is founded on will remain an under-funded FOSS volunteer project. 
+
+[Lazarus/FPC][2] has made amazing progress with FOSS contributions from unpaid volunteers, however there is a great amount of outstanding work that needs to be completed. Many of these volunteers would be willing to dedicate more time if incentivized monetarily.
+
+## Disbursements
+
+A well-funded PascalCoin Project can sponsor thousands of bounties on Lazarus/FPC, payable on milestone basis, in order to rapidly accelerate the development velocity of [Lazarus/FPC][2]. Also, well-known contributors could be retained by the PascalCoin Project on a time and material basis in order to contribute to Lazarus/FPC and/or PascalCoin.
+
+The PascalCoin Developers could also arrange larger specialized bounties with the Lazarus/FPC leadership team in order to significantly improve the IDE and to provide broader platform support and bug fixes.
+
+A total of 10% of the Developer Rewards is recommended for this funding, however other levels are possible (and will be voted on).
+
+## Rationale
+
+By supporting Lazarus/FPC, the PascalCoin project hitches onto the broader Pascal-world providing an inlet of expertise facilitating a rapid growth of a PascalCoin technical community. 
+
+By attracting a large developer mind-share, PascalCoin Project's increased productivity and efficiency are expected to reduce the long-term costs significantly, essentially paying for itself. It will also appeal to larger institutions since it's developer mind-share would be large as is the case with Ethereum.
+
+It is also expected by exponentiating developer mind-share, Layer-2 applications will flourish driving PascalCoin to the top-tier of Cryptocurrencies. As a result, the long-term ROI of this proposal is highly beneficial for both PascalCoin and the Pascal-world at large.
+
+
+## Voting
+
+This PIP will be optionally voted on with PIP-0011. It is intended to gauge acceptance (and hopefully consent) from users for this funding. It is also intended to assist users for making a more informed decision during voting.
+
+## Backwards Compatibility
+
+This change is a process change without impact on protocol.
+
+## Links
+
+1. [PIP-0011: 20% Developer Reward][1]
+2. [Lazarus/FPC Home Page][2]
+
+
+[1]: https://github.com/PascalCoin/PascalCoin/blob/master/PIP/PIP-0011.md
+[2]: https://www.lazarus-ide.org

PIP/PIP-0019.md

@@ -0,0 +1,30 @@
+<pre>
+  PIP: PIP-0019
+  Title: Balance recovered from lost accounts to be sent to developers fund
+  Type: Protocol
+  Impact: Hard-Fork
+  Author: Dr. Muhammad Amer <i>&lt;[email protected]&gt;</i>
+  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0019)
+  Status: Draft
+  Created: 2018-01-27
+ </pre>
+ 
+## Summary
+
+It is proposed that major portion of recovered balance (80%) from a lost account should go to developers fund.
+ 
+## Motivation
+ 
+Coinrot is a serious economic issue afflicting almost all other cryptocurrencies. Coinrot is the phenomenon of coins being permanently lost due to lost/corrupted keys and/or natural death. It is estimated that 20% of Bitcoins have already rotted. PascalCoin solves this problem by allowing PASC to be transferred from an account, without owners signature, after an inactivity period of 4 years. In current protocol, the recovered balance from a lost account will go to the miner who will mine the block with lost account. It is proposed that major portion of the recovered amount (80%) should go to developer's fund. This will still give 20% to miners and enhance developer's fund income.
+ 
+## Specification
+ 
+ _None Provided_
+
+## Rationale
+
+According to current protocol, lost account balance can be recovered by miners. By sending major potion of recovered account balance to developer's fund will enhance community effort to uplift PascalCoin.
+
+## Backwards Compatibility
+
+Despite no specification, this proposal is likely to require a hard-fork activation.

PIP/README.md

@@ -15,5 +15,15 @@ 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    |
+| [9](PIP-0009.md)      | RandomHash: GPU & ASIC Resistant Hash Algorithm | Herman Schoenfeld       | Protocol       | Proposed |
+| [10](PIP-0010.md)     | 50% Inflation Reduction                  | Herman Schoenfeld              | Protocol       | Proposed |
+| [11](PIP-0011.md)     | 20% Developer Reward                     | Herman Schoenfeld              | Protocol       | Proposed |
+| [12](PIP-0012.md)     | Change account recovery to 10 years      | Herman Schoenfeld              | Protocol       | Proposed |
+| [13](PIP-0013.md)     | Allow nodes to pull pending operations   | Herman Schoenfeld              | Protocol       | Proposed |
+| [14](PIP-0014.md)     | New operation to certify accounts for extended recovery period   | Dr. Muhammad Amer       | Protocol       | Proposed |
+| [15](PIP-0015.md)     | Fast Block Propagation                   | Herman Schoenfeld              | Protocol       | Proposed |
+| [16](PIP-0016.md)     | Layer-2 protocol support                 | Herman Schoenfeld              | Protocol       | Proposed |
+| [17](PIP-0017.md)     | Anonymity via Transaction Mixing (phase-1)   | Herman Schoenfeld          | Protocol       | Proposed |
+| [18](PIP-0018.md)     | 10% funding allocation for Lazarus/FPC   | Herman Schoenfeld              | Process        | Proposed |
+| [19](PIP-0019.md)     | Balance recovered from lost accounts to be sent to developers fund   | Dr. Muhammad Amer   | Protocol        | Draft |