Merge pull request #986 from JSON/patch-1

Doc clean-ups (typos, links, etc.)

README.md

@@ -2,7 +2,7 @@
 
 [![Join the chat at https://gitter.im/ethereum/sharding](https://badges.gitter.im/ethereum/sharding.svg)](https://gitter.im/ethereum/sharding?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
 
-To learn more about sharding and eth2.0/Serenity, see the [sharding FAQ](https://github.com/ethereum/wiki/wiki/Sharding-FAQs) and the [research compendium](https://notes.ethereum.org/s/H1PGqDhpm).
+To learn more about sharding and eth2.0/Serenity, see the [sharding FAQ](https://github.com/ethereum/wiki/wiki/Sharding-FAQ) and the [research compendium](https://notes.ethereum.org/s/H1PGqDhpm).
 
 This repo hosts the current eth2.0 specifications. Discussions about design rationale and proposed changes can be brought up and discussed as issues. Solidified, agreed upon changes to spec can be made through pull requests.
 
@@ -11,10 +11,10 @@ This repo hosts the current eth2.0 specifications. Discussions about design rati
 
 Core specifications for eth2.0 client validation can be found in [specs/core](specs/core). These are divided into phases. Each subsequent phase depends upon the prior. The current phases specified are:
 * [Phase 0 -- The Beacon Chain](specs/core/0_beacon-chain.md)
-* [Phase 1 -- Custody game](specs/core/1_custody-game.md)
+* [Phase 1 -- Custody Game](specs/core/1_custody-game.md)
 * [Phase 1 -- Shard Data Chains](specs/core/1_shard-data-chains.md)
 
-Accompanying documents can be found in [specs](specs) and include
+Accompanying documents can be found in [specs](specs) and include:
 * [SimpleSerialize (SSZ) spec](specs/simple-serialize.md)
 * [BLS signature verification](specs/bls_signature.md)
 * [General test format](specs/test_formats/README.md)

specs/bls_signature.md

@@ -86,7 +86,7 @@ def hash_to_G2(message_hash: Bytes32, domain: uint64) -> [uint384]:
 
 ### `modular_squareroot`
 
-`modular_squareroot(x)` returns a solution `y` to `y**2 % q == x`, and `None` if none exists. If there are two solutions the one with higher imaginary component is favored; if both solutions have equal imaginary component the one with higher real component is favored (note that this is equivalent to saying that the single solution with either imaginary component > p/2 or imaginary component zero and real component > p/2 is favored).
+`modular_squareroot(x)` returns a solution `y` to `y**2 % q == x`, and `None` if none exists. If there are two solutions, the one with higher imaginary component is favored; if both solutions have equal imaginary component, the one with higher real component is favored (note that this is equivalent to saying that the single solution with either imaginary component > p/2 or imaginary component zero and real component > p/2 is favored).
 
 The following is a sample implementation; implementers are free to implement modular square roots as they wish. Note that `x2 = -x1` is an _additive modular inverse_ so real and imaginary coefficients remain in `[0 .. q-1]`. `coerce_to_int(element: Fq) -> int` is a function that takes Fq element `element` (i.e. integers `mod q`) and converts it to a regular integer.
 

specs/core/0_beacon-chain.md

@@ -1,6 +1,6 @@
 # Ethereum 2.0 Phase 0 -- The Beacon Chain
 
-**NOTICE**: This document is a work in progress for researchers and implementers. It reflects recent spec changes and takes precedence over the Python proof-of-concept implementation [[python-poc]](#ref-python-poc).
+**NOTICE**: This document is a work in progress for researchers and implementers. It reflects recent spec changes and takes precedence over the Python proof-of-concept implementation [[python-poc]](https://github.com/ethereum/beacon_chain).
 
 ## Table of contents
 <!-- TOC -->

specs/networking/rpc-interface.md

@@ -247,7 +247,7 @@ Requests a list of block roots and slots from the peer. The `count` parameter MU
 
 Requests beacon block headers from the peer starting from `(start_root, start_slot)`. The response MUST contain no more than `max_headers` headers. `skip_slots` defines the maximum number of slots to skip between blocks. For example, requesting blocks starting at slots `2` a `skip_slots` value of `1` would return the blocks at `[2, 4, 6, 8, 10]`. In cases where a slot is empty for a given slot number, the closest previous block MUST be returned. For example, if slot `4` were empty in the previous example, the returned array would contain `[2, 3, 6, 8, 10]`. If slot three were further empty, the array would contain `[2, 6, 8, 10]` - i.e., duplicate blocks MUST be collapsed. A `skip_slots` value of `0` returns all blocks.
 
-The function of the `skip_slots` parameter helps facilitate light client sync - for example, in [#459](https://github.com/ethereum/eth2.0-specs/issues/459) - and allows clients to balance the peers from whom they request headers. Clients could, for instance, request every 10th block from a set of peers where each per has a different starting block in order to populate block data.
+The function of the `skip_slots` parameter helps facilitate light client sync - for example, in [#459](https://github.com/ethereum/eth2.0-specs/issues/459) - and allows clients to balance the peers from whom they request headers. Clients could, for instance, request every 10th block from a set of peers where each peer has a different starting block in order to populate block data.
 
 ### Beacon Block Bodies
 
@@ -287,6 +287,6 @@ Requests the `block_bodies` associated with the provided `block_roots` from the
 
 **Response Body:** TBD
 
-Requests contain the hashes of Merkle tree nodes that when merkelized yield the block's `state_root`.
+Requests contain the hashes of Merkle tree nodes that when merkleized yield the block's `state_root`.
 
 The response will contain the values that, when hashed, yield the hashes inside the request body.

specs/test_formats/README.md

@@ -118,7 +118,7 @@ Separation of configuration and tests aims to:
   Note: Some clients prefer compile-time constants and optimizations.
   They should compile for each configuration once, and run the corresponding tests per build target.
 
-The format is described in `configs/constant_presets`.
+The format is described in [`configs/constant_presets`](../../configs/constant_presets/README.md#format).
 
 
 ## Fork-timeline
@@ -129,7 +129,7 @@ A fork timeline is (preferably) loaded in as a configuration object into a clien
  - we may decide on an epoch number for a fork based on external events (e.g. Eth1 log event),
     a client should be able to activate a fork dynamically.
 
-The format is described in `configs/fork_timelines`.
+The format is described in [`configs/fork_timelines`](../../configs/fork_timelines/README.md#format).
 
 ## Config sourcing
 

specs/test_formats/bls/msg_hash_g2_compressed.md

@@ -11,7 +11,7 @@ input:
 output: List[bytes48] -- length of two
 ```
 
-All byte(s) fields are encoded as strings, hexadecimal encoding, prefixed with `0x`
+All byte(s) fields are encoded as strings, hexadecimal encoding, prefixed with `0x`.
 
 
 ## Condition

specs/test_formats/bls/msg_hash_g2_uncompressed.md

@@ -11,7 +11,7 @@ input:
 output: List[List[bytes48]] -- 3 lists, each a length of two
 ```
 
-All byte(s) fields are encoded as strings, hexadecimal encoding, prefixed with `0x`
+All byte(s) fields are encoded as strings, hexadecimal encoding, prefixed with `0x`.
 
 
 ## Condition

specs/test_formats/bls/priv_to_pub.md

@@ -9,7 +9,7 @@ input: bytes32 -- the private key
 output: bytes48 -- the public key
 ```
 
-All byte(s) fields are encoded as strings, hexadecimal encoding, prefixed with `0x`
+All byte(s) fields are encoded as strings, hexadecimal encoding, prefixed with `0x`.
 
 
 ## Condition

specs/test_formats/bls/sign_msg.md

@@ -12,7 +12,7 @@ input:
 output: bytes96    -- expected signature
 ```
 
-All byte(s) fields are encoded as strings, hexadecimal encoding, prefixed with `0x`
+All byte(s) fields are encoded as strings, hexadecimal encoding, prefixed with `0x`.
 
 
 ## Condition

specs/test_formats/ssz_static/core.md

@@ -1,6 +1,6 @@
 # Test format: SSZ static types
 
-The goal of this type is to provide clients with a solid reference how the known SSZ objects should be encoded.
+The goal of this type is to provide clients with a solid reference for how the known SSZ objects should be encoded.
 Each object described in the Phase-0 spec is covered.
 This is important, as many of the clients aiming to serialize/deserialize objects directly into structs/classes
 do not support (or have alternatives for) generic SSZ encoding/decoding.
@@ -27,6 +27,6 @@ A test-runner can implement the following assertions:
 ## References
 
 
-**`serialized`**: [SSZ serialization](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/simple-serialize.md#serialization)   
-**`root`** - [hash_tree_root](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/simple-serialize.md#merkleization) function  
-**`signing_root`** - [signing_root](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/simple-serialize.md#self-signed-containers) function
+**`serialized`**: [SSZ serialization](../../simple-serialize.md#serialization)   
+**`root`** - [hash_tree_root](../../simple-serialize.md#merkleization) function  
+**`signing_root`** - [signing_root](../../simple-serialize.md#self-signed-containers) function

test_generators/ssz_static/README.md

@@ -1,6 +1,6 @@
 # SSZ-static
 
 The purpose of this test-generator is to provide test-vectors for the most important applications of SSZ:
- the serialization and hashing of ETH 2.0 data types
+ the serialization and hashing of ETH 2.0 data types.
 
 Test-format documentation can be found [here](../../specs/test_formats/ssz_static/README.md).

test_libs/pyspec/README.md

@@ -58,4 +58,4 @@ The pyspec is not a replacement.
 
 ## License
 
-Same as the spec itself, see LICENSE file in spec repository root.
+Same as the spec itself, see [LICENSE](../../LICENSE) file in spec repository root.