PIP-0013: use hash of keys for optimization

PIP/PIP-0013.md

@@ -15,11 +15,11 @@ A new network operation called NET_OP_PULL_PENDING is proposed that allows nodes
 
 ## 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 only receives it when the next block is minted. This situation can lead to out-of-sequence N_OPERATION errors since a node forgets the correct N_OPERATION of accounts due to pending operations it no longer knows about. This has led to withdrawal failures at exchanges from Poloniex, a serious user-experience issue.  Whilst this can be mitigated by persisting the pending pool, a comprehensive solution is proposed here that allows a node to download relevant (or all) of the pending pool on startup. This also benefits mobile and light-client nodes. 
+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 
+The proposal here is to add a new network operation. 
 
 ### NET_OP_PULL_PENDING
 
@@ -57,12 +57,12 @@ else
        let receiverAccount = SafeBox.Accounts[O.Receiver]
        let feePayerAccount = SafeBox.Accounts[O.Signer]
        
-       if senderAccount.Key = k OR receiverAccount.Key = k OR feePayerAccount.Key = k then
+       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 O.NewKey = k then
+          if O is ChangeKeyOperation AND RIPEMD160(O.NewKey) = k then
             output.Add(O)
-          else if O is BuyAccountOperation and O.NewKey = k then
+          else if O is BuyAccountOperation and RIPEMD160(O.NewKey) = k then
             output.Add(O)
            else ....
             
@@ -78,7 +78,7 @@ Since this network operation could be used to DoS a peer, peers should include t
 
 ## 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. 
+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