fix spelling mistakes

Author: bohendo

not-so-smart-contracts/solidity/bad_randomness/README.md

@@ -10,7 +10,7 @@ Pseudorandom number generation on the blockchain is generally unsafe. There are
 
 A common workaround for the lack of on-chain randomness is using a commit and reveal scheme. Here, each user submits the hash of their secret number.
 When the time comes for the random number to be generated, each user sends their secret number to the contract
-which then verifies it matches the hash submitted earlier and xors them together. Therefore no participant can observe how their contribution
+which then verifies it matches the hash submitted earlier and XORs them together. Therefore no participant can observe how their contribution
 will affect the end result until after everyone has already committed to a value. However, this is also vulnerable to DoS attacks,
 since the last person to reveal can choose to never submit their secret. Even if the contract is allowed to move forward without
 everyone's secrets, this gives them influence over the end result. In general, we do not recommend commit and reveal schemes.
@@ -20,7 +20,7 @@ everyone's secrets, this gives them influence over the end result. In general, w
 - A lottery where people bet on whether the hash of the current block is even or odd. A miner that bets on even can throw out blocks whose
 hash are even.
 - A commit-reveal scheme where users don't necessarily have to reveal their secret (to prevent DoS). A user has money riding on the outcome
-of the PRG and submits a large number of commits, allowing them to choose the one they want to reveal at the end.
+of the PRNG and submits a large number of commits, allowing them to choose the one they want to reveal at the end.
 
 ## Mitigations
 
