[enh] Proofreading on Transaction 0.2 overview (2)

content/2016-04-04-transactions-0-2-overview.md

@@ -37,13 +37,13 @@ In protocol 0.1, it is not possible to automate this inter-community exchange. I
 You see: we had to find a solution and enhance our blockchain.
 ## Never reinvent the wheel
 
-Bitcoin universe is rich, after seven years of experimentation, their blockchain suffered by defects. Developers had to answer to many limitations, and had to oftenly create new features. Even today, Bitcoin community continues to evolve and to think about developments to realize to enhance this software.
+Bitcoin universe is rich, after seven years of experimentation, their blockchain suffered of defects. Developers had to answer to many limitations, and had to oftenly create new features. Even today, Bitcoin community continues to evolve and to think about developments to be realize in orderto enhance the software.
 
 In Bitcoin blockchain, it is notably possible to program [scripted transactions](https://en.bitcoin.it/wiki/Script) in a language which is not [turing complete](https://en.wikipedia.org/wiki/Turing_completeness). This scripting language let us experiment and realize new features using Bitcoin blockchain, without having to develop new versions of the software.
 
 Bitcoin universe has also seen many [alternate crypto-currencies](https://coinmarketcap.com/) appear. Often, these forks are realized using simple cipher algorithm changes, or consensus algorithms. These alternative currencies let this users get their part of monetary creation, as Bitcoin does not allow it anymore. Indeed, first miners have reaped everything, and one must now work for them to get his share.
 
-For users to realize safe places of change, the algorithm of crosschain transactions appeared. It makes users of distinct currencies be able to exchange between them monetary units without trusted third party, and without the need to trust each other. These units are present in different blockchains, and yet, crosschain exchange will link the exchange between the two blockchains.
+For users to realize safe places of change, the algorithm of crosschain transactions appeared. It gives users of distinct currencies the ablility to exchange between them monetary units without trusted third party, and without the need to trust each other. These units are present in different blockchains, and yet, crosschain exchange will link the exchange between the two blockchains.
 
 <center>![Protocol 0.2 swap transactions](https://framapic.org/GsAAbeI5Nk6B/NyzAFH2sPuoS)</center>
 
@@ -53,30 +53,30 @@ Previous example presents an ideal case, where Alice and Mark exchange their mon
 
 ## Keep It Simple
 
-To develop a scripting language into our transactions would have necessitate to much efforts, while we do not want our blockchain to transform in an application blockchain. We decided to develop this transaction mechanism in his simplest form: a writable condition in the blockchain.
+To develop a scripting language into our transactions would have necessitate to much efforts, while we do not want our blockchain to be transformed into an application blockchain. We decided to develop this transaction mechanism in its simplest form: a writable condition in the blockchain.
 
-How does it works concretely? Transactions still have a form of *Input* -> *Output*. Input his what is available for spending, while the output corresponds to money which will become available for spending for the recipient. But new elements makes their apparition: *Unlock parameters* and *locking conditions* of the money placed in this transaction. In practice, this change is simple. The transaction is now of the form of *Input* -> *Unlock* -> *Output lock*. The form of a transaction is like the following:
+How does it works concretely? Transactions still have a form of *Input* -> *Output*. Input is what is available for spending, while the output corresponds to money which will become available for spending for the recipient. But new elements makes their apparition: *Unlock parameters* and *locking conditions* of the money placed in this transaction. In practice, this change is simple. The transaction is now of the form of *Input* -> *Unlock* -> *Output lock*. The form of a transaction is like the following:
 
 ```
-ISSUERS: List of identifiers of the signers of this transaction
-INPUTS: List of source transaction, to which the signers must be the owners
+ISSUERS: List of public keys of the signers of this transaction
+INPUTS: List of sources of money, which the signers must be the owners
 UNLOCKS: List of unlock parameters of the inputs
-OUTPUTS: Locking conditions of the money
+OUTPUTS: Locking conditions of the sources of money
 SIGNATURES
 ```
 
-Two types of locks are possibles.
+Two types of locks are available:
 
-* A lock **SIG(PUBKEY)** which means *The signature of PUBKEY is necessary to use this money*.
+* **SIG(PUBKEY)** lock, which means *The signature of PUBKEY is necessary to unlock the source of money*.
 
-* A second lock is **XHX(HASH)**, which means *X number generating HASH is necessary to use this money*.
+* **XHX(HASH)** lock, which means *X number generating HASH is necessary to unlock the source of money*.
 
 These locks can be combined with **OR** and **AND** operators. Finally, it is possible to place a temporal lock **LOCKTIME** on a transaction. This lock prevents a transaction from being written in the blockchain before a fixed time.
 ## Some examples of the new possibilities
 
-Our simple transaction of 0.1 protocol transforms into a new form. To send money to public key **A** we place a locking condition **SIG(A°** meaning *Transaction has to be signed by pubkey A for this money to be unlocked*.
+Our simple transaction from v0.1 of the protocol are transformed into a new form. To send money to public key **A** we place a locking condition **SIG(A°** meaning *Transaction has to be signed by pubkey A for this money to be unlocked*.
 
-To send money to a pubkey **A**, while retaining control of the time it will be spendable, we will use a lock **XHX(HASH)** combined with a **SIG(A)**. We will choose a number **X** which, hashed, will generate the **HASH**. We will give this number **X** to **A** only when we will want him to be able to spend his money, for example when he did do his part of the contract.
+To send money to a pubkey **A**, while retaining control of the time it will be spendable, we will use a lock **XHX(HASH)** combined with a **SIG(A)**. We will choose a number **X** which, hashed, will generate the **HASH**. We will give this number **X** to **A** only when we will want him to be able to spend his money, for example when he will have fulfilled his part of the contract.
 
 We can also consider to implement *consumable* bills. A bill will be locked on a money consumable only by a secret number hidden in the bill. Physical destruction of the bill will reveal the number and let one get the money. A lot of physical destruction means are possible, like tickets to scratch, a chemical revealer, etc.