PIP-0030: typos, grammar and proof error fixes

PIP/PIP-0030.md

@@ -12,7 +12,7 @@
 
 ## Summary
 
-A new "SafeBoxHash" algorithm is proposed that enables secure deletion of the the SafeBox for non-mining nodes such as "light-nodes".
+A new "SafeBoxHash" algorithm is proposed that enables secure deletion of the SafeBox for non-mining nodes such as "light-nodes".
 
 ## Motivation
 
@@ -32,9 +32,9 @@ By changing the SafeBoxHash to be the SafeBoxRoot, it becomes possible for light
 
 #### Instant Wallet Synchronization
 
-Light-nodes will no longer require to syncronize and validate the SafeBox or the last 100 blocks. Instead, in order to validate their accounts they will simply query other nodes for the latest **SafeBoxHash** and the accounts states for the accounts they care about. The response will include short merkle-proofs that can be used to cryptographically prove those account states were used to compute the SafeBoxHash.
+Light-nodes will no longer require to syncronize and validate the SafeBox or the last 100 blocks. Instead, in order to validate their accounts they will simply query other nodes for the latest **SafeBoxRoot** and the Account Segments for the accounts they care about. The response will include short merkle-proofs that can be used to cryptographically prove those Account Segments are connected to the SafeBoxRoot.
 
-In effect, this results in an near-instant synchronization for the light-node.
+In effect, this results in an near-instant synchronization for light-nodes.
 
 
 #### Layer-2 Efficiency
@@ -59,9 +59,9 @@ This is not possible on other cryptocurrencies.
 
 SafeBox (in combination with this PIP), solves another major issue afflicting decentralized consensus systems.
 
-Since the merkle-proofs outlined in this PIP apply to **Account Segments** and not just individual accounts, there's always a small chance a light-node already has the account state and proof that another light-node may be requesting. It follows that a sufficiently large **set of light-nodes** attains a **high probability** of possessing the account state and proof.
+Since the merkle-proofs outlined in this PIP apply to **Account Segments** and not just individual accounts, there's always a small chance that a light-node possesses the Account Segment and proof that another light-node may be requesting. It follows that a sufficiently large **set of light-nodes** attains a **high probability** of possessing an Account Segment and proof any new node may be requesting.
 
-This leads to an astonishing outcome, since by employing basic request relaying and response caching, the entire SafeBox distributes itself over the light-node sub-network, multiple times over and rapidly. This allows light-nodes to handle almost all of their own load **without** burdening full-nodes. Also, light-nodes can ensure they never propagate or receive stale cached values by simply re-applying the proof on the value using the latest SafeBox hash.
+This leads to an astonishing outcome, since by employing basic request relaying and response caching, the entire SafeBox distributes itself over the light-node sub-network, multiple times over and rapidly. This allows light-nodes to service almost all of their own load **without** burdening full-nodes. Also, light-nodes can ensure they never propagate or receive stale cached values by simply re-applying the proof on the value using the latest SafeBox hash.
 
 In this manner, light-nodes provide a natural and secure load-balancing mechanism for the entire PascalCoin network. This is **not** the case for other cryptocurrencies where their SPV-wallets always depend on a full-node to service their requests. In a global adoption scenario, these networks would grind to a halt as large numbers of SPV nodes overwhelm (and essential DoS-attack) a small number of full-nodes struggling with an ever-expanding blockchain.
 
@@ -70,7 +70,6 @@ As a result, this feature makes PascalCoin "global adoption ready".
 
 ## Specification
 
-
 ### SafeBoxRoot
 
 
@@ -144,13 +143,13 @@ To prove an AccountSegment was used in the SafeBoxRoot calculation, the user fir
 * User's retrieves Account Segment 3 from network, unsecurely.
 * User determines the SafeBox root SR is correct most-work SafeBox (this is a future PIP, but can be normal sync for now).
 * User asks a random node for **"proof of Account Segment 3"**.
-* Node responds with four 32byte hashes
+* Node responds with four 32 byte hashes, *Hash_1...Hash_4*
 * User performs the below validation proof:  
 
 ![PASA Seals](resources/PIP-0030/SafeBoxRoot-Example-Proof-1.drawio.png)
 
 ```
-SR = HASH( HASH ( HASH( HASH(AccSeg3) ++ HASH(1), HASH(2) ), HASH(3) ), HASH(4) ) 
+SR = HASH( HASH ( HASH( HASH ( HASH(AccSeg3) ++ HASH_1) ++ HASH_2 ) ++ HASH_3 ) ++ HASH_4 ) 
 ```
 
 #### Example: Proof 2
@@ -159,14 +158,14 @@ SR = HASH( HASH ( HASH( HASH(AccSeg3) ++ HASH(1), HASH(2) ), HASH(3) ), HASH(4)
 * User's retrieves Account Segment 9 from network, unsecurely.
 * User determines the SafeBox root SR is correct most-work SafeBox (this is a future PIP, but can be normal sync for now).
 * User asks a random node for **"proof of Account Segment 9"**.
-* Node responds with two 32byte hashes
+* Node responds with two 32 byte hashes, , *Hash_1...Hash_2*
 * User performs the below validation proof:  
 
 
 ![PASA Seals](resources/PIP-0030/SafeBoxRoot-Example-Proof-2.drawio.png)
 
 ```
-SR = HASH( HASH(AccSeg9) ++ HASH(1), HASH(2) ) 
+SR = HASH( HASH ( HASH(AccSeg9) ++ HASH_1 ) ++ HASH_2 ) 
 ```
 
 **Note**: the dotted line implies this level of the hash proof was skipped, since it was not hashed. This is automatic in the proof.