Update EIP-225: fix typos

EIPS/eip-225.md

@@ -1,14 +1,14 @@
 ---
 eip: 225
 title: Clique proof-of-authority consensus protocol
 author: Péter Szilágyi <peterke@gmail.com>
 discussions-to: https://github.com/ethereum/EIPs/issues/225
 status: Final
 type: Standards Track
 category: Core
 created: 2017-03-06
 ---
 
 ## Abstract
 
 Clique is a proof-of-authority consensus protocol. It shadows the design of Ethereum mainnet, so it can be added to any client with minimal effort.
@@ -36,7 +36,7 @@
 
 The main design goals of the PoA protocol described here is that it should be very simple to implement and embed into any existing Ethereum client, while at the same time allow using existing sync technologies (fast, light, warp) without needing client developers to add custom logic to critical software.
 
 ## Design constraints
 
 There are two approaches to syncing a blockchain in general:
 
@@ -192,7 +192,7 @@
 ## Test Cases
 
 ```go
-// block represents a single block signed by a parcitular account, where
+// block represents a single block signed by a particular account, where
 // the account may or may not have cast a Clique vote.
 type block struct {
   signer     string   // Account that signed this particular block
@@ -473,6 +473,6 @@
 
 ## Implementation
 
 A reference implementation is part of [go-ethereum](https://github.com/ethereum/go-ethereum/tree/master/consensus/clique) and has been functioning as the consensus engine behind the [Rinkeby](https://www.rinkeby.io) testnet since April, 2017.
 ## Copyright
 Copyright and related rights waived via [CC0](../LICENSE.md).

EIPS/eip-627.md

@@ -11,8 +11,8 @@
 ## Abstract
 
 This EIP describes the format of Whisper messages within the ÐΞVp2p Wire Protocol.
 This EIP should substitute the [existing specification](https://github.com/ethereum/wiki/wiki/Whisper-Wire-Protocol).
 More detailed documentation on Whisper could be found [here](https://github.com/ethereum/go-ethereum/wiki/Whisper).
 
 ## Motivation
 
@@ -153,7 +153,7 @@
 
 Those unable to decrypt the message data are also unable to access the signature. The signature, if provided, is the ECDSA signature of the Keccak-256 hash of the unencrypted data using the secret key of the originator identity. The signature is serialised as the concatenation of the `R`, `S` and `V` parameters of the SECP-256k1 ECDSA signature, in that order. `R` and `S` are both big-endian encoded, fixed-width 256-bit unsigned. `V` is an 8-bit big-endian encoded, non-normalised and should be either 27 or 28.
 
-The padding field was introduced in order to align the message size, since message size alone might reveal important metainformation. Padding can be arbitrary size. However, it is recommended that the size of Data Field (excuding the Salt) before encryption (i.e. plain text) should be factor of 256 bytes.
+The padding field was introduced in order to align the message size, since message size alone might reveal important metainformation. Padding can be arbitrary size. However, it is recommended that the size of Data Field (excluding the Salt) before encryption (i.e. plain text) should be factor of 256 bytes.
 
 ### Payload Encryption
 
@@ -175,7 +175,7 @@
 
 This EIP is compatible with Whisper version 6. Any client which does not implement certain packet codes should gracefully ignore the packets with those codes. This will ensure the forward compatibility. 
 
 ## Implementation
 
 The golang implementation of Whisper (v.6) already uses packet codes 0x00 - 0x03. Parity's implementation of v.6 will also use codes 0x00 - 0x03. Codes 0x7E and 0x7F are reserved, but still unused and left for custom implementation of Whisper Mail Server.