Merge pull request #268 from eordano/master

Minor spelling fixes in README.md

README.md

@@ -36,19 +36,19 @@ About Copay
 General
 -------
 
-*Copay* implements a multisig wallet using p2sh addresses. It support multiple wallet configurations, like 3-of-5
+*Copay* implements a multisig wallet using p2sh addresses. It supports multiple wallet configurations, like
-(3 required signatures from 5 participant peers) or 2-of-3.  To generate addresses to receive coins,
+3-of-5 (3 required signatures from 5 participant peers) or 2-of-3. To generate addresses to receive coins,
-*Copay* needs the public keys of all the participat peers in  the wallet. Those public keys, among the 
+*Copay* needs the public keys of all the participant peers in the wallet. Those public keys, among the 
 wallet configuration, are combined to generate a single address to receive a payment.  
 
-To unlock the payment, and spend the wallet's funds, the needed signatures need to be collected an put togheter
+To unlock the payment, and spend the wallet's funds, the needed signatures need to be collected and put
-in the transaction. Each peer manage her own private key, and that key is never transmited to other
+togheter in the transaction. Each peer manages her own private key, and that key is never transmited to
-peers. Once a transaction proposal is created, the proposal is distributed among the peers and each peer
+other peers. Once a transaction proposal is created, the proposal is distributed among the peers and each peer
-can sign the transaction locally. Once the transaction is complete, the last signing peer will broadcast the 
+can sign the transaction locally. Once the signing is complete, the last signing peer will broadcast the 
 transaction to the bitcoin network, using a public API for that (Insight API by default in *Copay*)..
 
-*Copay* also implements BIP32 to generate new addresses for the peers. This mean that the actual piece of 
+*Copay* also implements BIP32 to generate new addresses for the peers. This means that the actual piece of 
-information shared between the peers is an extended public key, from which is possible to derive more
+information shared between the peers is an extended public key, from which it is possible to derive more
 public keys so the wallet can use them. Each peer holds for himself his extended private key, to be able
 to sign the incoming transaction proposals.
 
@@ -57,41 +57,40 @@ Serverless web
 *Copay* software does not need an application server to run. All the software is implemented in client-side
 Javascript. For persistent storage, the client browser's *localStorage* is used. This information is
 stored encryped using the peer's password. Also it is possible (and recommended) to backup that information
-with using one of the options provided by *Copay*, like file downloading.  Without a proper backup, all 
+with using one of the options provided by *Copay*, like file downloading. Without a proper backup, all 
 wallets funds can be lost if the browser's localStorage is deleted, or the browser installation deleted.
 
 Peer communications
 -------------------
-*Copay* use peer-to-peer (p2p) networking to comunicate the parties. Parties exchange transaction 
+*Copay* use peer-to-peer (p2p) networking for comunication between the parties. Parties exchange transaction 
-proposals, public keys, nicknames and some wallet options. As mentioned above, private keys are *no*
+proposals, public keys, nicknames and some wallet options. As mentioned above, private keys are *not*
 sent to the network. 
 
-webRTC is the used protocol. A p2p facilitator server is needed to allow the peers to find each other.
+webRTC is the used protocol for p2p communication. A p2p facilitator server is needed to allow the peers
- *Copay* uses the open-sourced *peerjs* 
+to find each other. *Copay* uses the open-sourced *peerjs* server implementation. Wallet participants
-server implementation. Wallet participants can use a public peerjs server or install their own. Once the peers
+can use a public peerjs server or install their own. Once the peers find each other, a true p2p
-find each other, a true p2p connection is established and there is no flow of information to the
+connection is established and there is no flow of information to the server, only between the peers.
-server, only between the peers.
 
-webRTC uses DTLS to secure communications between the peers, and each peer use a self-signed
+webRTC uses DTLS to secure communications between the peers, and each peer uses a self-signed
 certificate.
 
 Security model
 --------------
-On top of webRTC, *Copay* peers authenticate as part of the "wallet ring"(WR)  by 2 factors: An identity 
+On top of webRTC, *Copay* peers authenticate as part of the "wallet ring"(WR) by 2 factors: An identity 
 key and a network key. 
 
-The *identity key* is a ECDSA public key derived from their extended public 
+The *identity key* is a ECDSA public key derived from peers' extended public key using a specific BIP32
-key using a specific BIP32 branch. This special public key is never used for Bitcoin address creation, and
+branch. This special public key is never used for Bitcoin address creation, and should only be know by
-should only be know by members of the WR. 
+members of the WR. 
-In *Copay* this special public key is named *copayerId*.  To register into the peerjs server, while not
+In *Copay* this special public key is named *copayerId*. To register into the peerjs server, while not
-reveling its copayerId to an entity outside the WR, each peer hash the copayerId and pass a SIN 
+reveling its copayerId to an entity outside the WR, each peer hashes the copayerId and sends a SIN 
-to the server. peer discovery is then entirely done using peer's SINs. Note that all copayers in the WR
+to the server. peer discovery is then entirely done using the peer's SINs. Note that all copayers in
-know the complete copayerIDs of the peers.
+the WR know the complete copayerIDs of the peers.
 
 The *network key* is a random key generated when the wallet is created an shared in the initial 
 'secret string' that peers distribute while the wallet is been created. The network key is then stored 
-by each peer on the wallet configuration. The network key is used for establishing a CCM/AES 
+by each peer in their wallet configuration. The network key is used for establishing a CCM/AES 
-authenticated encrypted channel between all peers, on top of webRTC. The main reason of implementing
+authenticated encrypted channel between all peers, on top of webRTC. The main reason for implementing
 the *network key* is to prevent man-in-the-middle attacks from a compromised peerjs server.
 
 Secret String
@@ -99,7 +98,7 @@ Secret String
 When a wallet is created, a secret string is provided to invite new peers to the new wallet. This string
 has the following format:
 
-  - CopayerId of the peer generating the string. This is a 33 bytes ECDSA public key, as explained above.
+  - CopayerId of the peer generating the string. This is a 33 byte ECDSA public key, as explained above.
 This allow the receiving peer to locate the generating peer.
   - Network Key. A 8 byte string to encrypt and sign the peers communication.
 
@@ -109,7 +108,7 @@ Peer authentication
 -------------------
 
 It is important to note that all data in the wallet is shared between *all peers*, with the exception of each
-peer's private key, with are never transmited throught the network. There is not private messages or, in general,
+peer's private key, which are never transmited throught the network. There are no private messages or, in general,
 information that belongs to a subset of the WR.