@@ -30,13 +30,13 @@ In the future, however, these approaches show promise
 
 - [Verifiable delay functions](https://eprint.iacr.org/2018/601.pdf): functions which produce a pseudorandom number
 and take a fixed amount of sequential time to evaluate
-- [Randao](https://github.com/randao/randao): A commit reveal scheme where users must stake wei to participate
+- [RANDAO](https://github.com/randao/randao): A commit reveal scheme where users must stake wei to participate
 
 ## Examples
 
 - The `random` function in [theRun](theRun_source_code/theRun.sol) was vulnerable to this attack. It used the blockhash, timestamp and block number to generate numbers in a range to determine winners of the lottery. To exploit this, an attacker could set up a smart contract that generates numbers in the same way and submits entries when it would win. As well, the miner of the block has some control over the blockhash and timestamp and would also be able to influence the lottery in their favor.
 
 ## Sources
 
-- https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract
-- https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620
+- [StackExchange](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract)
+- [Blog Post](https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620)

not-so-smart-contracts/solidity/denial_of_service/README.md

@@ -1,8 +1,6 @@
 # Denial of Service
 
-A malicious contract can permanently stall another contract by failing
-in a strategic way. In particular, contracts that bulk perform transactions or updates using
-a `for` loop can be DoS'd if a call to another contract or `transfer` fails during the loop. 
+A malicious contract can permanently stall another contract by failing in a strategic way. In particular, contracts that bulk perform transactions or updates using a `for` loop can be DoS'd if a call to another contract or `transfer` fails during the loop. 
 
 ## Attack Scenarios
 
@@ -19,7 +17,7 @@ might run out of gas and revert.
 
 - Both [insecure](auction.sol#L4) and [secure](auction.sol#L26) versions of the auction contract mentioned above
 
-- Bulk refund functionality that is [suceptible to DoS](list_dos.sol#L3), and a [secure](list_dos.sol#L29) version
+- Bulk refund functionality that is [susceptible to DoS](list_dos.sol#L3), and a [secure](list_dos.sol#L29) version
 
 ## Mitigations
 

not-so-smart-contracts/solidity/forced_ether_reception/README.md

@@ -1,6 +1,6 @@
 # Contracts can be forced to receive ether
 
-In certain circunstances, contracts can be forced to receive ether without triggering any code. This should be considered by the contract developers in order to avoid breaking important invariants in their code.
+In certain circumstances, contracts can be forced to receive ether without triggering any code. This should be considered by the contract developers in order to avoid breaking important invariants in their code.
 
 ## Attack Scenario
 

not-so-smart-contracts/solidity/honeypots/README.md

@@ -23,7 +23,7 @@ The contract takes advantage of the fact that the global variable balance on the
 
 The contract appears vulnerable to a constructor mismatch, allowing anyone to call the public method `Test1()` and double any ether they send to the function. The calculation involves a while loop which is strange, but the bounds conditions seem correct enough.
 
-One of the features of Solidity is that it seeks to mimic JavaScript in its language syntax and style. This is ostensibly to ease onboarding of developers with something familiar. In this case, the contract takes advantage of different semantics between Solidity and JavaScript to create type confusion. The var keyword allows the compiler to infer the type of the assignment when declaring a variable. In this instance, `i1` and `i2` are resolved to fact be `uint8`. As such, their maximum value will be 255 before overflow -- causing the loop condition `if(i1<i2)` to fail, sending at most 255 wei to the caller before terminating.
+One of the features of Solidity is that it seeks to mimic JavaScript in its language syntax and style. This is ostensibly to ease on-boarding of developers with something familiar. In this case, the contract takes advantage of different semantics between Solidity and JavaScript to create type confusion. The var keyword allows the compiler to infer the type of the assignment when declaring a variable. In this instance, `i1` and `i2` are resolved to fact be `uint8`. As such, their maximum value will be 255 before overflow -- causing the loop condition `if(i1<i2)` to fail, sending at most 255 wei to the caller before terminating.
 
 Fortunately the var keyword has been deprecated by the Solidity authors. 
 

not-so-smart-contracts/solidity/incorrect_erc20_interface/README.md

@@ -1,4 +1,4 @@
-## Incorrect erc20 interface
+## Incorrect ERC20 interface
 
 ### Description
 Incorrect return values for ERC20 functions. A contract compiled with solidity > 0.4.22 interacting with these functions will fail to execute them, as the return value is missing.
@@ -16,6 +16,4 @@ contract Token{
 ### Recommendation
 - Set the appropriate return values and value-types for the defined ERC20 functions.
 - Use [Slither](https://github.com/crytic/slither/) or [crytic.io](https://crytic.io/) to detect the issue
-- Use `slither-check-erc` to ensure ERC's conformance
-
-
+- Use `slither-check-erc` to ensure ERC conformance

not-so-smart-contracts/solidity/incorrect_erc721_interface/README.md

@@ -1,4 +1,4 @@
-## Incorrect erc721 interface
+## Incorrect ERC721 interface
 
 ### Description
 Incorrect return values for ERC721 functions. A contract compiled with solidity > 0.4.22 interacting with these functions will fail to execute them, as the return value is missing.

not-so-smart-contracts/solidity/incorrect_interface/README.md

@@ -1,14 +1,14 @@
 # Incorrect interface
 A contract interface defines functions with a different type signature than the implementation, causing two different method id's to be created.
-As a result, when the interfact is called, the fallback method will be executed.
+As a result, when the interface is called, the fallback method will be executed.
 
 ## Attack Scenario
 
-- The interface is incorrectly defined. `Alice.set(uint)` takes an `uint` in `Bob.sol` but `Alice.set(int)` a `int` in `Alice.sol`. The two interfaces will produce two differents method IDs. As a result, Bob will call the fallback function of Alice rather than of `set`.
+- The interface is incorrectly defined. `Alice.set(uint)` takes an `uint` in `Bob.sol` but `Alice.set(int)` a `int` in `Alice.sol`. The two interfaces will produce two different method IDs. As a result, Bob will call the fallback function of Alice rather than of `set`.
 
 ## Mitigations
 
-Verify that type signatures are identical between inferfaces and implementations.
+Verify that type signatures are identical between interfaces and implementations.
 
 ## Example
 
@@ -79,4 +79,3 @@ bob.set_fixed(alice.address, {from: eth.accounts[0]} )
 alice.val()
 ```
 
-

not-so-smart-contracts/solidity/reentrancy/README.md

@@ -1,4 +1,4 @@
-# Re-entrancy
+# Reentrancy
 A state variable is changed after a contract uses `call.value`. The attacker uses
 [a fallback function](ReentrancyExploit.sol#L26-L33)—which is automatically executed after
 Ether is transferred from the targeted contract—to execute the vulnerable function again, *before* the

not-so-smart-contracts/solidity/uninitialized-storage/README.md

@@ -2,7 +2,7 @@
 ## Uninitialized storage variables
 
 ### Description
-An uinitialized storage variable will act as a reference to the first state variable, and can override a critical variable.
+An uninitialized storage variable will act as a reference to the first state variable, and can override a critical variable.
 
 ### Exploit Scenario:
 
@@ -27,4 +27,3 @@ Bob calls `func`. As a result, `owner` is override to 0.
 - Initialize all the storage variables.
 - Use [Slither](https://github.com/crytic/slither/) or [crytic.io](https://crytic.io/) to detect the issue
 
-