Grammatical errors, spell corrections

docs/chain.introduction.rst

@@ -32,7 +32,7 @@ Populus can run two types of transient chains.
 * ``temp``
 
     Runs a blockchain backed by the go-ethereum ``geth`` client.  This chain
-    will use a temporary directory for it's chain data which will be cleaned up
+    will use a temporary directory for its chain data which will be cleaned up
     and removed when the chain shuts down.
 
 
@@ -41,7 +41,7 @@ Local Chains
 
 Local chains can be setup within your ``populus.json`` file.  Each local chain
 stores its chain data in the ``populus.Project.blockchains_dir``
-and persists it's data between runs.
+and persists its data between runs.
 
 Local chains are backed by the go-ethereum ``geth`` client.
 
@@ -147,4 +147,4 @@ Here is an example of running the ``tester`` blockchain.
 
 .. note:: The ``testrpc`` chain can be run in the same manner.
 
-.. _Web3.py: http://web3py.readthedocs.io/en/latest/
+.. _Web3.py: http://web3py.readthedocs.io/en/latest/

docs/config.rst

@@ -199,7 +199,7 @@ primary sections, ``web3``, ``chain``, and ``contracts`` configuration settings.
     }
 
 The above chain configuration sets up a new local private chain within your
-project.  The chain above would set it's data directory to
+project.  The chain above would set its data directory to
 ``<project-dir>/chains/my-chain/``.
 
 To simplify configuration of chains you can use the ``ChainConfig`` object.
@@ -263,7 +263,7 @@ Available options are:
 
 * ``populus.chain.LocalGethChain``
 
-    A geth backed chain which will setup it's own data directory in the
+    A geth backed chain which will setup its own data directory in the
     ``./chains`` directory in the root of your project.
 
 * ``populus.chain.TemporaryGethChain``

docs/dev_cycle.intro.rst

@@ -82,7 +82,7 @@ all the transactions in this blocks are accepted and carried out by all the node
 **Node**: A running instance of the blockchain. The nodes sync to one another. When there are conflicts,
 e.g. if two nodes suggest two different block for the next block, the nodes gets a decision by consensus.
 
-**Consensus**: Miners get rewards when they find a valid block, and a valid block is valid only if it's built on a valid parent block,
+**Consensus**: Miners get rewards when they find a valid block, and a block is valid only if it's built on a valid parent block,
 and *accepted by the majority of nodes on the blockchain*. So miners are incentivised to reject false blocks and false transactions.
 They know that if they work on a false transaction (say a cheat), then there
 is high probability that other nodes will reject it, and their work effort will be lost without rewards.
@@ -121,6 +121,6 @@ the EVM needs the ABI in order to know how to call the bytecode.
 
 **testnet**: An Ethereum blockchain for testing. It behaves exactly as mainnet, but you don't use real Ether to send money and pay for the gas
 
-**Local chain**: A blockchain that runs localy, has it's own blocks, and does not sync to any other blockchain. Useful for development
+**Local chain**: A blockchain that runs localy, has its own blocks, and does not sync to any other blockchain. Useful for development
 and testing
 

docs/dev_cycle.part-01.rst

@@ -214,7 +214,7 @@ with  ``address.call``, and (b) when just send just Ether, in a transaction that
 .. note::
 
     If a contract has a fallback function,
-    any transaction or sending of ether to an address with code will result in it's code being invoked.
+    any transaction or sending of ether to an address with code will result in its code being invoked.
 
 **Payable**:
 ``function donate(uint usd_rate) public payable nonZeroValue {...}`` and ``function () payable {...}`` use the *payable*

docs/dev_cycle.part-02.rst

@@ -65,7 +65,7 @@ If you copy-pasted the ``Donator`` contract example, you will get:
 
       > stdout:
 
-What's that? actually it's not that bad. You can ignore the Python traceback, which is just the Populus call stack until the actual
+What's that? Actually it's not that bad. You can ignore the Python traceback, which is just the Populus call stack until the actual
 call to the compiler.
 
 To undersatnd what went wrong, just look at the compiler's output. The error message is quite clear:
@@ -92,7 +92,7 @@ The fixed line should be:
 .. note::
 
   Try the `online IDE <https://remix.ethereum.org>`_ , which has great interactive compiler and web-form like interface
-  to call the contract and it's funcitons.
+  to call the contract and its funcitons.
 
 
 Try to compile again:
@@ -123,8 +123,8 @@ Tester Deployment
 You now have two compiled contracts, ready for deployment.
 
 The first deployment step is to verify that it works on the ``tester`` chain. This is an ephemeral blockchain.
-It runs localy, and resets each time is starts. The state of the chain when it runs is kept only in memory,
-and cleared when done. It's a great tool for a testing.
+It runs locally, and resets each time it starts. The state of the chain when it runs is kept only in memory,
+and cleared when done. It's a great tool for testing.
 
 Deploy to the ``tester`` chain:
 
