Merge pull request #648 from OffchainLabs/refactor-docs

Update docs

docs/Dispute_Resolution.md

@@ -12,28 +12,25 @@ To advance a chain’s VM, any validator of the Arbitrum chain can make a disput
 
 ## How a chain advances: the malicious case
 
-The challenging case arises when a dishonest validator tries to cheat.  There are two things a dishonest validator might try to do.  First, they might try to corrupt the execution of the chain by making a disputable assertion that is false in the hopes that the EthBridge will accept that assertion. Second, they might let somebody else make a truthful disputable assertion and then start a bogus dispute about it.
+The challenging case arises when a dishonest validator tries to cheat. There are two things a dishonest validator might try to do. First, they might try to corrupt the execution of the chain by making a disputable assertion that is false in the hopes that the EthBridge will accept that assertion. Second, they might let somebody else make a truthful disputable assertion and then start a bogus dispute about it.
 
 Arbitrum deters misbehavior by requiring validators who make or challenge an assertion to put down a currency stake that is held by the EthBridge. If a validator gets caught cheating, it will forfeit its stake. (Half of the cheater’s stake goes to the other party in the dispute. The other half is burned. Validators who haven’t been caught cheating can get their stake back, once the challenge period for the thing they’re staked on has passed.)
 
 Arbitrum’s dispute resolution protocol is designed to resolve disputes very efficiently, by identifying a cheating party while requiring a minimum of on-chain Ethereum activity. The dispute plays out as a contest between an asserter (who claims their disputable assertion is correct) and a challenger (who claims that the same assertion is wrong), with the EthBridge acting as referee.
 
-
-
 ## Dispute resolution
 
 The dispute resolution protocol goes in two stages. First, the players narrow down their disagreement, using an on-chain bisection protocol, until they are disagreeing about a single step of the VM’s computation. Then the asserter sends a one-step proof—a proof of correctness for the execution of a single VM instruction—to the EthBridge which checks that tiny proof.
 
-The bisection protocol starts when the asserter claims that a VM starting with state-hash X can execute N instructions, resulting in state-hash Y, and the challenger responds that this is false. 
-The asserter is required to divide their assertion into K assertions, each involving the execution of N/K instructions, which fit together to give the initial assertion. Then the challenger has to pick one of those K smaller assertions to challenge. If either player fails to act within a specified time limit measured in a number of blocks, they lose. After one round of K-way division, the size of the dispute has been cut to N/K steps.  
+The bisection protocol starts when the asserter claims that a VM starting with state-hash X can execute N instructions, resulting in state-hash Y, and the challenger responds that this is false.
+The asserter is required to divide their assertion into K assertions, each involving the execution of N/K instructions, which fit together to give the initial assertion. Then the challenger has to pick one of those K smaller assertions to challenge. If either player fails to act within a specified time limit measured in a number of blocks, they lose. After one round of K-way division, the size of the dispute has been cut to N/K steps.
 
 The process continues with further divisions. After a logarithmic number of divisions (logarithmic in the number of instructions executed, N), the dispute has been narrowed to a single step: the dispute will be over whether or not a VM starting with state-hash Y can execute a single instruction to get to the state-hash Z.
 
-At this point the asserter has to give a one-step proof to the EthBridge, containing the information that the EthBridge needs to quickly verify that the one-step assertion is correct.  Or perhaps the asserter will fail to provide a valid one-step proof. Either way, the dispute is resolved.
+At this point the asserter has to give a one-step proof to the EthBridge, containing the information that the EthBridge needs to quickly verify that the one-step assertion is correct. Or perhaps the asserter will fail to provide a valid one-step proof. Either way, the dispute is resolved.
 
-![img](http://staging-developer.offchainlabs.com/img/Arbitrum_dispute.png)
+![img](assets/Arbitrum_dispute.png)
 
 We won’t go into the details of one-step proofs here. Suffice it to say that [Arbitrum’s custom VM architecture](AVM_Design.md) comes into play here, making the one-step proof small (a few hundred bytes at most) and quick to check (costing about 90,000 Ethereum gas, or about one dollar at current prices).
 
 By making disputes relatively cheap to resolve, and imposing a substantial penalty on the loser, Arbitrum strongly disincentivizes attempts to cheat, but even if a dispute occurs this doesn’t impose a huge on-chain impact. In the common case, validators will agree and progress will occur off-chain.
-

docs/Public_Testnet.md

@@ -70,7 +70,7 @@ All contracts are deployed from https://github.com/OffchainLabs/arbitrum/tree/v0
 
 #### Important Addresses
 
-- Main L1 Rollup Contract: [ 0xC34Fd04E698dB75f8381BFA7298e8Ae379bFDA71](https://kovan.etherscan.io/address/ 0xC34Fd04E698dB75f8381BFA7298e8Ae379bFDA71)
+- Main L1 Rollup Contract: [0xC34Fd04E698dB75f8381BFA7298e8Ae379bFDA71](https://kovan.etherscan.io/address/0xC34Fd04E698dB75f8381BFA7298e8Ae379bFDA71)
 - Our Hosted Aggregator Address: [0x569753e1d905ba9e74abdd65f4d41d80a0ce4dfc](https://kovan.etherscan.io/address/0x1d143638962dc93c52c4053a3dcce71cccb30bd3)
 - Our Hosted Validator Address: [0x51eefd904c9317ef4a242de47cd48c9183f60143](https://kovan.etherscan.io/address/0x705c33d9364dd570bc2998a1a1e788221c14d2da)