@@ -158,7 +158,7 @@ Deploy to the ``tester`` chain:
 When you deploy a contract Populus re-compiles *all* the contracts, but deploys only those you asked for.
 
 Well, deployment works. Since the ``tester`` chain is *not* persistent, everything was deleted, but the deployment should work on persistent
-chains: it's the same Ethereum protocol. Check for yourself and run the deploy again, it will re-dploy exactly the same,since
+chains: it's the same Ethereum protocol. Check for yourself and run the deploy again. It will re-deploy exactly the same, since
 each starts from a reset state.
 
 
@@ -171,4 +171,4 @@ So far you have:
 * Verified that deployment works, using the tester chain
 
 
-In the next step we will add some tests.
+In the next step we will add some tests.

docs/dev_cycle.part-03.rst

@@ -6,10 +6,9 @@ Part 3: First Test
 Tests and Chains
 ----------------
 
-For testing, we will use the ``tester`` chain again. It's very convenient blockchain for tests,
-because it resets on each run and the state is saved only in memory and cleared after each run.
-In a way, this is an idea similar to running tests against a DB,
-where you create an ad-hoc temporary DB for the tests.
+For testing, we will use the ``tester`` chain again. It's a very convenient blockchain for tests,
+because the state is saved only in memory and cleared after each run.  In a way, this is an idea
+similar to running tests against a DB, where you create an ad-hoc temporary DB for the tests.
 
 You will run Populus tests with ``py.test``, which was installed when you installed Populus.
 
@@ -22,7 +21,7 @@ Add a test file:
 .. note::
 
     py.test collects all the tests that follow
-    it's `naming conventions <https://pytest.readthedocs.io/en/reorganize-docs/new-docs/user/naming_conventions.html>`_.
+    its `naming conventions <https://pytest.readthedocs.io/en/reorganize-docs/new-docs/user/naming_conventions.html>`_.
 
 We don't need the Greeter example for this project, so delete it:
 
@@ -39,7 +38,7 @@ What is a Contract?
 -------------------
 
 The simplest definition of a contract is a compiled program that runs on the Ethereum blockchain.
-It's a bytecode of instructions, saved on the blockchain, that a blockchain node can run.
+It's a set of bytecode instructions, saved on the blockchain, that a blockchain node can run.
 The node gives this program a sandbox, a closed environment, to execute.
 
 In a way, if the blockchain is the OS, then a contract is an executable that runs by the OS.
@@ -112,8 +111,8 @@ Another bonus is the ``chain`` object, provided as an argument at ``def test_def
 that corresponds to a running blockchain, the ``tester`` blockchain.
 Reminder: The ``tester`` chain is ephemeral, saved only in memory, and will reset on every test run.
 
-The ``chain`` argument is a py.test *fixture*: in py.test world it's a special argument that the test function can accept.
-You don't have to declare or assign it, it's just ready and available for your test.
+The ``chain`` argument is a py.test *fixture*: in py.test world, it's a special argument that the test function can accept.
+You don't have to declare or assign it. It's just ready and available for your test.
 
 The Populus testing fixtures comes from the Populus py.test plug-in, which prepares for you several useful fixtures: ``project``,
 ``chain``, ``provider``, ``registrar`` and ``web3``. All these fixtures are part of the Populus API. See :ref:`populus_testing`

docs/dev_cycle.part-04.rst

@@ -55,7 +55,7 @@ object with Python methods. This object is stored in the ``donator`` variable.
 Reminder: we have two options to interact with a contract on the blockchain, *transactions* and *calls*.
 With Populus, you initiate a transaction with ``transact``, and a call with ``call``:
 
-* *Transactions*: Send a transaction, run the contract code, transfer funds, and *change* the state of the contract and it's balance. This change will be permanent, and synced to the entire blockchain.
+* *Transactions*: Send a transaction, run the contract code, transfer funds, and *change* the state of the contract and its balance. This change will be permanent, and synced to the entire blockchain.
 
 * *Call*: Behaves exactly as a transaction, but once done, everything is revert and no state is changed. A call is kinda "dry-run", and an efficient way to query the current state without expensive gas costs.
 
@@ -88,7 +88,7 @@ Populus gives you a *Python* interface to a bytecode contract. Nice, no?
 **[6] Asserts**: We expect the ``donationsTotal`` to be ``500 + 650 = 1150``, the ``donationsCount`` is 2,
 and the ``defaultUsdRate`` to match the last update, 380.
 
-The test gets the varaibles with ``call``, and should update instanrly because it's a local ``tester`` chain. On a distributed
+The test gets the variables with ``call``, and should update instantly because it's a local ``tester`` chain. On a distributed
 blockchain it will take sometime until the transactions are mined and actually change the state.
 
 Run the test:

docs/dev_cycle.part-06.rst

@@ -21,7 +21,7 @@ Run this chain:
 
     $ chains/horton/./run_chain.sh
 
-And you will see that geth starts to do it's thing:
+And you will see that geth starts to do its thing:
 
 .. code-block:: shell
 
@@ -152,7 +152,7 @@ The next line should be familiar to you by now:
      donator, deploy_tx_hash = chain.provider.get_or_deploy_contract('Donator')
 
 
-Populus does it's magic:
+Populus does its magic:
 
 **New**: If the contract was *never* deployed to a blockchain, compile the source,
 deploy to the chain, create a Web3 contract Python object instance, which points to the blockchain bytecode, and returns this Python object.
@@ -255,7 +255,7 @@ This is how you project directory should look:
 
 
 The *registrar* is loaded with ``get_or_deploy_contract``, and if Populus finds an entry for a contract, it knows
-that the contract already deployed, and it's address on this chain.
+that the contract already deployed, and its address on this chain.
 
 Take a look at the registrar:
 
@@ -276,7 +276,7 @@ The registrar saves a deployment reference with unique "signature" of the blockc
 The signature is the first block hash, which is obviously unique. It appears after the ``blockchain://`` part. Then the hash
 of the latest block at the time of deployment after, ``block``.
 The registrar uses a special URI structure designed for blockchains, which is built from a resource name (blockchain, block, etc)
-and it's hash. See `BIP122 URI <https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki>`_
+and its hash. See `BIP122 URI <https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki>`_
 
 To have *another* contract deployed to the *same* chain, we will greet our good ol' friend, the Greeter. Yes, you probably
 missed it too.
@@ -529,4 +529,4 @@ Interim Summary
 * You deployed a persistent contract instance to a local chain
 * You interacted with the ``Project`` object, which is the entry point to the Populus API
 * You deployed the same Solidity source file on two seprated local chains, ``horton`` and ``morty``
-* Deployments are saved in the the ``registrar``
+* Deployments are saved in the the ``registrar``

docs/dev_cycle.part-07.rst

@@ -15,7 +15,7 @@ and the *ABI* (application binary interface).
 
 Reminder: the contract instance is compiled, a bytecode, so the EVM
 (ethereum virtual machine) needs the ABI in order to call this bytecode. The ABI (application binary interface)
-is essentially a JSON file with detailed description of the functions and their arguments, which tells how to call them. It's part of the
+is essentially a JSON file with a detailed description of the functions and their arguments, which says how to call them. It's part of the
 compiler output.
 
 Populus does not ask you for the address and the ABI of the projects' contracts:  it already
@@ -292,7 +292,7 @@ and mine it:
     INFO [10-20|01:49:05] Commit new mining work                   number=3920 txs=1 uncles=0 elapsed=735.282µs
     INFO [10-20|01:49:21] Successfully sealed new block
 
-Check the persistancy of the instance again. Stop the ``horton`` chain, press Ctrl+C in it's terminal window,
+Check the persistancy of the instance again. Stop the ``horton`` chain, press Ctrl+C in its terminal window,
 and then re-run it with ``chains/horton/./run_chain.sh``.
 
 Run the script again:
@@ -306,7 +306,7 @@ Run the script again:
     Total of 7.00 Ether accepted in 3 donations, an avergage of 2,333,333,333,333,333,504.00 Wei per donation.
     Thank you for the donation! Tx hash 0x8a595949271f17a2a57a8b2f37f409fb1ee809c209bcbcf513706afdee922323
 
-Oh, it's so easy to donate when a genesis block allocates you billion something.
+Oh, it's so easy to donate when a genesis block allocates you billions of something.
 
 The contract instance *is* persistent, and the state is saved. With ``horton``, a local chain, it's saved to your hard-drive.
 On ``mainent`` and ``testnet``, to the entire blockchain nodes network.

docs/dev_cycle.part-08.rst

@@ -72,7 +72,7 @@ We can interact with a contract instance via the Python shell as well. We will d
 for the sake of demostration. During the regular development process, Populus does all that
 for you.
 
-To get a handle to the ``Donator`` instance on ``horton`` we need (a) it's **address**, where the bytecode sits,
+To get a handle to the ``Donator`` instance on ``horton`` we need (a) its **address**, where the bytecode sits,
 and (b) the **ABI** ,application binary interface, the detailed description of the functions and arguments
 of the contract interface. With the ABI the EVM knows how to call the compiled
 bytecode.
@@ -107,7 +107,7 @@ The :ref:`populus_registrar` is where Populus holds the deployment details:
     }
 
 It's hard to tell which blockchain is ``horton``. Populus encodes a blockchain signature
-by the *hash* of it's block 0.  We only see that ``Donator`` is deployed on two blockchains.
+by the *hash* of its block 0.  We only see that ``Donator`` is deployed on two blockchains.
 
 But since ``Greeter`` was deployed only on ``horton``,
 the blockchain with two deployments is ``horton``, and the other one is ``morty``.
@@ -401,7 +401,7 @@ Quit the ``horton`` chain and start a new Python shell.
 Mainnet with Infura.io
 ''''''''''''''''''''''
 
-As an endpoint we will use ``infura.io``. It's a publicly avaialble blockchain node, by Consensys, which is great
+As an endpoint we will use ``infura.io``. It's a publicly available blockchain node, by Consensys, which is great
 for read-only queries.
 
 Infura is a remote node, so you will use the ``HTTPProvider``.
@@ -463,7 +463,7 @@ This transaction details:
 
     If you will use block number 4402735, you should get **exactly** the same output as shown above.
     This is the ``mainent``, which is synced accross all the nodes, and every node will return the same info.
-    The local chains ``horton`` or ``morty`` run a private instance, so every machine produces it's own blocks and hashes.
+    The local chains ``horton`` or ``morty`` run a private instance, so every machine produces its own blocks and hashes.
     Not so on the global, real blockchain, where all the nodes are synced
     (which is the crux of the whole blockchain idea).
 
@@ -526,7 +526,7 @@ Interim Summary
 * Query the blockchain info on local geth nodes.
 
 Although Populus does a lot of work behind the scenes, it's recommended to have a good grasp of Web3.
-See the the `Web3.py documentation <https://web3py.readthedocs.io/en/latest/>`_ and
+See the `Web3.py documentation <https://web3py.readthedocs.io/en/latest/>`_ and
 the `full list of `web3.js JavaScript API <https://web3js.readthedocs.io/en/1.0/>`_. Most of the javascript
 API have a Python equivalent.
 

docs/dev_cycle.part-09.rst

@@ -117,7 +117,7 @@ the ``Donator`` will just continue to hold these 113 Ether. In other words, they
 
     The blockchain "state" is not a physical property of nature. The state is a consensus
     among the majority of the nodes on the blockchain. If, theoreticaly, all the nodes decide to wipe out an account
-    balance, they can do it. A single node can't, but the entire network can. It's  unlikely to happen, but it's
+    balance, they can do it. A single node can't, but the entire network can. It's unlikely to happen, but it's
     a theoretical possiblility you should be aware of. It happend once, after the DAO hack, where all the nodes
     agreed on a *hard fork*, a forced update of the blockchain state, which reverted the hack.
     See `a good discussion of the issue on Quartz <https://qz.com/730004/everything-you-need-to-know-about-the-ethereum-hard-fork/>`_.
@@ -157,7 +157,7 @@ Withdraw is handled in one simple function:
             }
 
 Anyone that calls this function will get the entire Ether in the contract to his or her own
-account. The contract sends it's remaining balance, ``this.balance``, to the account address
+account. The contract sends its remaining balance, ``this.balance``, to the account address
 that sent the transaction, ``msg.sender``.
 
 The send is enclosed in a ``require`` clause, so if something failed everything is reverted.
@@ -173,7 +173,7 @@ Re-entry attack
 ''''''''''''''''
 
 When ``Donator2`` will run ``send(this.balance)``, the beneficiary
-contract gets an opportunity to run it's ``fallback`` and get the execution control.
+contract gets an opportunity to run its ``fallback`` and get the execution control.
 In the fallback, it can call ``Donator2`` again before the ``send`` was line was completed, but the money already *sent*.
 This is a *re-entry* attack. To avoid it, any state changes should occur *before* the send.
 
@@ -449,7 +449,7 @@ Unlock the account:
     Again, extremely naive and unsafe way to unlock and use passwords. Use only for development and testing,
     with dummy Ether
 
-The new account should be ready, it's unlocked, and has the funds for the gas.
+The new account should be ready. It's unlocked and has the funds for the gas.
 
 Send the withdraw transaction yet *again*:
 

docs/dev_cycle.part-10.rst

@@ -11,7 +11,7 @@ from other contracts, which is especially useful when you a more generic functio
 a basic core contract, a functionality you want to inherit and re-use in another, more specific use case.
 
 
-A Contract that is Controlled by it's Owner
+A Contract that is Controlled by its Owner
 -------------------------------------------
 
 
@@ -380,7 +380,7 @@ Run the test:
 
 
 Ok, all the inherited members passed: The ``Ownable`` constructor that sets ``owner`` ran when you deployed
-it's subclass, ``Donator3``. The parent modifier ``onlyOwner`` works as a modifier to a subclass function,
+its subclass, ``Donator3``. The parent modifier ``onlyOwner`` works as a modifier to a subclass function,
 and the ``transferOwnership`` parent's funcion can be called by clients via the subclass interface.
 
 .. note::