From 1d44023731e6f0d23c123e02893e313bece1e47a Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Mon, 14 Jan 2019 21:25:23 -0600
Subject: [PATCH 01/44] initial pass on phase 0 validator doc

---
 specs/validator/0_beacon-chain-validator.md | 278 ++++++++++++++++++++
 1 file changed, 278 insertions(+)
 create mode 100644 specs/validator/0_beacon-chain-validator.md

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
new file mode 100644
index 000000000..c34a76ee3
--- /dev/null
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -0,0 +1,278 @@
+# Ethereum 2.0 Phase 0 -- Honest Validator
+
+__NOTICE__: This document is a work-in-progress for researchers and implementers. This is an accompanying document to [Ethereum 2.0 Phase 0 -- The Beacon Chain](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md) that describes the expected actions of a "validator" participating in the Ethereum 2.0 protocol.
+
+## Table of Contents
+
+## Introduction
+
+This document represents the expected behavior of an "honest validator" with respect to Phase 0 of the Ethereum 2.0 protocol. This document does not distinguish between a "node" and a "validator client". The separation of concerns between these (potentially) two pieces of software is left as a design decision that is outside of scope.
+
+A validator is an entity that participates in the consensus of the Ethereum 2.0 protocol. This is an optional role for users in which they can post ETH as collateral to seek financial returns in exchange for building and securing the protocol. This is similar to proof of work networks in which a miner provides collateral in the form of hardware/hash-power to seek returns in exchange for building and securing the protocol.
+
+## Prerequisites
+
+All terminology, constants, functions, and protocol mechanics defined in the [Phase 0 -- The Beacon Chain](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md) doc are requisite for this document and used throughout. Please see the Phase 0 doc before continuing and use as a reference throughout.
+
+## Becoming a validator
+
+### Initialization
+
+A validator must initial many parameters locally before submitting a deposit and joining the validator registry.
+
+#### BLS public key
+
+Validator public keys are [G1 points](https://github.com/ethereum/eth2.0-specs/blob/master/specs/bls_signature.md#g1-points) on the [BLS12-381 curve](https://z.cash/blog/new-snark-curve). A private key, `privkey`, must be securely generated along with the resultant `pubkey`. This `privkey` must be "hot", that is, constantly available to sign data throughout the lifetime of the validator.
+
+#### BLS withdrawal key
+
+A secondary withdrawal private key, `withdrawal_privkey`, must also be securely generated along with the resultant `withdrawal_pubkey`. This `withdrawal_privkey` does not have to be available for signing during the normal lifetime of a validator and can live in "cold storage".
+
+The validator constructs their `withdrawal_credentials` through the following:
+* Set `withdrawal_credentials[:1] == BLS_WITHDRAWAL_PREFIX_BYTE`.
+* Set `withdrawal_credentials[1:] == hash(withdrawal_pubkey)[1:]`.
+
+#### RANDAO commitment
+
+A validator's RANDAO commitment is the outermost layer of a 32-byte hash-onion. To create this commitment, perform the following steps:
+
+* Randomly generate a 32-byte `randao_seed`.
+* Store this `randao_seed` in a secure location.
+* Calculate `randao_commitment = repeat_hash(randao_seed, n)` where `n` is large enough such that within the lifetime of the validator, the validator will not propose more than `n` beacon chain blocks.
+
+Assuming `>= 100k validators`, on average a validator will have an opportunity to reveal once every `>= 600k seconds`, so `<= 50 times per year`. At this estimate, `n == 5000` would last a century. To be conservative, we recommend `n >= 100k`.
+
+_Note_: A validator must be able to reveal the next layer deep from their current commitment at any time. There are many strategies that trade off space and computation to be able to provide this reveal. At one end of this trade-off, a validator might only store their `randao_seed` and repeat the `repeat_hash` calculation on the fly to re-calculate the layer `n-1` for the reveal. On the other end of this trade-off, a validator might store _all_ layers of the hash-onion and not have to perform any calculations to retrieve the layer `n-1`. A more sensible strategy might be to store every `m`th layer as cached references to recalculate the intermittent layers as needed.
+
+#### Custody commitment
+
+A validator's custody commitment is the outermost layer of a 32-byte hash-onion. To create this commitment, perform the following steps:
+
+* Randomly generate a 32-byte `custody_seed`.
+* Store this `custody_seed` in a secutre location.
+* Calculate `custody_commitment = repeat_hash(custody_seed, n)` where `n` is large enough such that within the lifetime of the validator, the validator will not attest to more than `n` beacon chain blocks.
+
+Assuming a validator changes their `custody_seed` with frequency `>= 1 week`, the validator changes their seed approximately `<= 50 times per year`. At this estimate, `n == 5000` would last a century. To be conservative, we recommend `n >= 100k`.
+
+See above note on hash-onion caching strategies in [RANDAO commitment]().
+
+_Note_: although this commitment is being committed to and stored in phase 0, it will not be used until phase 1.
+
+### Deposit
+
+In phase 0, all incoming validator deposits originate from the Ethereum 1.0 PoW chain. Deposits are made to the [deposit contract](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#ethereum-10-deposit-contract) located at `DEPOSIT_CONTRACT_ADDRESS`. 
+
+To submit a deposit:
+
+* Pack the validator's [initialization parameters]() into `deposit_input`, a [`DepositInput`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#depositinput) object.
+* Set `deposit_input.proof_of_possession = EMPTY_SIGNATURE`.
+* Let `proof_of_possession` be the result of `bls_sign` of the `hash_tree_root(deposit_input)` with `domain=DOMAIN_DEPOSIT`.
+* Set `deposit_input.proof_of_possession = proof_of_possession`.
+* Send a transaction on the Ethereum 1.0 chain to `DEPOSIT_CONTRACT_ADDRESS` executing `deposit` along with `deposit_input` as the singular `bytes` input along with a deposit `amount` in ETH.
+
+### Validator index
+
+Once a validator has been added to the state's `validator_registry`, the validator's `validator_index` is defined by the index into the registry at which the [`ValidatorRecord`]() contains the `pubkey` specified in the validator's deposit. This `validator_index` is used throughout the specification to dictate validator roles and responsibilities at any point and should be stored locally.
+
+### Activation
+
+A validator is activated some amount of slots after being added to the registry. There is a maximum validator churn per finalized epoch so the delay until activation is variable depending upon finality, total active validator balance, and the number of validators in the queue to be activated.
+
+The function [`is_active_validator`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#is_active_validator) can be used to check if a validator is active at a given slot. Usage is as follows:
+
+```python
+validator = state.validator_registry[validator_index]
+is_active_validator(validator, slot)
+```
+
+Once a validator is active, the validator is assigned [responsibilities]() until exited.
+
+## Beacon chain responsibilities
+
+A validator has two primary responsibilities to the beacon chain -- [proposing blocks]() and [creating attestations](). Proposals happen infrequently, whereas attestations should be created once per epoch.
+
+### Block proposal
+
+A validator is expected to propose a [`BeaconBlock`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#beaconblock) at the beginning of any slot during which `get_beacon_proposer_index(state, slot)` returns the validator's `validator_index`. To propose, the validator selects the `BeaconBlock`, `parent`, that in their view of the fork choice is the head of the chain during `slot`. The validator is to create, sign, and broadcast a `block` that is a child of `parent` that creates a valid [beacon chain state transition](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#beacon-chain-state-transition-function).
+
+#### Block header
+
+##### Slot
+
+Set `block.slot = slot` where `slot` is the current slot at which the validator has been selected to propose. The `parent` selected must satisfy that `parent.slot < block.slot`.
+
+_Note:_ there might be "skipped" slots between the `parent` and `block`. These skipped slots are processed in the state transition function without per-block processing.
+
+##### Parent root
+
+Set `block.parent_root = hash_tree_root(parent)`.
+
+##### State root
+
+Set `block.state_root = hash_tree_root(state)` of the resulting `state` of the `parent -> block` state transition.
+
+_Note_: To calculate `state_root`, the validator should first run the state transition function on an unsigned `block` containing a stub for the `state_root`. It is useful to be able to run a state transition function that does _not_ validate signatures for this purpose.
+
+##### Randao reveal
+
+Set `block.randao_reveal` to the `n`th layer deep reveal from the validator's current `randao_commitment` where `n = validator.randao_layers + 1`. `block.randao_reveal` should satisfy `repeat_hash(block.randao_reveal, validator.randao_layers + 1) == validator.randao_commitment`.
+
+##### Deposit root
+
+##### Signature
+
+Set `block.signature = signed_proposal_data` where `signed_proposal_data` is defined as:
+
+```python
+proposal_data = ProposalSignedData(
+    slot=slot,
+    shard=BEACON_CHAIN_SHARD_NUMBER,
+    block_root=hash_tree_root(block),  # where `block.sigature == EMPTY_SIGNATURE
+)
+proposal_root = hash_tree_root(proposal_data)
+
+signed_proposal_data = bls_sign(
+    privkey=validator.privkey,  # privkey store locally, not in state
+    message=proposal_root,
+    domain=get_domain(
+        state.fork_data,  # `state` is the resulting state of `block` transition
+        state.slot,
+        DOMAIN_PROPOSAL,
+    )
+)
+```
+
+#### Block body
+
+##### Proposer slashings
+
+##### Casper slashings
+
+##### Attestations
+
+Up to `MAX_ATTESTATIONS` aggregate attestations can be added to the `block`. The attestations added must satify the verification conditions found in [attestation processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestations-1). To maximize profit, the validator should attempt to add aggregate attestations that include the most available that have not previously been added on chain.
+
+##### Deposits
+
+##### Exits
+
+### Attestations
+
+A validator is expected to create, sign, and broadcast an attestion during each epoch. The slot during which the validator performs this roal is any slot at which `get_shard_committees_at_slot(state, slot)` contains a committee that contains `validator_index`.
+
+A validator should create and broadcast the attestation halfway through the `slot` during which the validator is assigned -- that is `SLOT_DURATION * 0.5` seconds after the start of `slot`.
+
+#### Attestation data
+
+First the validator should construct `attestation_data`, an [`AttestationData`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestationdata) object based upon the state at the assigned slot.
+
+##### Slot
+
+Set `attestation_data.slot = slot` where `slot` is the current slot of which the validator is a member of a committee.
+
+##### Shard
+
+Set `attestation_data.shard = shard` where `shard` is the shard associated with the validator's committee defined by `get_shard_committees_at_slot`.
+
+##### Beacon block root
+
+Set `attestation_data.beacon_block_root = hash_tree_root(head)` where `head` is the validator's view of the `head` block of the beacon chain during `slot`.
+
+##### Epoch boundary root
+
+Set `attestation_data.epoch_boundary_root = hash_tree_root(epoch_boundary)` where `epoch_boundary` is the block at the most recent epoch boundary in the chain defined by `head` -- i.e. the `BeaconBlock` with `slot == head.slot - head.slot % EPOCH_LENGTH`.
+
+_Note:_ This can be looked up in the state using `get_block_root(state, head.slot - head.slot % EPOCH_LENGTH)`.
+
+##### Shard block root
+
+Set `attestation_data.shard_block_root = ZERO_HASH`.
+
+_Note:_ This is a stub for phase 0.
+
+##### Latest crosslink root
+
+Set `attestation_data.latest_crosslink_root = state.latest_crosslinks[shard].shard_block_root` where `state` is the beacon state at `head` and `shard` is the validator's assigned shard.
+
+##### Justified slot
+
+Set `attestation_data.justified_slot = state.justified_slot` where `state` is the beacon state at `head`.
+
+##### Justified block root
+
+Set `attestation_data.justified_block_root = hash_tree_root(justified_block)` where `justified_block` is the block at `state.justified_slot` in the chain defined by `head`.
+
+_Note:_ This can be looked up in the state using `get_block_root(state, justified_slot)`.
+
+#### Construct attestation
+
+Next the validator creates `attestation`, an [`Attestation`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestation) object.
+
+##### Data
+
+Set `attestation.data = attestation_data` where `attestation_data` is the `AttestationData` object defined in the [previous section]().
+
+##### Participation bitfield
+
+* Let `participation_bitfield` be a byte array filled with zeros of length `(len(committee) + 7) // 8`.
+* Let `index_into_committee` be the index into the validator's `committee` at which `validator_index` is located.
+* Set `participation_bitfield[index_into_committee // 8] |= 2 ** (index_into_committee % 8)`.
+* Set `attestation.participation_bitfield = participation_bitfield`.
+
+_Note_: Calling `get_attestation_participants(state, attestation.data, attestation.participation_bitfield)` should return `[validator_index]`.
+
+##### Custody bitfield
+
+* Let `custody_bitfield` be a byte array filled with zeros of length `(len(committee) + 7) // 8`.
+* Set `attestation.custody_bitfield = custody_bitfield`.
+
+_Note:_ This is a stub for phase 0.
+
+##### Aggregate signature
+
+Set `attestation.aggregate_signature = signed_attestation_data` where `signed_attestation_data` is defined as:
+
+```python
+attestation_data_and_custody_bit = AttestationDataAndCustodyBit(
+    attestation.data,
+    False,
+)
+attestation_message_to_sign = hash_tree_root(attestation_data_and_custody_bit)
+
+signed_attestation_data = bls_sign(
+    privkey=validator.privkey,  # privkey store locally, not in state
+    message=attestation_message_to_sign,
+    domain=get_domain(
+        state.fork_data,  # `state` is the state at `head`
+        state.slot,
+        DOMAIN_ATTESTATION,
+    )
+)
+```
+
+## How to avoid slashing
+
+"Slashing" is the burning of some amount of validator funds and immediate ejection from the active validator set. In Phase 0, there are two ways in which funds can be slashed -- [proposal slashing]() and [attestation slashing](). Although being slashed has serious repercussions, it is simple enough to avoid being slashed all together by remaining _consistent_ with respect to the messages you have previously signed.
+
+_Note_: signed data must be within the same `ForkData` context to conflict. Messages cannot be slashed across forks.
+
+### Proposal slashing
+
+To avoid "proposal slashings", a validator must not sign two conflicting [`ProposalSignedData`]() (suggest renaming `ProposalData`) where conflicting is defined as having the same `slot` and `shard` but a different `block_root`.
+
+The following helper can be run to check if two proposal messages conflict:
+
+```python
+def proposal_data_is_slashable(proposal_data_1: ProposalSignedData,
+                               proposal_data_2: ProposalSignedData) -> bool:
+    if (proposal_data_1.slot != proposal_data_2.slot):
+        return False
+    if (proposal_data_1.shard != proposal_data_2.shard):
+        return False
+        
+    return proposal_data_1.block_root != proposal_data_2.block_root
+```
+
+### Casper slashing
+
+To avoid "Casper slashings", a validator must not sign two conflicting [`AttestationData`]() objects where conflicting is defined as a set of two attestations that satisfy either [`is_double_vote`]() or [`is_surround_vote`]().

From 1070ba2d114c072ec948c5b04531b5db1adca9cc Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Tue, 15 Jan 2019 11:33:46 +0800
Subject: [PATCH 02/44] Add ToC

---
 specs/validator/0_beacon-chain-validator.md | 51 +++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index c34a76ee3..77ec0de6a 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -4,6 +4,57 @@ __NOTICE__: This document is a work-in-progress for researchers and implementers
 
 ## Table of Contents
 
+<!-- TOC -->
+
+- [Ethereum 2.0 Phase 0 -- Honest Validator](#ethereum-20-phase-0----honest-validator)
+    - [Table of Contents](#table-of-contents)
+    - [Introduction](#introduction)
+    - [Prerequisites](#prerequisites)
+    - [Becoming a validator](#becoming-a-validator)
+        - [Initialization](#initialization)
+            - [BLS public key](#bls-public-key)
+            - [BLS withdrawal key](#bls-withdrawal-key)
+            - [RANDAO commitment](#randao-commitment)
+            - [Custody commitment](#custody-commitment)
+        - [Deposit](#deposit)
+        - [Validator index](#validator-index)
+        - [Activation](#activation)
+    - [Beacon chain responsibilities](#beacon-chain-responsibilities)
+        - [Block proposal](#block-proposal)
+            - [Block header](#block-header)
+                - [Slot](#slot)
+                - [Parent root](#parent-root)
+                - [State root](#state-root)
+                - [Randao reveal](#randao-reveal)
+                - [Deposit root](#deposit-root)
+                - [Signature](#signature)
+            - [Block body](#block-body)
+                - [Proposer slashings](#proposer-slashings)
+                - [Casper slashings](#casper-slashings)
+                - [Attestations](#attestations)
+                - [Deposits](#deposits)
+                - [Exits](#exits)
+        - [Attestations](#attestations-1)
+            - [Attestation data](#attestation-data)
+                - [Slot](#slot-1)
+                - [Shard](#shard)
+                - [Beacon block root](#beacon-block-root)
+                - [Epoch boundary root](#epoch-boundary-root)
+                - [Shard block root](#shard-block-root)
+                - [Latest crosslink root](#latest-crosslink-root)
+                - [Justified slot](#justified-slot)
+                - [Justified block root](#justified-block-root)
+            - [Construct attestation](#construct-attestation)
+                - [Data](#data)
+                - [Participation bitfield](#participation-bitfield)
+                - [Custody bitfield](#custody-bitfield)
+                - [Aggregate signature](#aggregate-signature)
+    - [How to avoid slashing](#how-to-avoid-slashing)
+        - [Proposal slashing](#proposal-slashing)
+        - [Casper slashing](#casper-slashing)
+
+<!-- /TOC -->
+
 ## Introduction
 
 This document represents the expected behavior of an "honest validator" with respect to Phase 0 of the Ethereum 2.0 protocol. This document does not distinguish between a "node" and a "validator client". The separation of concerns between these (potentially) two pieces of software is left as a design decision that is outside of scope.

From d29ce725db96a534c365f0e50d51ae1ea7e10b79 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Mon, 14 Jan 2019 21:50:34 -0600
Subject: [PATCH 03/44] add deposit root logic in block proposals

---
 specs/validator/0_beacon-chain-validator.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 77ec0de6a..f8d50e051 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -170,6 +170,12 @@ Set `block.randao_reveal` to the `n`th layer deep reveal from the validator's cu
 
 ##### Deposit root
 
+`block.deposit_root` is a mechanism used by block proposers to vote on a recent deposit root found in the Ethereum 1.0 PoW deposit contract. When consensus is formed `state.latest_deposit_root` is updated, and validator deposits up to this root can be processed.
+
+* Let `D` be the set of `DepositRootVote` objects `obj` in `state.deposit_root_votes` where `obj.deposit_root` is the deposit root of an eth1.0 block that is (i) part of the canonical chain, (ii) >= 1000 blocks behind the head, and (iii) newer than `state.latest_deposit_root`.
+* If `D` is empty, set `block.deposit root` to the deposit root of the 1000th ancestor of the head of the canonical eth1.0 chain.
+* If `D` is nonempty, set `block.deposit_root = best_vote.deposit_root` where `best_vote` is the member of `D` that has the highest `vote_count`, breaking ties by favoring newer deposit roots.
+
 ##### Signature
 
 Set `block.signature = signed_proposal_data` where `signed_proposal_data` is defined as:

From 6b72ae3a3b90b663f28f5637891892aa957d3cd4 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Mon, 14 Jan 2019 22:36:33 -0600
Subject: [PATCH 04/44] fill in missing links in phase 0 validator doc

---
 specs/validator/0_beacon-chain-validator.md | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index f8d50e051..e98795b22 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -105,7 +105,7 @@ A validator's custody commitment is the outermost layer of a 32-byte hash-onion.
 
 Assuming a validator changes their `custody_seed` with frequency `>= 1 week`, the validator changes their seed approximately `<= 50 times per year`. At this estimate, `n == 5000` would last a century. To be conservative, we recommend `n >= 100k`.
 
-See above note on hash-onion caching strategies in [RANDAO commitment]().
+See above note on hash-onion caching strategies in [RANDAO commitment](#randao-commitment).
 
 _Note_: although this commitment is being committed to and stored in phase 0, it will not be used until phase 1.
 
@@ -115,15 +115,18 @@ In phase 0, all incoming validator deposits originate from the Ethereum 1.0 PoW
 
 To submit a deposit:
 
-* Pack the validator's [initialization parameters]() into `deposit_input`, a [`DepositInput`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#depositinput) object.
+* Pack the validator's [initialization parameters](#initialization) into `deposit_input`, a [`DepositInput`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#depositinput) object.
 * Set `deposit_input.proof_of_possession = EMPTY_SIGNATURE`.
 * Let `proof_of_possession` be the result of `bls_sign` of the `hash_tree_root(deposit_input)` with `domain=DOMAIN_DEPOSIT`.
 * Set `deposit_input.proof_of_possession = proof_of_possession`.
+* Let `amount` be the amount of eth to be deposited by the validator where `MIN_DEPOSIT <= amount <= MAX_DEPOSIT`.
 * Send a transaction on the Ethereum 1.0 chain to `DEPOSIT_CONTRACT_ADDRESS` executing `deposit` along with `deposit_input` as the singular `bytes` input along with a deposit `amount` in ETH.
 
+_Note_: Multiple deposits can be made by the same validator (same initialization params). A singular `Validator` will be added to `state.validator_registry` with each deposit amount being added to the validator's balance. A validator can only be activated when total deposits meet or exceed 
+
 ### Validator index
 
-Once a validator has been added to the state's `validator_registry`, the validator's `validator_index` is defined by the index into the registry at which the [`ValidatorRecord`]() contains the `pubkey` specified in the validator's deposit. This `validator_index` is used throughout the specification to dictate validator roles and responsibilities at any point and should be stored locally.
+Once a validator has been added to the state's `validator_registry`, the validator's `validator_index` is defined by the index into the registry at which the [`ValidatorRecord`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#validatorrecord) contains the `pubkey` specified in the validator's deposit. This `validator_index` is used throughout the specification to dictate validator roles and responsibilities at any point and should be stored locally.
 
 ### Activation
 
@@ -136,11 +139,11 @@ validator = state.validator_registry[validator_index]
 is_active_validator(validator, slot)
 ```
 
-Once a validator is active, the validator is assigned [responsibilities]() until exited.
+Once a validator is active, the validator is assigned [responsibilities](#beacon-chain-responsibilities) until exited.
 
 ## Beacon chain responsibilities
 
-A validator has two primary responsibilities to the beacon chain -- [proposing blocks]() and [creating attestations](). Proposals happen infrequently, whereas attestations should be created once per epoch.
+A validator has two primary responsibilities to the beacon chain -- [proposing blocks](block-proposal) and [creating attestations](attestations-1). Proposals happen infrequently, whereas attestations should be created once per epoch.
 
 ### Block proposal
 
@@ -267,7 +270,7 @@ Next the validator creates `attestation`, an [`Attestation`](https://github.com/
 
 ##### Data
 
-Set `attestation.data = attestation_data` where `attestation_data` is the `AttestationData` object defined in the [previous section]().
+Set `attestation.data = attestation_data` where `attestation_data` is the `AttestationData` object defined in the previous section, [attestation data](#attestation-data).
 
 ##### Participation bitfield
 
@@ -309,13 +312,13 @@ signed_attestation_data = bls_sign(
 
 ## How to avoid slashing
 
-"Slashing" is the burning of some amount of validator funds and immediate ejection from the active validator set. In Phase 0, there are two ways in which funds can be slashed -- [proposal slashing]() and [attestation slashing](). Although being slashed has serious repercussions, it is simple enough to avoid being slashed all together by remaining _consistent_ with respect to the messages you have previously signed.
+"Slashing" is the burning of some amount of validator funds and immediate ejection from the active validator set. In Phase 0, there are two ways in which funds can be slashed -- [proposal slashing](#proposal-slashing) and [attestation slashing](#casper-slashing). Although being slashed has serious repercussions, it is simple enough to avoid being slashed all together by remaining _consistent_ with respect to the messages you have previously signed.
 
 _Note_: signed data must be within the same `ForkData` context to conflict. Messages cannot be slashed across forks.
 
 ### Proposal slashing
 
-To avoid "proposal slashings", a validator must not sign two conflicting [`ProposalSignedData`]() (suggest renaming `ProposalData`) where conflicting is defined as having the same `slot` and `shard` but a different `block_root`.
+To avoid "proposal slashings", a validator must not sign two conflicting [`ProposalSignedData`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#proposalsigneddata) (suggest renaming `ProposalData`) where conflicting is defined as having the same `slot` and `shard` but a different `block_root`.
 
 The following helper can be run to check if two proposal messages conflict:
 
@@ -332,4 +335,4 @@ def proposal_data_is_slashable(proposal_data_1: ProposalSignedData,
 
 ### Casper slashing
 
-To avoid "Casper slashings", a validator must not sign two conflicting [`AttestationData`]() objects where conflicting is defined as a set of two attestations that satisfy either [`is_double_vote`]() or [`is_surround_vote`]().
+To avoid "Casper slashings", a validator must not sign two conflicting [`AttestationData`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#attestationdata) objects where conflicting is defined as a set of two attestations that satisfy either [`is_double_vote`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#is_double_vote) or [`is_surround_vote`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#is_surround_vote).

From 2881f56c081183a87ac601b2102f972bab4afc07 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Wed, 16 Jan 2019 14:44:58 -0600
Subject: [PATCH 05/44] add pr feedback

---
 specs/validator/0_beacon-chain-validator.md | 24 +++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index e98795b22..c710886f9 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -69,7 +69,7 @@ All terminology, constants, functions, and protocol mechanics defined in the [Ph
 
 ### Initialization
 
-A validator must initial many parameters locally before submitting a deposit and joining the validator registry.
+A validator must initialize many parameters locally before submitting a deposit and joining the validator registry.
 
 #### BLS public key
 
@@ -91,7 +91,7 @@ A validator's RANDAO commitment is the outermost layer of a 32-byte hash-onion.
 * Store this `randao_seed` in a secure location.
 * Calculate `randao_commitment = repeat_hash(randao_seed, n)` where `n` is large enough such that within the lifetime of the validator, the validator will not propose more than `n` beacon chain blocks.
 
-Assuming `>= 100k validators`, on average a validator will have an opportunity to reveal once every `>= 600k seconds`, so `<= 50 times per year`. At this estimate, `n == 5000` would last a century. To be conservative, we recommend `n >= 100k`.
+Assuming `>= 100k validators`, on average a validator will have an opportunity to reveal once every `>= 600k seconds`, so `<= 50 times per year`. At this estimate, `n == 5000` would last a century. If this value is poorly configured and a validator runs out of layers of to reveal, the validator can no longer propose beacon blocks and should exit.
 
 _Note_: A validator must be able to reveal the next layer deep from their current commitment at any time. There are many strategies that trade off space and computation to be able to provide this reveal. At one end of this trade-off, a validator might only store their `randao_seed` and repeat the `repeat_hash` calculation on the fly to re-calculate the layer `n-1` for the reveal. On the other end of this trade-off, a validator might store _all_ layers of the hash-onion and not have to perform any calculations to retrieve the layer `n-1`. A more sensible strategy might be to store every `m`th layer as cached references to recalculate the intermittent layers as needed.
 
@@ -100,10 +100,10 @@ _Note_: A validator must be able to reveal the next layer deep from their curren
 A validator's custody commitment is the outermost layer of a 32-byte hash-onion. To create this commitment, perform the following steps:
 
 * Randomly generate a 32-byte `custody_seed`.
-* Store this `custody_seed` in a secutre location.
+* Store this `custody_seed` in a secure location.
 * Calculate `custody_commitment = repeat_hash(custody_seed, n)` where `n` is large enough such that within the lifetime of the validator, the validator will not attest to more than `n` beacon chain blocks.
 
-Assuming a validator changes their `custody_seed` with frequency `>= 1 week`, the validator changes their seed approximately `<= 50 times per year`. At this estimate, `n == 5000` would last a century. To be conservative, we recommend `n >= 100k`.
+Assuming a validator changes their `custody_seed` with frequency `>= 1 week`, the validator changes their seed approximately `<= 50 times per year`. At this estimate, `n == 5000` would last a century. If this value is poorly configured and a validator runs out of layers of to reveal, the validator can no longer update their `custody_commitment` and should exit.
 
 See above note on hash-onion caching strategies in [RANDAO commitment](#randao-commitment).
 
@@ -218,7 +218,7 @@ Up to `MAX_ATTESTATIONS` aggregate attestations can be added to the `block`. The
 
 ### Attestations
 
-A validator is expected to create, sign, and broadcast an attestion during each epoch. The slot during which the validator performs this roal is any slot at which `get_shard_committees_at_slot(state, slot)` contains a committee that contains `validator_index`.
+A validator is expected to create, sign, and broadcast an attestation during each epoch. The slot during which the validator performs this role is any slot at which `get_shard_committees_at_slot(state, slot)` contains a committee that contains `validator_index`.
 
 A validator should create and broadcast the attestation halfway through the `slot` during which the validator is assigned -- that is `SLOT_DURATION * 0.5` seconds after the start of `slot`.
 
@@ -314,7 +314,7 @@ signed_attestation_data = bls_sign(
 
 "Slashing" is the burning of some amount of validator funds and immediate ejection from the active validator set. In Phase 0, there are two ways in which funds can be slashed -- [proposal slashing](#proposal-slashing) and [attestation slashing](#casper-slashing). Although being slashed has serious repercussions, it is simple enough to avoid being slashed all together by remaining _consistent_ with respect to the messages you have previously signed.
 
-_Note_: signed data must be within the same `ForkData` context to conflict. Messages cannot be slashed across forks.
+_Note_: Signed data must be within the same `Fork` context to conflict. Messages cannot be slashed across forks.
 
 ### Proposal slashing
 
@@ -333,6 +333,18 @@ def proposal_data_is_slashable(proposal_data_1: ProposalSignedData,
     return proposal_data_1.block_root != proposal_data_2.block_root
 ```
 
+Specifically, when signing an `BeaconBlock`, a validator should perform the following steps in the following order:
+1. Save a record to hard disk that an beacon block has been signed for the `slot` and `shard`.
+2. Generate and broadcast the block.
+
+If the software crashes at some point within this routine, then when the validator comes back online the hard disk has the record of the _potentially_ signed/broadcast block and can effectively avoid slashing.
+
 ### Casper slashing
 
 To avoid "Casper slashings", a validator must not sign two conflicting [`AttestationData`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#attestationdata) objects where conflicting is defined as a set of two attestations that satisfy either [`is_double_vote`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#is_double_vote) or [`is_surround_vote`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#is_surround_vote).
+
+Specifically, when signing an `Attestation`, a validator should perform the following steps in the following order:
+1. Save a record to hard disk that an attestation has been signed for source -- `attestation_data.justified_slot // EPOCH_LENGTH` -- and target -- `attestation_data.slot // EPOCH_LENGTH`.
+2. Generate and broadcast attestation.
+
+If the software crashes at some point within this routine, then when the validator comes back online the hard disk has the record of the _potentially_ signed/broadcast attestation and can effectively avoid slashing.

From 40d4ec33cb4455187de3171703ceeab03a43aaba Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Wed, 16 Jan 2019 15:24:59 -0600
Subject: [PATCH 06/44] add basics for all block operations

---
 specs/validator/0_beacon-chain-validator.md | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index c710886f9..40cb0eadd 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -206,16 +206,24 @@ signed_proposal_data = bls_sign(
 
 ##### Proposer slashings
 
+Up to `MAX_PROPOSER_SLASHINGS` [`ProposerSlashing`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#proposerslashing) objects can be included in the `block`. The proposer slashings must satisfy the verification conditions found in [proposer slashings processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#proposer-slashings-1). The validator receives a small "whistleblower" reward for each proposer slashing found and included.
+
 ##### Casper slashings
 
+Up to `MAX_CASPER_SLASHINGS` [`CasperSlashing`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#casperslashing) objects can be included in the `block`. The casper slashings must satisfy the verification conditions found in [casper slashings processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#casper-slashings-1). The validator receives a small "whistleblower" reward for each casper slashing found and included.
+
 ##### Attestations
 
-Up to `MAX_ATTESTATIONS` aggregate attestations can be added to the `block`. The attestations added must satify the verification conditions found in [attestation processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestations-1). To maximize profit, the validator should attempt to add aggregate attestations that include the most available that have not previously been added on chain.
+Up to `MAX_ATTESTATIONS` aggregate attestations can be included in the `block`. The attestations added must satisfy the verification conditions found in [attestation processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestations-1). To maximize profit, the validator should attempt to add aggregate attestations that include the most available that have not previously been added on chain.
 
 ##### Deposits
 
+Up to `MAX_DEPOSITS` [`Deposit`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#deposit) objects can be included in the `block`. These deposits are constructed from the `Deposit` logs from the [Eth1.0 deposit contract](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#ethereum-10-deposit-contract) and must be processed in sequential order. The deposits included in the `block` must satisfy the verification conditions found in [deposits processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#deposits-1).
+
 ##### Exits
 
+Up to `MAX_EXITS` [`Exit`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#exit) objects can be included in the `block`. The exits must satisfy the verification conditions found in [exits processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#exits-1).
+
 ### Attestations
 
 A validator is expected to create, sign, and broadcast an attestation during each epoch. The slot during which the validator performs this role is any slot at which `get_shard_committees_at_slot(state, slot)` contains a committee that contains `validator_index`.

From 7fc5238b8f0a552251739366d696560a7215095b Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Thu, 17 Jan 2019 11:38:56 -0600
Subject: [PATCH 07/44] update deposit root section to utilize eth1data

---
 specs/validator/0_beacon-chain-validator.md | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 40cb0eadd..687c126c7 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -26,7 +26,7 @@ __NOTICE__: This document is a work-in-progress for researchers and implementers
                 - [Parent root](#parent-root)
                 - [State root](#state-root)
                 - [Randao reveal](#randao-reveal)
-                - [Deposit root](#deposit-root)
+                - [Eth1 Data](#eth1-data)
                 - [Signature](#signature)
             - [Block body](#block-body)
                 - [Proposer slashings](#proposer-slashings)
@@ -171,13 +171,21 @@ _Note_: To calculate `state_root`, the validator should first run the state tran
 
 Set `block.randao_reveal` to the `n`th layer deep reveal from the validator's current `randao_commitment` where `n = validator.randao_layers + 1`. `block.randao_reveal` should satisfy `repeat_hash(block.randao_reveal, validator.randao_layers + 1) == validator.randao_commitment`.
 
-##### Deposit root
+##### Eth1 Data
 
-`block.deposit_root` is a mechanism used by block proposers to vote on a recent deposit root found in the Ethereum 1.0 PoW deposit contract. When consensus is formed `state.latest_deposit_root` is updated, and validator deposits up to this root can be processed.
+`block.eth1_data` is a mechanism used by block proposers vote on a recent Ethereum 1.0 block hash and an associated deposit root found in the Ethereum 1.0 deposit contract. When consensus is formed, `state.latest_eth1_data` is updated, and validator deposits up to this root can be processed.
 
-* Let `D` be the set of `DepositRootVote` objects `obj` in `state.deposit_root_votes` where `obj.deposit_root` is the deposit root of an eth1.0 block that is (i) part of the canonical chain, (ii) >= 1000 blocks behind the head, and (iii) newer than `state.latest_deposit_root`.
-* If `D` is empty, set `block.deposit root` to the deposit root of the 1000th ancestor of the head of the canonical eth1.0 chain.
-* If `D` is nonempty, set `block.deposit_root = best_vote.deposit_root` where `best_vote` is the member of `D` that has the highest `vote_count`, breaking ties by favoring newer deposit roots.
+* Let `D` be the set of `Eth1DataVote` objects `vote` in `state.eth1_data_votes` where:
+    * `vote.eth1_data.block_hash` is the hash of an eth1.0 block that is (i) part of the canonical chain, (ii) >= 1000 blocks behind the head, and (iii) newer than `state.latest_eth1_data.block_data`.
+    * `vote.eth1_data.deposit_root` is the deposit root of the eth1.0 deposit contract at the block defined by `vote.eth1_data.block_hash`.
+* If `D` is empty:
+    * Let `block_hash` be the block hash of the 1000th ancestory of the head of the canonical eth1.0 chain.to the deposit root of the 1000th ancestor of the head of the canonical eth1.0 chain.
+    * Let `deposit_root` be the the deposit root of the eth1.0 deposit contract at the block defined by `block_hash`.
+* If `D` is nonempty:
+    * Let `best_vote` be the member of `D` that has the highest `vote.eth1_data.vote_count`, breaking ties by favoring block hashes with higher associated block height.
+    * Let `block_hash = best_vote.eth1_data.block_hash`.
+    * Let `deposit_root = best_vote.eth1_data.deposit_root`.
+* Set `block.eth1_data = Eth1Data(deposit_root=deposit_root, block_hash=block_hash)`.
 
 ##### Signature
 

From b8f48d20a53bee27d4b58c3511178dd5aa6185b3 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Thu, 17 Jan 2019 21:28:14 -0600
Subject: [PATCH 08/44] add follow distance constant and extra details around
 time to being added to the validator registry

---
 specs/validator/0_beacon-chain-validator.md | 27 ++++++++++++++++-----
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 687c126c7..3af9cfebb 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -16,7 +16,8 @@ __NOTICE__: This document is a work-in-progress for researchers and implementers
             - [BLS withdrawal key](#bls-withdrawal-key)
             - [RANDAO commitment](#randao-commitment)
             - [Custody commitment](#custody-commitment)
-        - [Deposit](#deposit)
+        - [Submit deposit](#submit-deposit)
+        - [Process deposit](#process-deposit)
         - [Validator index](#validator-index)
         - [Activation](#activation)
     - [Beacon chain responsibilities](#beacon-chain-responsibilities)
@@ -65,6 +66,14 @@ A validator is an entity that participates in the consensus of the Ethereum 2.0
 
 All terminology, constants, functions, and protocol mechanics defined in the [Phase 0 -- The Beacon Chain](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md) doc are requisite for this document and used throughout. Please see the Phase 0 doc before continuing and use as a reference throughout.
 
+## Constants
+
+### Misc
+
+| Name | Value | Unit | Duration |
+| - | - | :-: |
+| `ETH1_FOLLOW_DISTANCE` | `2**10` (= 1,024) | blocks | ~4 hours |
+
 ## Becoming a validator
 
 ### Initialization
@@ -109,7 +118,7 @@ See above note on hash-onion caching strategies in [RANDAO commitment](#randao-c
 
 _Note_: although this commitment is being committed to and stored in phase 0, it will not be used until phase 1.
 
-### Deposit
+### Submit deposit
 
 In phase 0, all incoming validator deposits originate from the Ethereum 1.0 PoW chain. Deposits are made to the [deposit contract](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#ethereum-10-deposit-contract) located at `DEPOSIT_CONTRACT_ADDRESS`. 
 
@@ -124,13 +133,17 @@ To submit a deposit:
 
 _Note_: Multiple deposits can be made by the same validator (same initialization params). A singular `Validator` will be added to `state.validator_registry` with each deposit amount being added to the validator's balance. A validator can only be activated when total deposits meet or exceed 
 
+### Process deposit
+
+Deposits cannot be processed into the beacon chain until the eth1.0 block in which they were deposited or any of its ancestors is added to the beacon chain `state.eth1_data`. This takes _a minimum_ of `ETH1_FOLLOW_DISTANCE` eth1.0 blocks (~4 hours) plus `ETH1_DATA_VOTING_PERIOD` slots (~1.7 hours). Once the necessary eth1.0 data is added, the deposit will normally be added to a beacon chain block and processed into the `state.validator_registry` within an epoch or two. The validator is then in a queue to be activated.
+
 ### Validator index
 
-Once a validator has been added to the state's `validator_registry`, the validator's `validator_index` is defined by the index into the registry at which the [`ValidatorRecord`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#validatorrecord) contains the `pubkey` specified in the validator's deposit. This `validator_index` is used throughout the specification to dictate validator roles and responsibilities at any point and should be stored locally.
+Once a validator has been processed and added to the state's `validator_registry`, the validator's `validator_index` is defined by the index into the registry at which the [`ValidatorRecord`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#validatorrecord) contains the `pubkey` specified in the validator's deposit. This `validator_index` is used throughout the specification to dictate validator roles and responsibilities at any point and should be stored locally.
 
 ### Activation
 
-A validator is activated some amount of slots after being added to the registry. There is a maximum validator churn per finalized epoch so the delay until activation is variable depending upon finality, total active validator balance, and the number of validators in the queue to be activated.
+In normal operation, the validator is quickly activated at which point the validator is added to the shuffling and begins validation after an additional `ENTRY_EXIT_DELAY` slots.
 
 The function [`is_active_validator`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#is_active_validator) can be used to check if a validator is active at a given slot. Usage is as follows:
 
@@ -141,6 +154,8 @@ is_active_validator(validator, slot)
 
 Once a validator is active, the validator is assigned [responsibilities](#beacon-chain-responsibilities) until exited.
 
+_Note_: There is a maximum validator churn per finalized epoch so the delay until activation is variable depending upon finality, total active validator balance, and the number of validators in the queue to be activated.
+
 ## Beacon chain responsibilities
 
 A validator has two primary responsibilities to the beacon chain -- [proposing blocks](block-proposal) and [creating attestations](attestations-1). Proposals happen infrequently, whereas attestations should be created once per epoch.
@@ -176,10 +191,10 @@ Set `block.randao_reveal` to the `n`th layer deep reveal from the validator's cu
 `block.eth1_data` is a mechanism used by block proposers vote on a recent Ethereum 1.0 block hash and an associated deposit root found in the Ethereum 1.0 deposit contract. When consensus is formed, `state.latest_eth1_data` is updated, and validator deposits up to this root can be processed.
 
 * Let `D` be the set of `Eth1DataVote` objects `vote` in `state.eth1_data_votes` where:
-    * `vote.eth1_data.block_hash` is the hash of an eth1.0 block that is (i) part of the canonical chain, (ii) >= 1000 blocks behind the head, and (iii) newer than `state.latest_eth1_data.block_data`.
+    * `vote.eth1_data.block_hash` is the hash of an eth1.0 block that is (i) part of the canonical chain, (ii) >= `ETH1_FOLLOW_DISTANCE` blocks behind the head, and (iii) newer than `state.latest_eth1_data.block_data`.
     * `vote.eth1_data.deposit_root` is the deposit root of the eth1.0 deposit contract at the block defined by `vote.eth1_data.block_hash`.
 * If `D` is empty:
-    * Let `block_hash` be the block hash of the 1000th ancestory of the head of the canonical eth1.0 chain.to the deposit root of the 1000th ancestor of the head of the canonical eth1.0 chain.
+    * Let `block_hash` be the block hash of the `ETH1_FOLLOW_DISTANCE`th ancestory of the head of the canonical eth1.0 chain.
     * Let `deposit_root` be the the deposit root of the eth1.0 deposit contract at the block defined by `block_hash`.
 * If `D` is nonempty:
     * Let `best_vote` be the member of `D` that has the highest `vote.eth1_data.vote_count`, breaking ties by favoring block hashes with higher associated block height.

From 421ef9e08d67af14766f32ea5e0cda9d9cc3d5e1 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Thu, 17 Jan 2019 21:29:38 -0600
Subject: [PATCH 09/44] fix bad link in v guide

---
 specs/validator/0_beacon-chain-validator.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 3af9cfebb..4b8cd0927 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -349,7 +349,7 @@ _Note_: Signed data must be within the same `Fork` context to conflict. Messages
 
 ### Proposal slashing
 
-To avoid "proposal slashings", a validator must not sign two conflicting [`ProposalSignedData`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#proposalsigneddata) (suggest renaming `ProposalData`) where conflicting is defined as having the same `slot` and `shard` but a different `block_root`.
+To avoid "proposal slashings", a validator must not sign two conflicting [`ProposalSignedData`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#proposalsigneddata) (suggest renaming `ProposalData`) where conflicting is defined as having the same `slot` and `shard` but a different `block_root`.
 
 The following helper can be run to check if two proposal messages conflict:
 
@@ -372,7 +372,7 @@ If the software crashes at some point within this routine, then when the validat
 
 ### Casper slashing
 
-To avoid "Casper slashings", a validator must not sign two conflicting [`AttestationData`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#attestationdata) objects where conflicting is defined as a set of two attestations that satisfy either [`is_double_vote`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#is_double_vote) or [`is_surround_vote`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#is_surround_vote).
+To avoid "Casper slashings", a validator must not sign two conflicting [`AttestationData`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestationdata) objects where conflicting is defined as a set of two attestations that satisfy either [`is_double_vote`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#is_double_vote) or [`is_surround_vote`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#is_surround_vote).
 
 Specifically, when signing an `Attestation`, a validator should perform the following steps in the following order:
 1. Save a record to hard disk that an attestation has been signed for source -- `attestation_data.justified_slot // EPOCH_LENGTH` -- and target -- `attestation_data.slot // EPOCH_LENGTH`.

From 9e75a76fc1f1bbc820269e61441e83ccda471423 Mon Sep 17 00:00:00 2001
From: vbuterin <v@buterin.com>
Date: Fri, 18 Jan 2019 21:06:21 -0600
Subject: [PATCH 10/44] Implement #459

Contents:

* Peg entries and exits to epoch boundaries
* Add a store of historical active index roots
* Mix it into the randomness
* Remove the delta hash chain

Note that the actual light client implementation is beyond the scope of the spec.

[Note to reviewers: verify that the invariant added in the PR is correct]

Question:

* Do we want to also only store epoch-boundary randao values? I don't think we use the epoch-intermediate ones anywhere.....
---
 specs/core/0_beacon-chain.md | 91 ++++++++++++++----------------------
 1 file changed, 35 insertions(+), 56 deletions(-)

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
index 5640340b6..05d138649 100644
--- a/specs/core/0_beacon-chain.md
+++ b/specs/core/0_beacon-chain.md
@@ -18,7 +18,6 @@
         - [Reward and penalty quotients](#reward-and-penalty-quotients)
         - [Status flags](#status-flags)
         - [Max operations per block](#max-operations-per-block)
-        - [Validator registry delta flags](#validator-registry-delta-flags)
         - [Signature domains](#signature-domains)
     - [Data structures](#data-structures)
         - [Beacon chain operations](#beacon-chain-operations)
@@ -47,7 +46,6 @@
             - [`Crosslink`](#crosslink)
             - [`PendingAttestation`](#pendingattestation)
             - [`Fork`](#fork)
-            - [`ValidatorRegistryDeltaBlock`](#validatorregistrydeltablock)
             - [`Eth1Data`](#eth1data)
             - [`Eth1DataVote`](#eth1datavote)
     - [Ethereum 1.0 deposit contract](#ethereum-10-deposit-contract)
@@ -73,6 +71,7 @@
             - [`get_crosslink_committees_at_slot`](#get_crosslink_committees_at_slot)
             - [`get_block_root`](#get_block_root)
             - [`get_randao_mix`](#get_randao_mix)
+            - [`get_active_index_root`](#get_active_index_root)
             - [`get_beacon_proposer_index`](#get_beacon_proposer_index)
             - [`merkle_root`](#merkle_root)
             - [`get_attestation_participants`](#get_attestation_participants)
@@ -168,6 +167,7 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted
 | `MAX_CASPER_VOTES` | `2**10` (= 1,024) | votes |
 | `LATEST_BLOCK_ROOTS_LENGTH` | `2**13` (= 8,192) | block roots |
 | `LATEST_RANDAO_MIXES_LENGTH` | `2**13` (= 8,192) | randao mixes |
+| `LATEST_INDEX_ROOTS_LENGTH` | `2**13` (= 8,192) | index roots |
 | `LATEST_PENALIZED_EXIT_LENGTH` | `2**13` (= 8,192) | epochs | ~36 days |
 | `MAX_WITHDRAWALS_PER_EPOCH` | `2**2` (= 4) | withdrawals |
 
@@ -235,13 +235,6 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted
 | `MAX_DEPOSITS` | `2**4` (= 16) |
 | `MAX_EXITS` | `2**4` (= 16) |
 
-### Validator registry delta flags
-
-| Name | Value |
-| - | - |
-| `ACTIVATION` | `0` |
-| `EXIT` | `1` |
-
 ### Signature domains
 
 | Name | Value |
@@ -478,7 +471,6 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted
     'validator_balances': ['uint64'],
     'validator_registry_update_slot': 'uint64',
     'validator_registry_exit_count': 'uint64',
-    'validator_registry_delta_chain_tip': 'hash32',  # For light clients to track deltas
 
     # Randomness and committees
     'latest_randao_mixes': ['hash32'],
@@ -487,8 +479,8 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted
     'current_epoch_start_shard': 'uint64',
     'previous_epoch_calculation_slot': 'uint64',
     'current_epoch_calculation_slot': 'uint64',
-    'previous_epoch_randao_mix': 'hash32',
-    'current_epoch_randao_mix': 'hash32',
+    'previous_epoch_seed': 'hash32',
+    'current_epoch_seed': 'hash32',
 
     # Custody challenges
     'custody_challenges': [CustodyChallenge],
@@ -502,6 +494,7 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted
     # Recent state
     'latest_crosslinks': [Crosslink],
     'latest_block_roots': ['hash32'],  # Needed to process attestations, older to newer
+    'latest_index_roots': ['hash32'],
     'latest_penalized_balances': ['uint64'],  # Balances penalized at every withdrawal period
     'latest_attestations': [PendingAttestation],
     'batched_block_roots': ['hash32'],
@@ -584,18 +577,6 @@ Unless otherwise indicated, code appearing in `this style` is to be interpreted
 }
 ```
 
-#### `ValidatorRegistryDeltaBlock`
-
-```python
-{
-    'latest_registry_delta_root': 'hash32',
-    'validator_index': 'uint24',
-    'pubkey': 'uint384',
-    'slot': 'uint64',
-    'flag': 'uint64',
-}
-```
-
 #### `Eth1Data`
 
 ```python
@@ -954,7 +935,7 @@ def get_crosslink_committees_at_slot(state: BeaconState,
     if slot < state_epoch_slot:
         committees_per_slot = get_previous_epoch_committee_count_per_slot(state)
         shuffling = get_shuffling(
-            state.previous_epoch_randao_mix,
+            state.previous_epoch_seed,
             state.validator_registry,
             state.previous_epoch_calculation_slot,
         )
@@ -962,7 +943,7 @@ def get_crosslink_committees_at_slot(state: BeaconState,
     else:
         committees_per_slot = get_current_epoch_committee_count_per_slot(state)
         shuffling = get_shuffling(
-            state.current_epoch_randao_mix,
+            state.current_epoch_seed,
             state.validator_registry,
             state.current_epoch_calculation_slot,
         )
@@ -1007,6 +988,19 @@ def get_randao_mix(state: BeaconState,
     return state.latest_randao_mixes[slot % LATEST_RANDAO_MIXES_LENGTH]
 ```
 
+#### `get_active_index_root`
+
+```python
+def get_active_index_root(state: BeaconState,
+                          slot: int) -> Hash32:
+    """
+    Returns the randao mix at a recent ``slot``.
+    """
+    assert state.slot // EPOCH_LENGTH < slot // EPOCH_LENGTH + LATEST_INDEX_ROOTS_LENGTH
+    assert slot // EPOCH_LENGTH <= state.slot // EPOCH_LENGTH
+    return state.latest_index_roots[(slot // EPOCH_LENGTH) % LATEST_INDEX_ROOTS_LENGTH]
+```
+
 #### `get_beacon_proposer_index`
 
 ```python
@@ -1235,7 +1229,6 @@ def get_initial_beacon_state(initial_validator_deposits: List[Deposit],
         validator_balances=[],
         validator_registry_update_slot=GENESIS_SLOT,
         validator_registry_exit_count=0,
-        validator_registry_delta_chain_tip=ZERO_HASH,
 
         # Randomness and committees
         latest_randao_mixes=[ZERO_HASH for _ in range(LATEST_RANDAO_MIXES_LENGTH)],
@@ -1244,8 +1237,8 @@ def get_initial_beacon_state(initial_validator_deposits: List[Deposit],
         current_epoch_start_shard=GENESIS_START_SHARD,
         previous_epoch_calculation_slot=GENESIS_SLOT,
         current_epoch_calculation_slot=GENESIS_SLOT,
-        previous_epoch_randao_mix=ZERO_HASH,
-        current_epoch_randao_mix=ZERO_HASH,
+        previous_epoch_seed=ZERO_HASH,
+        current_epoch_seed=ZERO_HASH,
 
         # Custody challenges
         custody_challenges=[],
@@ -1259,6 +1252,7 @@ def get_initial_beacon_state(initial_validator_deposits: List[Deposit],
         # Recent state
         latest_crosslinks=[Crosslink(slot=GENESIS_SLOT, shard_block_root=ZERO_HASH) for _ in range(SHARD_COUNT)],
         latest_block_roots=[ZERO_HASH for _ in range(LATEST_BLOCK_ROOTS_LENGTH)],
+        latest_index_roots=[ZERO_HASH for _ in range(LATEST_INDEX_ROOTS_LENGTH)],
         latest_penalized_balances=[0 for _ in range(LATEST_PENALIZED_EXIT_LENGTH)],
         latest_attestations=[],
         batched_block_roots=[],
@@ -1383,16 +1377,7 @@ Note: All functions in this section mutate `state`.
 def activate_validator(state: BeaconState, index: int, genesis: bool) -> None:
     validator = state.validator_registry[index]
 
-    validator.activation_slot = GENESIS_SLOT if genesis else (state.slot + ENTRY_EXIT_DELAY)
-    state.validator_registry_delta_chain_tip = hash_tree_root(
-        ValidatorRegistryDeltaBlock(
-            latest_registry_delta_root=state.validator_registry_delta_chain_tip,
-            validator_index=index,
-            pubkey=validator.pubkey,
-            slot=validator.activation_slot,
-            flag=ACTIVATION,
-        )
-    )
+    validator.activation_slot = GENESIS_SLOT if genesis else (state.slot - state.slot % EPOCH_LENGTH + ENTRY_EXIT_DELAY)
 ```
 
 ```python
@@ -1406,22 +1391,13 @@ def exit_validator(state: BeaconState, index: int) -> None:
     validator = state.validator_registry[index]
 
     # The following updates only occur if not previous exited
-    if validator.exit_slot <= state.slot + ENTRY_EXIT_DELAY:
+    if validator.exit_slot <= state.slot - state.slot % EPOCH_LENGTH + ENTRY_EXIT_DELAY:
         return
 
-    validator.exit_slot = state.slot + ENTRY_EXIT_DELAY
+    validator.exit_slot = state.slot - state.slot % EPOCH_LENGTH + ENTRY_EXIT_DELAY
 
     state.validator_registry_exit_count += 1
     validator.exit_count = state.validator_registry_exit_count
-    state.validator_registry_delta_chain_tip = hash_tree_root(
-        ValidatorRegistryDeltaBlock(
-            latest_registry_delta_root=state.validator_registry_delta_chain_tip,
-            validator_index=index,
-            pubkey=validator.pubkey,
-            slot=validator.exit_slot,
-            flag=EXIT,
-        )
-    )
 ```
 
 ```python
@@ -1583,7 +1559,7 @@ Verify that `len(block.body.exits) <= MAX_EXITS`.
 For each `exit` in `block.body.exits`:
 
 * Let `validator = state.validator_registry[exit.validator_index]`.
-* Verify that `validator.exit_slot > state.slot + ENTRY_EXIT_DELAY`.
+* Verify that `validator.exit_slot > state.slot - state.slot % EPOCH_LENGTH + ENTRY_EXIT_DELAY`.
 * Verify that `state.slot >= exit.slot`.
 * Let `exit_message = hash_tree_root(Exit(slot=exit.slot, validator_index=exit.validator_index, signature=EMPTY_SIGNATURE))`.
 * Verify that `bls_verify(pubkey=validator.pubkey, message=exit_message, signature=exit.signature, domain=get_domain(state.fork, exit.slot, DOMAIN_EXIT))`.
@@ -1763,7 +1739,7 @@ def update_validator_registry(state: BeaconState) -> None:
     # Activate validators within the allowable balance churn
     balance_churn = 0
     for index, validator in enumerate(state.validator_registry):
-        if validator.activation_slot > state.slot + ENTRY_EXIT_DELAY and state.validator_balances[index] >= MAX_DEPOSIT_AMOUNT:
+        if validator.activation_slot > state.slot - state.slot % EPOCH_LENGTH + ENTRY_EXIT_DELAY and state.validator_balances[index] >= MAX_DEPOSIT_AMOUNT:
             # Check the balance churn would be within the allowance
             balance_churn += get_effective_balance(state, index)
             if balance_churn > max_balance_churn:
@@ -1775,7 +1751,7 @@ def update_validator_registry(state: BeaconState) -> None:
     # Exit validators within the allowable balance churn
     balance_churn = 0
     for index, validator in enumerate(state.validator_registry):
-        if validator.exit_slot > state.slot + ENTRY_EXIT_DELAY and validator.status_flags & INITIATED_EXIT:
+        if validator.exit_slot > state.slot - state.slot % EPOCH_LENGTH + ENTRY_EXIT_DELAY and validator.status_flags & INITIATED_EXIT:
             # Check the balance churn would be within the allowance
             balance_churn += get_effective_balance(state, index)
             if balance_churn > max_balance_churn:
@@ -1791,17 +1767,19 @@ and perform the following updates:
 
 * Set `state.previous_epoch_calculation_slot = state.current_epoch_calculation_slot`
 * Set `state.previous_epoch_start_shard = state.current_epoch_start_shard`
-* Set `state.previous_epoch_randao_mix = state.current_epoch_randao_mix`
+* Set `state.previous_epoch_seed = state.current_epoch_seed`
 * Set `state.current_epoch_calculation_slot = state.slot`
 * Set `state.current_epoch_start_shard = (state.current_epoch_start_shard + get_current_epoch_committee_count_per_slot(state) * EPOCH_LENGTH) % SHARD_COUNT`
-* Set `state.current_epoch_randao_mix = get_randao_mix(state, state.current_epoch_calculation_slot - SEED_LOOKAHEAD)`
+* Set `state.current_epoch_seed = hash(get_randao_mix(state, state.current_epoch_calculation_slot - SEED_LOOKAHEAD) + get_active_index_root(state, state.current_epoch_calculation_slot))`
 
 If a validator registry update does _not_ happen do the following:
 
 * Set `state.previous_epoch_calculation_slot = state.current_epoch_calculation_slot`
 * Set `state.previous_epoch_start_shard = state.current_epoch_start_shard`
 * Let `epochs_since_last_registry_change = (state.slot - state.validator_registry_update_slot) // EPOCH_LENGTH`.
-* If `epochs_since_last_registry_change` is an exact power of 2, set `state.current_epoch_calculation_slot = state.slot` and `state.current_epoch_randao_mix = state.latest_randao_mixes[(state.current_epoch_calculation_slot - SEED_LOOKAHEAD) % LATEST_RANDAO_MIXES_LENGTH]`. Note that `state.current_epoch_start_shard` is left unchanged.
+* If `epochs_since_last_registry_change` is an exact power of 2, set `state.current_epoch_calculation_slot = state.slot` and `state.current_epoch_seed = hash(get_randao_mix(state, state.current_epoch_calculation_slot - SEED_LOOKAHEAD) + get_active_index_root(state, state.current_epoch_calculation_slot))`. Note that `state.current_epoch_start_shard` is left unchanged.
+
+**Invariant**: the active index root that is hashed into the shuffling seed actually is the `hash_tree_root` of the validator set that is used for that epoch.
 
 Regardless of whether or not a validator set change happens, run the following:
 
@@ -1844,6 +1822,7 @@ def process_penalties_and_exits(state: BeaconState) -> None:
 
 * Let `e = state.slot // EPOCH_LENGTH`. Set `state.latest_penalized_balances[(e+1) % LATEST_PENALIZED_EXIT_LENGTH] = state.latest_penalized_balances[e % LATEST_PENALIZED_EXIT_LENGTH]`
 * Remove any `attestation` in `state.latest_attestations` such that `attestation.data.slot < state.slot - EPOCH_LENGTH`.
+* Let `epoch = state.slot // EPOCH_LENGTH`. Set `state.latest_index_roots[epoch % LATEST_INDEX_ROOTS_LENGTH] = hash_tree_root(get_active_validator_indices(state, state.slot))`
 
 ## State root processing
 

From 958c338c8fe1e9ea8e7494add7d33eecdced5513 Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Sat, 19 Jan 2019 18:11:07 -0600
Subject: [PATCH 11/44] Update specs/core/0_beacon-chain.md

Co-Authored-By: vbuterin <v@buterin.com>
---
 specs/core/0_beacon-chain.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
index 3f687618a..afa87a140 100644
--- a/specs/core/0_beacon-chain.md
+++ b/specs/core/0_beacon-chain.md
@@ -994,7 +994,7 @@ def get_randao_mix(state: BeaconState,
 def get_active_index_root(state: BeaconState,
                           slot: int) -> Hash32:
     """
-    Returns the randao mix at a recent ``slot``.
+    Returns the index root at a recent ``slot``.
     """
     assert state.slot // EPOCH_LENGTH < slot // EPOCH_LENGTH + LATEST_INDEX_ROOTS_LENGTH
     assert slot // EPOCH_LENGTH <= state.slot // EPOCH_LENGTH

From 02725b870e0cc8b6c01427906cafe4a36461a528 Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Sat, 19 Jan 2019 18:11:14 -0600
Subject: [PATCH 12/44] Update specs/core/0_beacon-chain.md

Co-Authored-By: vbuterin <v@buterin.com>
---
 specs/core/0_beacon-chain.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
index afa87a140..25eb7bbe6 100644
--- a/specs/core/0_beacon-chain.md
+++ b/specs/core/0_beacon-chain.md
@@ -992,7 +992,7 @@ def get_randao_mix(state: BeaconState,
 
 ```python
 def get_active_index_root(state: BeaconState,
-                          slot: int) -> Hash32:
+                          slot: int) -> Bytes32:
     """
     Returns the index root at a recent ``slot``.
     """

From 12b217df70ea36fa7322efd00fdd8491cba5ed7f Mon Sep 17 00:00:00 2001
From: vbuterin <v@buterin.com>
Date: Sat, 19 Jan 2019 18:13:17 -0600
Subject: [PATCH 13/44] Updated as per hww's suggestions

---
 specs/core/0_beacon-chain.md | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
index 25eb7bbe6..88b3c0384 100644
--- a/specs/core/0_beacon-chain.md
+++ b/specs/core/0_beacon-chain.md
@@ -996,9 +996,11 @@ def get_active_index_root(state: BeaconState,
     """
     Returns the index root at a recent ``slot``.
     """
-    assert state.slot // EPOCH_LENGTH < slot // EPOCH_LENGTH + LATEST_INDEX_ROOTS_LENGTH
-    assert slot // EPOCH_LENGTH <= state.slot // EPOCH_LENGTH
-    return state.latest_index_roots[(slot // EPOCH_LENGTH) % LATEST_INDEX_ROOTS_LENGTH]
+    state_epoch = state.slot // EPOCH_LENGTH
+    given_epoch = slot // EPOCH_LENGTH 
+    assert state_epoch < given_epoch + LATEST_INDEX_ROOTS_LENGTH
+    assert given_epoch <= state_epoch
+    return state.latest_index_roots[given_epoch % LATEST_INDEX_ROOTS_LENGTH]
 ```
 
 #### `get_beacon_proposer_index`
@@ -1819,9 +1821,10 @@ def process_penalties_and_exits(state: BeaconState) -> None:
 
 ### Final updates
 
-* Let `e = state.slot // EPOCH_LENGTH`. Set `state.latest_penalized_balances[(e+1) % LATEST_PENALIZED_EXIT_LENGTH] = state.latest_penalized_balances[e % LATEST_PENALIZED_EXIT_LENGTH]`
+* Let `epoch = state.slot // EPOCH_LENGTH`.
+* Set `state.latest_penalized_balances[(epoch+1) % LATEST_PENALIZED_EXIT_LENGTH] = state.latest_penalized_balances[epoch % LATEST_PENALIZED_EXIT_LENGTH]`
 * Remove any `attestation` in `state.latest_attestations` such that `attestation.data.slot < state.slot - EPOCH_LENGTH`.
-* Let `epoch = state.slot // EPOCH_LENGTH`. Set `state.latest_index_roots[epoch % LATEST_INDEX_ROOTS_LENGTH] = hash_tree_root(get_active_validator_indices(state, state.slot))`
+* Set `state.latest_index_roots[epoch % LATEST_INDEX_ROOTS_LENGTH] = hash_tree_root(get_active_validator_indices(state, state.slot))`
 
 ## State root processing
 

From 0efeed9a56c4544c522afc946c96502a0c3acab2 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Mon, 21 Jan 2019 08:39:24 -0600
Subject: [PATCH 14/44] fix constants in validator section

---
 specs/validator/0_beacon-chain-validator.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 4b8cd0927..1aaeb86ab 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -10,6 +10,8 @@ __NOTICE__: This document is a work-in-progress for researchers and implementers
     - [Table of Contents](#table-of-contents)
     - [Introduction](#introduction)
     - [Prerequisites](#prerequisites)
+    - [Constants](#constants)
+        - [Misc](#misc)
     - [Becoming a validator](#becoming-a-validator)
         - [Initialization](#initialization)
             - [BLS public key](#bls-public-key)
@@ -71,7 +73,7 @@ All terminology, constants, functions, and protocol mechanics defined in the [Ph
 ### Misc
 
 | Name | Value | Unit | Duration |
-| - | - | :-: |
+| - | - | :-: | :-: |
 | `ETH1_FOLLOW_DISTANCE` | `2**10` (= 1,024) | blocks | ~4 hours |
 
 ## Becoming a validator

From 52696f88067385a2e582b144fdccaecfbdba8321 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Mon, 21 Jan 2019 11:07:56 -0600
Subject: [PATCH 15/44] ensure validator links to master

---
 specs/validator/0_beacon-chain-validator.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 1aaeb86ab..8296ee97c 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -141,7 +141,7 @@ Deposits cannot be processed into the beacon chain until the eth1.0 block in whi
 
 ### Validator index
 
-Once a validator has been processed and added to the state's `validator_registry`, the validator's `validator_index` is defined by the index into the registry at which the [`ValidatorRecord`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#validatorrecord) contains the `pubkey` specified in the validator's deposit. This `validator_index` is used throughout the specification to dictate validator roles and responsibilities at any point and should be stored locally.
+Once a validator has been processed and added to the state's `validator_registry`, the validator's `validator_index` is defined by the index into the registry at which the [`ValidatorRecord`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#validatorrecord) contains the `pubkey` specified in the validator's deposit. This `validator_index` is used throughout the specification to dictate validator roles and responsibilities at any point and should be stored locally.
 
 ### Activation
 
@@ -374,7 +374,7 @@ If the software crashes at some point within this routine, then when the validat
 
 ### Casper slashing
 
-To avoid "Casper slashings", a validator must not sign two conflicting [`AttestationData`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestationdata) objects where conflicting is defined as a set of two attestations that satisfy either [`is_double_vote`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#is_double_vote) or [`is_surround_vote`](https://github.com/ethereum/eth2.0-specs/blob/bd506e12227850888df167926b52f8fd2db31915/specs/core/0_beacon-chain.md#is_surround_vote).
+To avoid "Casper slashings", a validator must not sign two conflicting [`AttestationData`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestationdata) objects where conflicting is defined as a set of two attestations that satisfy either [`is_double_vote`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#is_double_vote) or [`is_surround_vote`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#is_surround_vote).
 
 Specifically, when signing an `Attestation`, a validator should perform the following steps in the following order:
 1. Save a record to hard disk that an attestation has been signed for source -- `attestation_data.justified_slot // EPOCH_LENGTH` -- and target -- `attestation_data.slot // EPOCH_LENGTH`.

From 460188f9f55ed084f3008c5d1e878d708394a443 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Mon, 21 Jan 2019 11:47:23 -0600
Subject: [PATCH 16/44] clarify get_shuffling invariant

---
 specs/core/0_beacon-chain.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
index 49db5fdb0..daf0cae7e 100644
--- a/specs/core/0_beacon-chain.md
+++ b/specs/core/0_beacon-chain.md
@@ -912,7 +912,7 @@ def get_shuffling(seed: Bytes32,
     return split(shuffled_active_validator_indices, committees_per_slot * EPOCH_LENGTH)
 ```
 
-**Invariant**: if `get_shuffling(seed, validators, slot)` returns some value `x`, it should return the same value `x` for the same `seed` and `slot` and possible future modifications of `validators` forever in phase 0, and until the ~1 year deletion delay in phase 2 and in the future.
+**Invariant**: if `get_shuffling(seed, validators, slot)` returns some value `x` and `slot <= state.slot + ENTRY_EXIT_DELAY`, it should return the same value `x` for the same `seed` and `slot` and possible future modifications of `validators` forever in phase 0, and until the ~1 year deletion delay in phase 2 and in the future.
 
 **Note**: this definition and the next few definitions make heavy use of repetitive computing. Production implementations are expected to appropriately use caching/memoization to avoid redoing work.
 

From 634740a2f26517973d1948b53f72137b54c49e7f Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Tue, 22 Jan 2019 07:56:44 -0600
Subject: [PATCH 17/44] Update specs/validator/0_beacon-chain-validator.md

Co-Authored-By: djrtwo <dannyjryan@gmail.com>
---
 specs/validator/0_beacon-chain-validator.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 8296ee97c..3f8e8d29d 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -130,7 +130,7 @@ To submit a deposit:
 * Set `deposit_input.proof_of_possession = EMPTY_SIGNATURE`.
 * Let `proof_of_possession` be the result of `bls_sign` of the `hash_tree_root(deposit_input)` with `domain=DOMAIN_DEPOSIT`.
 * Set `deposit_input.proof_of_possession = proof_of_possession`.
-* Let `amount` be the amount of eth to be deposited by the validator where `MIN_DEPOSIT <= amount <= MAX_DEPOSIT`.
+* Let `amount` be the amount in Gwei to be deposited by the validator where `MIN_DEPOSIT_AMOUNT <= amount <= MAX_DEPOSIT_AMOUNT`.
 * Send a transaction on the Ethereum 1.0 chain to `DEPOSIT_CONTRACT_ADDRESS` executing `deposit` along with `deposit_input` as the singular `bytes` input along with a deposit `amount` in ETH.
 
 _Note_: Multiple deposits can be made by the same validator (same initialization params). A singular `Validator` will be added to `state.validator_registry` with each deposit amount being added to the validator's balance. A validator can only be activated when total deposits meet or exceed 

From b7de018f4d7121e6f9d764b6db9f5395905d0959 Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Tue, 22 Jan 2019 07:57:51 -0600
Subject: [PATCH 18/44] Update specs/validator/0_beacon-chain-validator.md

Co-Authored-By: djrtwo <dannyjryan@gmail.com>
---
 specs/validator/0_beacon-chain-validator.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 3f8e8d29d..b55a25d0a 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -196,7 +196,7 @@ Set `block.randao_reveal` to the `n`th layer deep reveal from the validator's cu
     * `vote.eth1_data.block_hash` is the hash of an eth1.0 block that is (i) part of the canonical chain, (ii) >= `ETH1_FOLLOW_DISTANCE` blocks behind the head, and (iii) newer than `state.latest_eth1_data.block_data`.
     * `vote.eth1_data.deposit_root` is the deposit root of the eth1.0 deposit contract at the block defined by `vote.eth1_data.block_hash`.
 * If `D` is empty:
-    * Let `block_hash` be the block hash of the `ETH1_FOLLOW_DISTANCE`th ancestory of the head of the canonical eth1.0 chain.
+    * Let `block_hash` be the block hash of the `ETH1_FOLLOW_DISTANCE`th ancestor of the head of the canonical eth1.0 chain.
     * Let `deposit_root` be the the deposit root of the eth1.0 deposit contract at the block defined by `block_hash`.
 * If `D` is nonempty:
     * Let `best_vote` be the member of `D` that has the highest `vote.eth1_data.vote_count`, breaking ties by favoring block hashes with higher associated block height.

From a934138d8bf52482481977656b380523de3bd2d9 Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Tue, 22 Jan 2019 07:58:10 -0600
Subject: [PATCH 19/44] Update specs/validator/0_beacon-chain-validator.md

Co-Authored-By: djrtwo <dannyjryan@gmail.com>
---
 specs/validator/0_beacon-chain-validator.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index b55a25d0a..0b10aeb9f 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -131,7 +131,7 @@ To submit a deposit:
 * Let `proof_of_possession` be the result of `bls_sign` of the `hash_tree_root(deposit_input)` with `domain=DOMAIN_DEPOSIT`.
 * Set `deposit_input.proof_of_possession = proof_of_possession`.
 * Let `amount` be the amount in Gwei to be deposited by the validator where `MIN_DEPOSIT_AMOUNT <= amount <= MAX_DEPOSIT_AMOUNT`.
-* Send a transaction on the Ethereum 1.0 chain to `DEPOSIT_CONTRACT_ADDRESS` executing `deposit` along with `deposit_input` as the singular `bytes` input along with a deposit `amount` in ETH.
+* Send a transaction on the Ethereum 1.0 chain to `DEPOSIT_CONTRACT_ADDRESS` executing `deposit` along with `deposit_input` as the singular `bytes` input along with a deposit `amount` in Gwei.
 
 _Note_: Multiple deposits can be made by the same validator (same initialization params). A singular `Validator` will be added to `state.validator_registry` with each deposit amount being added to the validator's balance. A validator can only be activated when total deposits meet or exceed 
 

From daa1b6ebf1ef32876ef94c8591b65f9da1069e9f Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Tue, 22 Jan 2019 07:58:29 -0600
Subject: [PATCH 20/44] Update specs/validator/0_beacon-chain-validator.md

Co-Authored-By: djrtwo <dannyjryan@gmail.com>
---
 specs/validator/0_beacon-chain-validator.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 0b10aeb9f..c79d22347 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -307,7 +307,7 @@ Set `attestation.data = attestation_data` where `attestation_data` is the `Attes
 
 ##### Participation bitfield
 
-* Let `participation_bitfield` be a byte array filled with zeros of length `(len(committee) + 7) // 8`.
+* Let `aggregation_bitfield` be a byte array filled with zeros of length `(len(committee) + 7) // 8`.
 * Let `index_into_committee` be the index into the validator's `committee` at which `validator_index` is located.
 * Set `participation_bitfield[index_into_committee // 8] |= 2 ** (index_into_committee % 8)`.
 * Set `attestation.participation_bitfield = participation_bitfield`.

From 05e8d25a80b8668b00b0d64e8da988a07e32f091 Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Tue, 22 Jan 2019 07:58:55 -0600
Subject: [PATCH 21/44] Update specs/validator/0_beacon-chain-validator.md

Co-Authored-By: djrtwo <dannyjryan@gmail.com>
---
 specs/validator/0_beacon-chain-validator.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index c79d22347..2521e1cb3 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -197,7 +197,7 @@ Set `block.randao_reveal` to the `n`th layer deep reveal from the validator's cu
     * `vote.eth1_data.deposit_root` is the deposit root of the eth1.0 deposit contract at the block defined by `vote.eth1_data.block_hash`.
 * If `D` is empty:
     * Let `block_hash` be the block hash of the `ETH1_FOLLOW_DISTANCE`th ancestor of the head of the canonical eth1.0 chain.
-    * Let `deposit_root` be the the deposit root of the eth1.0 deposit contract at the block defined by `block_hash`.
+    * Let `deposit_root` be the deposit root of the eth1.0 deposit contract at the block defined by `block_hash`.
 * If `D` is nonempty:
     * Let `best_vote` be the member of `D` that has the highest `vote.eth1_data.vote_count`, breaking ties by favoring block hashes with higher associated block height.
     * Let `block_hash = best_vote.eth1_data.block_hash`.

From c32a79f940edd06d45626b4b5987592ed7f18059 Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Tue, 22 Jan 2019 08:03:00 -0600
Subject: [PATCH 22/44] Update specs/validator/0_beacon-chain-validator.md

Co-Authored-By: djrtwo <dannyjryan@gmail.com>
---
 specs/validator/0_beacon-chain-validator.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 2521e1cb3..dde1610ba 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -235,7 +235,7 @@ Up to `MAX_PROPOSER_SLASHINGS` [`ProposerSlashing`](https://github.com/ethereum/
 
 ##### Casper slashings
 
-Up to `MAX_CASPER_SLASHINGS` [`CasperSlashing`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#casperslashing) objects can be included in the `block`. The casper slashings must satisfy the verification conditions found in [casper slashings processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#casper-slashings-1). The validator receives a small "whistleblower" reward for each casper slashing found and included.
+Up to `MAX_CASPER_SLASHINGS` [`CasperSlashing`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#casperslashing) objects can be included in the `block`. The Casper slashings must satisfy the verification conditions found in [Casper slashings processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#casper-slashings-1). The validator receives a small "whistleblower" reward for each Casper slashing found and included.
 
 ##### Attestations
 

From 697545a9e056c08e54e02027f16fdfc0c72c2cde Mon Sep 17 00:00:00 2001
From: vbuterin <v@buterin.com>
Date: Tue, 22 Jan 2019 22:47:07 -0600
Subject: [PATCH 23/44] Added entry_exit_effect_slot helper and moved index
 roots update

---
 specs/core/0_beacon-chain.md | 34 +++++++++++++++++++++++-----------
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
index b0e7303c5..56789d822 100644
--- a/specs/core/0_beacon-chain.md
+++ b/specs/core/0_beacon-chain.md
@@ -83,6 +83,7 @@
             - [`is_double_vote`](#is_double_vote)
             - [`is_surround_vote`](#is_surround_vote)
             - [`integer_squareroot`](#integer_squareroot)
+            - [`entry_exit_effect_slot`](#entry_exit_effect_slot)
             - [`bls_verify`](#bls_verify)
             - [`bls_verify_multiple`](#bls_verify_multiple)
             - [`bls_aggregate_pubkeys`](#bls_aggregate_pubkeys)
@@ -1159,7 +1160,7 @@ def is_surround_vote(attestation_data_1: AttestationData,
 ```python
 def integer_squareroot(n: int) -> int:
     """
-    The largest integer ``x`` such that ``x**2`` is less than ``n``.
+    The largest integer ``x`` such that ``x**2`` is less than or equal to ``n``.
     """
     assert n >= 0
     x = n
@@ -1170,6 +1171,17 @@ def integer_squareroot(n: int) -> int:
     return x
 ```
 
+#### `entry_exit_effect_slot`
+
+```python
+def entry_exit_effect_slot(n: int) -> int:
+    """
+    An entry or exit triggered in the slot given by the input takes effect at
+    the slot given by the output.
+    """
+    return (n - n % EPOCH_LENGTH) + EPOCH_LENGTH + ENTRY_EXIT_DELAY
+```
+
 #### `bls_verify`
 
 `bls_verify` is a function for verifying a BLS signature, defined in the [BLS Signature spec](https://github.com/ethereum/eth2.0-specs/blob/master/specs/bls_signature.md#bls_verify).
@@ -1372,13 +1384,13 @@ def process_deposit(state: BeaconState,
 
 ### Routines for updating validator status
 
-Note: All functions in this section mutate `state`.
+Note: All functions in this section mutate `state`. 
 
 ```python
 def activate_validator(state: BeaconState, index: int, genesis: bool) -> None:
     validator = state.validator_registry[index]
 
-    validator.activation_slot = GENESIS_SLOT if genesis else (state.slot - state.slot % EPOCH_LENGTH + ENTRY_EXIT_DELAY)
+    validator.activation_slot = GENESIS_SLOT if genesis else entry_exit_effect_slot(state.slot)
 ```
 
 ```python
@@ -1392,10 +1404,10 @@ def exit_validator(state: BeaconState, index: int) -> None:
     validator = state.validator_registry[index]
 
     # The following updates only occur if not previous exited
-    if validator.exit_slot <= state.slot - state.slot % EPOCH_LENGTH + ENTRY_EXIT_DELAY:
+    if validator.exit_slot <= entry_exit_effect_slot(state.slot):
         return
 
-    validator.exit_slot = state.slot - state.slot % EPOCH_LENGTH + ENTRY_EXIT_DELAY
+    validator.exit_slot = entry_exit_effect_slot(state.slot)
 
     state.validator_registry_exit_count += 1
     validator.exit_count = state.validator_registry_exit_count
@@ -1560,7 +1572,7 @@ Verify that `len(block.body.exits) <= MAX_EXITS`.
 For each `exit` in `block.body.exits`:
 
 * Let `validator = state.validator_registry[exit.validator_index]`.
-* Verify that `validator.exit_slot > state.slot - state.slot % EPOCH_LENGTH + ENTRY_EXIT_DELAY`.
+* Verify that `validator.exit_slot > entry_exit_effect_slot(state.slot)`.
 * Verify that `state.slot >= exit.slot`.
 * Let `exit_message = hash_tree_root(Exit(slot=exit.slot, validator_index=exit.validator_index, signature=EMPTY_SIGNATURE))`.
 * Verify that `bls_verify(pubkey=validator.pubkey, message=exit_message, signature=exit.signature, domain=get_domain(state.fork, exit.slot, DOMAIN_EXIT))`.
@@ -1711,12 +1723,13 @@ def process_ejections(state: BeaconState) -> None:
             exit_validator(state, index)
 ```
 
-### Validator registry
+### Validator registry and shuffling seed data
 
-First, update `previous_epoch_calculation_slot` and `previous_epoch_start_shard`:
+First, update `previous_epoch_calculation_slot`, `previous_epoch_start_shard` and `latest_index_roots`:
 
 * Set `state.previous_epoch_calculation_slot = state.current_epoch_calculation_slot`
 * Set `state.previous_epoch_start_shard = state.current_epoch_start_shard`
+* Set `state.latest_index_roots[epoch % LATEST_INDEX_ROOTS_LENGTH] = hash_tree_root(get_active_validator_indices(state, state.slot))`
 
 If the following are satisfied:
 
@@ -1745,7 +1758,7 @@ def update_validator_registry(state: BeaconState) -> None:
     # Activate validators within the allowable balance churn
     balance_churn = 0
     for index, validator in enumerate(state.validator_registry):
-        if validator.activation_slot > state.slot - state.slot % EPOCH_LENGTH + ENTRY_EXIT_DELAY and state.validator_balances[index] >= MAX_DEPOSIT_AMOUNT:
+        if validator.activation_slot > entry_exit_effect_slot(state.slot) and state.validator_balances[index] >= MAX_DEPOSIT_AMOUNT:
             # Check the balance churn would be within the allowance
             balance_churn += get_effective_balance(state, index)
             if balance_churn > max_balance_churn:
@@ -1757,7 +1770,7 @@ def update_validator_registry(state: BeaconState) -> None:
     # Exit validators within the allowable balance churn
     balance_churn = 0
     for index, validator in enumerate(state.validator_registry):
-        if validator.exit_slot > state.slot - state.slot % EPOCH_LENGTH + ENTRY_EXIT_DELAY and validator.status_flags & INITIATED_EXIT:
+        if validator.exit_slot > entry_exit_effect_slot(state.slot) and validator.status_flags & INITIATED_EXIT:
             # Check the balance churn would be within the allowance
             balance_churn += get_effective_balance(state, index)
             if balance_churn > max_balance_churn:
@@ -1825,7 +1838,6 @@ def process_penalties_and_exits(state: BeaconState) -> None:
 * Let `epoch = state.slot // EPOCH_LENGTH`.
 * Set `state.latest_penalized_balances[(epoch+1) % LATEST_PENALIZED_EXIT_LENGTH] = state.latest_penalized_balances[epoch % LATEST_PENALIZED_EXIT_LENGTH]`
 * Remove any `attestation` in `state.latest_attestations` such that `attestation.data.slot < state.slot - EPOCH_LENGTH`.
-* Set `state.latest_index_roots[epoch % LATEST_INDEX_ROOTS_LENGTH] = hash_tree_root(get_active_validator_indices(state, state.slot))`
 
 ## State root processing
 

From f9097bfe8b3832db07b8a263320aff93368b3a68 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Wed, 23 Jan 2019 00:22:47 -0600
Subject: [PATCH 24/44] Update specs/core/0_beacon-chain.md

Co-Authored-By: vbuterin <v@buterin.com>
---
 specs/core/0_beacon-chain.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
index 56789d822..9399bc255 100644
--- a/specs/core/0_beacon-chain.md
+++ b/specs/core/0_beacon-chain.md
@@ -1384,7 +1384,7 @@ def process_deposit(state: BeaconState,
 
 ### Routines for updating validator status
 
-Note: All functions in this section mutate `state`. 
+Note: All functions in this section mutate `state`.
 
 ```python
 def activate_validator(state: BeaconState, index: int, genesis: bool) -> None:

From 6ac5608d0be01a8eb40440bcb2030e3439af0557 Mon Sep 17 00:00:00 2001
From: Chih Cheng Liang <chihchengliang@gmail.com>
Date: Tue, 22 Jan 2019 01:21:22 +0800
Subject: [PATCH 25/44] Explicit check bytes end

---
 specs/simple-serialize.md | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/specs/simple-serialize.md b/specs/simple-serialize.md
index 8630c47c6..9774a9ecd 100644
--- a/specs/simple-serialize.md
+++ b/specs/simple-serialize.md
@@ -219,14 +219,22 @@ The decoding requires knowledge of the type of the item to be decoded. When
 performing decoding on an entire serialized string, it also requires knowledge
 of the order in which the objects have been serialized.
 
-Note: Each return will provide ``deserialized_object, new_index`` keeping track
-of the new index.
+Note: Each return will provide:
+- `deserialized_object`
+- `new_index`
 
 At each step, the following checks should be made:
 
 | Check to perform         | Check                                                      |
 |:-------------------------|:-----------------------------------------------------------|
-| Ensure sufficient length | ``length(rawbytes) >= current_index + deserialize_length`` |
+| Ensure sufficient length | ``len(rawbytes) >= current_index + deserialize_length``    |
+
+At the final step, the following checks should be made:
+
+| Check to perform         | Check                                |
+|:-------------------------|:-------------------------------------|
+| Ensure no extra length   | `new_index == len(rawbytes)`         |
+
 
 #### uint
 
@@ -326,6 +334,7 @@ Instantiate a container with the full set of deserialized data, matching each me
 | rawbytes has enough left for length       | ``len(rawbytes) > current_index + LENGTH_BYTES``                |
 | list is not greater than serialized bytes | ``len(rawbytes) > current_index + LENGTH_BYTES + total_length`` |
 
+
 To deserialize:
 
 1. Get the list of the container's fields.

From 028eba903ea542394167ea838e1d7b3669464b10 Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Wed, 23 Jan 2019 17:15:53 -0600
Subject: [PATCH 26/44] Update specs/validator/0_beacon-chain-validator.md

Co-Authored-By: djrtwo <dannyjryan@gmail.com>
---
 specs/validator/0_beacon-chain-validator.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index dde1610ba..86d0bd14c 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -309,7 +309,7 @@ Set `attestation.data = attestation_data` where `attestation_data` is the `Attes
 
 * Let `aggregation_bitfield` be a byte array filled with zeros of length `(len(committee) + 7) // 8`.
 * Let `index_into_committee` be the index into the validator's `committee` at which `validator_index` is located.
-* Set `participation_bitfield[index_into_committee // 8] |= 2 ** (index_into_committee % 8)`.
+* Set `aggregation_bitfield[index_into_committee // 8] |= 2 ** (index_into_committee % 8)`.
 * Set `attestation.participation_bitfield = participation_bitfield`.
 
 _Note_: Calling `get_attestation_participants(state, attestation.data, attestation.participation_bitfield)` should return `[validator_index]`.

From 4a566469a5cb0c27b26c606931c4e1017e8c3fa2 Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Wed, 23 Jan 2019 17:16:04 -0600
Subject: [PATCH 27/44] Update specs/validator/0_beacon-chain-validator.md

Co-Authored-By: djrtwo <dannyjryan@gmail.com>
---
 specs/validator/0_beacon-chain-validator.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 86d0bd14c..61539d974 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -310,7 +310,7 @@ Set `attestation.data = attestation_data` where `attestation_data` is the `Attes
 * Let `aggregation_bitfield` be a byte array filled with zeros of length `(len(committee) + 7) // 8`.
 * Let `index_into_committee` be the index into the validator's `committee` at which `validator_index` is located.
 * Set `aggregation_bitfield[index_into_committee // 8] |= 2 ** (index_into_committee % 8)`.
-* Set `attestation.participation_bitfield = participation_bitfield`.
+* Set `attestation.aggregation_bitfield = aggregation_bitfield`.
 
 _Note_: Calling `get_attestation_participants(state, attestation.data, attestation.participation_bitfield)` should return `[validator_index]`.
 

From b7c2f33dcbc8ec35e29abeeabc254283c02e99d7 Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Wed, 23 Jan 2019 17:26:11 -0600
Subject: [PATCH 28/44] Update specs/validator/0_beacon-chain-validator.md

Co-Authored-By: djrtwo <dannyjryan@gmail.com>
---
 specs/validator/0_beacon-chain-validator.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 61539d974..8ac6fdf45 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -312,7 +312,7 @@ Set `attestation.data = attestation_data` where `attestation_data` is the `Attes
 * Set `aggregation_bitfield[index_into_committee // 8] |= 2 ** (index_into_committee % 8)`.
 * Set `attestation.aggregation_bitfield = aggregation_bitfield`.
 
-_Note_: Calling `get_attestation_participants(state, attestation.data, attestation.participation_bitfield)` should return `[validator_index]`.
+_Note_: Calling `get_attestation_participants(state, attestation.data, attestation.aggregation_bitfield)` should return a list of length equal to 1, containing `validator_index`.
 
 ##### Custody bitfield
 

From 59b301f7af7b91925083bcf68d460a44bbc8254e Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Wed, 23 Jan 2019 17:31:27 -0600
Subject: [PATCH 29/44] Update specs/validator/0_beacon-chain-validator.md

Co-Authored-By: djrtwo <dannyjryan@gmail.com>
---
 specs/validator/0_beacon-chain-validator.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 8ac6fdf45..6d3a1976b 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -151,7 +151,7 @@ The function [`is_active_validator`](https://github.com/ethereum/eth2.0-specs/bl
 
 ```python
 validator = state.validator_registry[validator_index]
-is_active_validator(validator, slot)
+is_active = is_active_validator(validator, slot)
 ```
 
 Once a validator is active, the validator is assigned [responsibilities](#beacon-chain-responsibilities) until exited.

From 5bb02a9d09cd2fe8a5358d1854bb1c9c888bf798 Mon Sep 17 00:00:00 2001
From: Hsiao-Wei Wang <hwwang156@gmail.com>
Date: Thu, 24 Jan 2019 15:53:52 +0800
Subject: [PATCH 30/44] Update specs/simple-serialize.md

Co-Authored-By: ChihChengLiang <chihchengliang@gmail.com>
---
 specs/simple-serialize.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/simple-serialize.md b/specs/simple-serialize.md
index 9774a9ecd..60b436e6d 100644
--- a/specs/simple-serialize.md
+++ b/specs/simple-serialize.md
@@ -331,7 +331,7 @@ Instantiate a container with the full set of deserialized data, matching each me
 
 | Check to perform                          | code                                                            |
 |:------------------------------------------|:----------------------------------------------------------------|
-| rawbytes has enough left for length       | ``len(rawbytes) > current_index + LENGTH_BYTES``                |
+| ``rawbytes`` has enough left for length       | ``len(rawbytes) > current_index + LENGTH_BYTES``                |
 | list is not greater than serialized bytes | ``len(rawbytes) > current_index + LENGTH_BYTES + total_length`` |
 
 

From c2112f0bfcf122856105d0690cccef9156dfc484 Mon Sep 17 00:00:00 2001
From: Chih Cheng Liang <chihchengliang@gmail.com>
Date: Thu, 24 Jan 2019 15:57:50 +0800
Subject: [PATCH 31/44] PR feedback: remove unnecessary newline

---
 specs/simple-serialize.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/specs/simple-serialize.md b/specs/simple-serialize.md
index 60b436e6d..524a010d3 100644
--- a/specs/simple-serialize.md
+++ b/specs/simple-serialize.md
@@ -331,10 +331,9 @@ Instantiate a container with the full set of deserialized data, matching each me
 
 | Check to perform                          | code                                                            |
 |:------------------------------------------|:----------------------------------------------------------------|
-| ``rawbytes`` has enough left for length       | ``len(rawbytes) > current_index + LENGTH_BYTES``                |
+| ``rawbytes`` has enough left for length   | ``len(rawbytes) > current_index + LENGTH_BYTES``                |
 | list is not greater than serialized bytes | ``len(rawbytes) > current_index + LENGTH_BYTES + total_length`` |
 
-
 To deserialize:
 
 1. Get the list of the container's fields.

From 88ffae633527a02c6de68df9c40b0e98615ffc83 Mon Sep 17 00:00:00 2001
From: Chih Cheng Liang <chihchengliang@gmail.com>
Date: Thu, 24 Jan 2019 16:08:56 +0800
Subject: [PATCH 32/44] define deserialized_object and new_index

---
 specs/simple-serialize.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/specs/simple-serialize.md b/specs/simple-serialize.md
index 524a010d3..e0528b562 100644
--- a/specs/simple-serialize.md
+++ b/specs/simple-serialize.md
@@ -54,6 +54,9 @@ overhead.
 | `from_bytes` | Convert from bytes to object. Should take ``bytes`` and ``byte_order``.                        |
 | `value`      | The value to serialize.                                                                        |
 | `rawbytes`   | Raw serialized bytes.                                                                          |
+| `deserialized_object` | The deserialized data in the data structure of your programming language.             |
+| `new_index`  | An index to keep track the latest position where the `rawbytes` have been deserialized.        |
+
 
 ## Constants
 

From 14432e91a3fd0f66806faccc533c384c0fb5eb63 Mon Sep 17 00:00:00 2001
From: Chih Cheng Liang <chihchengliang@gmail.com>
Date: Thu, 24 Jan 2019 16:11:04 +0800
Subject: [PATCH 33/44] add code block to variable in the table

---
 specs/simple-serialize.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/simple-serialize.md b/specs/simple-serialize.md
index e0528b562..70245aebe 100644
--- a/specs/simple-serialize.md
+++ b/specs/simple-serialize.md
@@ -306,7 +306,7 @@ entire length of the list.
 
 | Check to perform                          | code                                                            |
 |:------------------------------------------|:----------------------------------------------------------------|
-| rawbytes has enough left for length       | ``len(rawbytes) > current_index + LENGTH_BYTES``                |
+| ``rawbytes`` has enough left for length   | ``len(rawbytes) > current_index + LENGTH_BYTES``                |
 | list is not greater than serialized bytes | ``len(rawbytes) > current_index + LENGTH_BYTES + total_length`` |
 
 ```python

From d41215aeececf065befefd2b99830a434ba58d01 Mon Sep 17 00:00:00 2001
From: Chih Cheng Liang <chihchengliang@gmail.com>
Date: Thu, 24 Jan 2019 16:11:45 +0800
Subject: [PATCH 34/44] rename Terminology to Variables and Functions

---
 specs/simple-serialize.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/simple-serialize.md b/specs/simple-serialize.md
index 70245aebe..f69544ffa 100644
--- a/specs/simple-serialize.md
+++ b/specs/simple-serialize.md
@@ -43,7 +43,7 @@ protocol for use in the Ethereum 2.0 Beacon Chain.
 The core feature of `ssz` is the simplicity of the serialization with low
 overhead.
 
-## Terminology
+## Variables and Functions
 
 | Term         | Definition                                                                                     |
 |:-------------|:-----------------------------------------------------------------------------------------------|

From 5dfa4e005b2d9e07e684cecc027c70407463bda0 Mon Sep 17 00:00:00 2001
From: Chih Cheng Liang <chihchengliang@gmail.com>
Date: Thu, 24 Jan 2019 16:12:43 +0800
Subject: [PATCH 35/44] rename byte_order to byteorder

---
 specs/simple-serialize.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/specs/simple-serialize.md b/specs/simple-serialize.md
index f69544ffa..5edaa6e10 100644
--- a/specs/simple-serialize.md
+++ b/specs/simple-serialize.md
@@ -48,10 +48,10 @@ overhead.
 | Term         | Definition                                                                                     |
 |:-------------|:-----------------------------------------------------------------------------------------------|
 | `little`     | Little endian.                                                                                 |
-| `byte_order` | Specifies [endianness](https://en.wikipedia.org/wiki/Endianness): big endian or little endian. |
+| `byteorder`  | Specifies [endianness](https://en.wikipedia.org/wiki/Endianness): big endian or little endian. |
 | `len`        | Length/number of bytes.                                                                        |
-| `to_bytes`   | Convert to bytes. Should take parameters ``size`` and ``byte_order``.                          |
-| `from_bytes` | Convert from bytes to object. Should take ``bytes`` and ``byte_order``.                        |
+| `to_bytes`   | Convert to bytes. Should take parameters ``size`` and ``byteorder``.                           |
+| `from_bytes` | Convert from bytes to object. Should take ``bytes`` and ``byteorder``.                         |
 | `value`      | The value to serialize.                                                                        |
 | `rawbytes`   | Raw serialized bytes.                                                                          |
 | `deserialized_object` | The deserialized data in the data structure of your programming language.             |

From 45c064a2d6cbba2fb284b0e8fae7d83742dab31c Mon Sep 17 00:00:00 2001
From: Chih Cheng Liang <chihchengliang@gmail.com>
Date: Thu, 24 Jan 2019 16:24:05 +0800
Subject: [PATCH 36/44] remove all unnecessary newline

---
 specs/simple-serialize.md | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/specs/simple-serialize.md b/specs/simple-serialize.md
index 5edaa6e10..150c71b62 100644
--- a/specs/simple-serialize.md
+++ b/specs/simple-serialize.md
@@ -57,7 +57,6 @@ overhead.
 | `deserialized_object` | The deserialized data in the data structure of your programming language.             |
 | `new_index`  | An index to keep track the latest position where the `rawbytes` have been deserialized.        |
 
-
 ## Constants
 
 | Constant          | Value | Definition                                                                            |
@@ -75,7 +74,6 @@ overhead.
 |:---------:|:-----------------------------------------------------------|
 |  `uintN`  | Type of `N` bits unsigned integer, where ``N % 8 == 0``.   |
 
-
 Convert directly to bytes the size of the int. (e.g. ``uint16 = 2 bytes``)
 
 All integers are serialized as **little endian**.
@@ -145,7 +143,6 @@ Lists are a collection of elements of the same homogeneous type.
 |:--------------------------------------------|:----------------------------|
 | Length of serialized list fits into 4 bytes | ``len(serialized) < 2**32`` |
 
-
 1. Get the number of raw bytes to serialize: it is ``len(list) * sizeof(element)``.
    * Encode that as a `4-byte` **little endian** `uint32`.
 2. Append the elements in a packed manner.
@@ -174,7 +171,6 @@ A container represents a heterogenous, associative collection of key-value pairs
 
 To serialize a container, obtain the list of its field's names in the specified order. For each field name in this list, obtain the corresponding value and serialize it. Tightly pack the complete set of serialized values in the same order as the field names into a buffer. Calculate the size of this buffer of serialized bytes and encode as a `4-byte` **little endian** `uint32`. Prepend the encoded length to the buffer. The result of this concatenation is the final serialized value of the container.
 
-
 | Check to perform                            | Code                        |
 |:--------------------------------------------|:----------------------------|
 | Length of serialized fields fits into 4 bytes | ``len(serialized) < 2**32`` |
@@ -238,7 +234,6 @@ At the final step, the following checks should be made:
 |:-------------------------|:-------------------------------------|
 | Ensure no extra length   | `new_index == len(rawbytes)`         |
 
-
 #### uint
 
 Convert directly from bytes into integer utilising the number of bytes the same
@@ -453,6 +448,5 @@ return hash(b''.join([hash_tree_root(getattr(x, field)) for field in value.field
 |   Go   | [ https://github.com/prysmaticlabs/prysm/tree/master/shared/ssz ](https://github.com/prysmaticlabs/prysm/tree/master/shared/ssz) | Go implementation of SSZ mantained by Prysmatic Labs |
 |  Swift | [ https://github.com/yeeth/SimpleSerialize.swift ](https://github.com/yeeth/SimpleSerialize.swift) | Swift implementation maintained SSZ |
 
-
 ## Copyright
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

From a182fdaa6f3ca43ff7c5f57fcf3bc34d5b2d8869 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Thu, 24 Jan 2019 22:07:41 -0700
Subject: [PATCH 37/44] pr feedback

---
 specs/validator/0_beacon-chain-validator.md | 56 ++++++++-------------
 1 file changed, 20 insertions(+), 36 deletions(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index 6d3a1976b..f1e650884 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -16,8 +16,6 @@ __NOTICE__: This document is a work-in-progress for researchers and implementers
         - [Initialization](#initialization)
             - [BLS public key](#bls-public-key)
             - [BLS withdrawal key](#bls-withdrawal-key)
-            - [RANDAO commitment](#randao-commitment)
-            - [Custody commitment](#custody-commitment)
         - [Submit deposit](#submit-deposit)
         - [Process deposit](#process-deposit)
         - [Validator index](#validator-index)
@@ -60,9 +58,9 @@ __NOTICE__: This document is a work-in-progress for researchers and implementers
 
 ## Introduction
 
-This document represents the expected behavior of an "honest validator" with respect to Phase 0 of the Ethereum 2.0 protocol. This document does not distinguish between a "node" and a "validator client". The separation of concerns between these (potentially) two pieces of software is left as a design decision that is outside of scope.
+This document represents the expected behavior of an "honest validator" with respect to Phase 0 of the Ethereum 2.0 protocol. This document does not distinguish between a "node" (ie. the functionality of following and reading the beacon chain) and a "validator client" (ie. the functionality of actively participating in consensus). The separation of concerns between these (potentially) two pieces of software is left as a design decision that is out of scope.
 
-A validator is an entity that participates in the consensus of the Ethereum 2.0 protocol. This is an optional role for users in which they can post ETH as collateral to seek financial returns in exchange for building and securing the protocol. This is similar to proof of work networks in which a miner provides collateral in the form of hardware/hash-power to seek returns in exchange for building and securing the protocol.
+A validator is an entity that participates in the consensus of the Ethereum 2.0 protocol. This is an optional role for users in which they can post ETH as collateral and verify and attest to the validity of blocks to seek financial returns in exchange for building and securing the protocol. This is similar to proof of work networks in which a miner provides collateral in the form of hardware/hash-power to seek returns in exchange for building and securing the protocol.
 
 ## Prerequisites
 
@@ -94,32 +92,6 @@ The validator constructs their `withdrawal_credentials` through the following:
 * Set `withdrawal_credentials[:1] == BLS_WITHDRAWAL_PREFIX_BYTE`.
 * Set `withdrawal_credentials[1:] == hash(withdrawal_pubkey)[1:]`.
 
-#### RANDAO commitment
-
-A validator's RANDAO commitment is the outermost layer of a 32-byte hash-onion. To create this commitment, perform the following steps:
-
-* Randomly generate a 32-byte `randao_seed`.
-* Store this `randao_seed` in a secure location.
-* Calculate `randao_commitment = repeat_hash(randao_seed, n)` where `n` is large enough such that within the lifetime of the validator, the validator will not propose more than `n` beacon chain blocks.
-
-Assuming `>= 100k validators`, on average a validator will have an opportunity to reveal once every `>= 600k seconds`, so `<= 50 times per year`. At this estimate, `n == 5000` would last a century. If this value is poorly configured and a validator runs out of layers of to reveal, the validator can no longer propose beacon blocks and should exit.
-
-_Note_: A validator must be able to reveal the next layer deep from their current commitment at any time. There are many strategies that trade off space and computation to be able to provide this reveal. At one end of this trade-off, a validator might only store their `randao_seed` and repeat the `repeat_hash` calculation on the fly to re-calculate the layer `n-1` for the reveal. On the other end of this trade-off, a validator might store _all_ layers of the hash-onion and not have to perform any calculations to retrieve the layer `n-1`. A more sensible strategy might be to store every `m`th layer as cached references to recalculate the intermittent layers as needed.
-
-#### Custody commitment
-
-A validator's custody commitment is the outermost layer of a 32-byte hash-onion. To create this commitment, perform the following steps:
-
-* Randomly generate a 32-byte `custody_seed`.
-* Store this `custody_seed` in a secure location.
-* Calculate `custody_commitment = repeat_hash(custody_seed, n)` where `n` is large enough such that within the lifetime of the validator, the validator will not attest to more than `n` beacon chain blocks.
-
-Assuming a validator changes their `custody_seed` with frequency `>= 1 week`, the validator changes their seed approximately `<= 50 times per year`. At this estimate, `n == 5000` would last a century. If this value is poorly configured and a validator runs out of layers of to reveal, the validator can no longer update their `custody_commitment` and should exit.
-
-See above note on hash-onion caching strategies in [RANDAO commitment](#randao-commitment).
-
-_Note_: although this commitment is being committed to and stored in phase 0, it will not be used until phase 1.
-
 ### Submit deposit
 
 In phase 0, all incoming validator deposits originate from the Ethereum 1.0 PoW chain. Deposits are made to the [deposit contract](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#ethereum-10-deposit-contract) located at `DEPOSIT_CONTRACT_ADDRESS`. 
@@ -133,7 +105,7 @@ To submit a deposit:
 * Let `amount` be the amount in Gwei to be deposited by the validator where `MIN_DEPOSIT_AMOUNT <= amount <= MAX_DEPOSIT_AMOUNT`.
 * Send a transaction on the Ethereum 1.0 chain to `DEPOSIT_CONTRACT_ADDRESS` executing `deposit` along with `deposit_input` as the singular `bytes` input along with a deposit `amount` in Gwei.
 
-_Note_: Multiple deposits can be made by the same validator (same initialization params). A singular `Validator` will be added to `state.validator_registry` with each deposit amount being added to the validator's balance. A validator can only be activated when total deposits meet or exceed 
+_Note_: Deposits made for the same `pubkey` are treated as for the same validator. A singular `Validator` will be added to `state.validator_registry` with each additional deposit amount added to the validator's balance. A validator can only be activated when total deposits for the validator pubkey meet or exceed `MAX_DEPOSIT_AMOUNT`.
 
 ### Process deposit
 
@@ -141,7 +113,7 @@ Deposits cannot be processed into the beacon chain until the eth1.0 block in whi
 
 ### Validator index
 
-Once a validator has been processed and added to the state's `validator_registry`, the validator's `validator_index` is defined by the index into the registry at which the [`ValidatorRecord`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#validatorrecord) contains the `pubkey` specified in the validator's deposit. This `validator_index` is used throughout the specification to dictate validator roles and responsibilities at any point and should be stored locally.
+Once a validator has been processed and added to the state's `validator_registry`, the validator's `validator_index` is defined by the index into the registry at which the [`ValidatorRecord`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#validatorrecord) contains the `pubkey` specified in the validator's deposit. A validator's `validator_index` is guaranteed to not change from the time of initial deposit until the validator exists and fully withdraws. This `validator_index` is used throughout the specification to dictate validator roles and responsibilities at any point and should be stored locally.
 
 ### Activation
 
@@ -186,7 +158,19 @@ _Note_: To calculate `state_root`, the validator should first run the state tran
 
 ##### Randao reveal
 
-Set `block.randao_reveal` to the `n`th layer deep reveal from the validator's current `randao_commitment` where `n = validator.randao_layers + 1`. `block.randao_reveal` should satisfy `repeat_hash(block.randao_reveal, validator.randao_layers + 1) == validator.randao_commitment`.
+Set `block.randao_reveal = reveal_signature` where `reveal_signature` is defined as:
+
+```python
+reveal_signature = bls_sign(
+    privkey=validator.privkey,  # privkey store locally, not in state
+    message=int_to_bytes32(validator.proposer_slots + 1),
+    domain=get_domain(
+        fork_data,  # `fork_data` is the fork_data at the slot `block.slot`
+        block.slot,
+        DOMAIN_RANDAO,
+    )
+)
+```
 
 ##### Eth1 Data
 
@@ -220,8 +204,8 @@ signed_proposal_data = bls_sign(
     privkey=validator.privkey,  # privkey store locally, not in state
     message=proposal_root,
     domain=get_domain(
-        state.fork_data,  # `state` is the resulting state of `block` transition
-        state.slot,
+        fork_data,  # `fork_data` is the fork_data at the slot `block.slot`
+        block.slot,
         DOMAIN_PROPOSAL,
     )
 )
@@ -239,7 +223,7 @@ Up to `MAX_CASPER_SLASHINGS` [`CasperSlashing`](https://github.com/ethereum/eth2
 
 ##### Attestations
 
-Up to `MAX_ATTESTATIONS` aggregate attestations can be included in the `block`. The attestations added must satisfy the verification conditions found in [attestation processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestations-1). To maximize profit, the validator should attempt to add aggregate attestations that include the most available that have not previously been added on chain.
+Up to `MAX_ATTESTATIONS` aggregate attestations can be included in the `block`. The attestations added must satisfy the verification conditions found in [attestation processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#attestations-1). To maximize profit, the validator should attempt to create aggregate attestations that include singular attestations from the largest number of validators whose signatures from the same epoch have not previously been added on chain.
 
 ##### Deposits
 

From 1614f2a9d798b042a248ab7f8b19b781054230b8 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Thu, 24 Jan 2019 23:11:40 -0700
Subject: [PATCH 38/44] simplify slashing instructions in vlaidator guide

---
 specs/validator/0_beacon-chain-validator.md | 19 ++++---------------
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/specs/validator/0_beacon-chain-validator.md b/specs/validator/0_beacon-chain-validator.md
index f1e650884..29ec0c7e0 100644
--- a/specs/validator/0_beacon-chain-validator.md
+++ b/specs/validator/0_beacon-chain-validator.md
@@ -331,27 +331,16 @@ signed_attestation_data = bls_sign(
 
 "Slashing" is the burning of some amount of validator funds and immediate ejection from the active validator set. In Phase 0, there are two ways in which funds can be slashed -- [proposal slashing](#proposal-slashing) and [attestation slashing](#casper-slashing). Although being slashed has serious repercussions, it is simple enough to avoid being slashed all together by remaining _consistent_ with respect to the messages you have previously signed.
 
-_Note_: Signed data must be within the same `Fork` context to conflict. Messages cannot be slashed across forks.
+_Note_: Signed data must be within a sequential `Fork` context to conflict. Messages cannot be slashed across diverging forks. If the previous fork version is 1 and the chain splits into fork 2 and 102, messages from 1 can slashable against messages in forks 1, 2, and 102. Messages in 2 cannot be slashable against messages in 102 and vice versa.
 
 ### Proposal slashing
 
-To avoid "proposal slashings", a validator must not sign two conflicting [`ProposalSignedData`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#proposalsigneddata) (suggest renaming `ProposalData`) where conflicting is defined as having the same `slot` and `shard` but a different `block_root`.
+To avoid "proposal slashings", a validator must not sign two conflicting [`ProposalSignedData`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#proposalsigneddata) where conflicting is defined as having the same `slot` and `shard` but a different `block_root`. In phase 0, proposals are only made for the beacon chain (`shard == BEACON_CHAIN_SHARD_NUMBER`).
 
-The following helper can be run to check if two proposal messages conflict:
-
-```python
-def proposal_data_is_slashable(proposal_data_1: ProposalSignedData,
-                               proposal_data_2: ProposalSignedData) -> bool:
-    if (proposal_data_1.slot != proposal_data_2.slot):
-        return False
-    if (proposal_data_1.shard != proposal_data_2.shard):
-        return False
-        
-    return proposal_data_1.block_root != proposal_data_2.block_root
-```
+In phase 0, as long as the validator does not sign two different beacon chain proposals for the same slot, the validator is safe against proposal slashings.
 
 Specifically, when signing an `BeaconBlock`, a validator should perform the following steps in the following order:
-1. Save a record to hard disk that an beacon block has been signed for the `slot` and `shard`.
+1. Save a record to hard disk that an beacon block has been signed for the `slot=slot` and `shard=BEACON_CHAIN_SHARD_NUMBER`.
 2. Generate and broadcast the block.
 
 If the software crashes at some point within this routine, then when the validator comes back online the hard disk has the record of the _potentially_ signed/broadcast block and can effectively avoid slashing.

From 0254bc8d177dc916ee902c1cfc1ed5ad7538f6dd Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Thu, 24 Jan 2019 23:17:56 -0700
Subject: [PATCH 39/44] pr feedback

---
 specs/core/0_beacon-chain.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
index daf0cae7e..0cc239866 100644
--- a/specs/core/0_beacon-chain.md
+++ b/specs/core/0_beacon-chain.md
@@ -912,7 +912,7 @@ def get_shuffling(seed: Bytes32,
     return split(shuffled_active_validator_indices, committees_per_slot * EPOCH_LENGTH)
 ```
 
-**Invariant**: if `get_shuffling(seed, validators, slot)` returns some value `x` and `slot <= state.slot + ENTRY_EXIT_DELAY`, it should return the same value `x` for the same `seed` and `slot` and possible future modifications of `validators` forever in phase 0, and until the ~1 year deletion delay in phase 2 and in the future.
+**Invariant**: if `get_shuffling(seed, validators, slot)` returns some value `x` for some `slot <= state.slot + ENTRY_EXIT_DELAY`, it should return the same value `x` for the same `seed` and `slot` and possible future modifications of `validators` forever in phase 0, and until the ~1 year deletion delay in phase 2 and in the future.
 
 **Note**: this definition and the next few definitions make heavy use of repetitive computing. Production implementations are expected to appropriately use caching/memoization to avoid redoing work.
 

From f61d3643521b9ad06642c8a2026be22fe9f5735d Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Fri, 25 Jan 2019 14:56:10 -0700
Subject: [PATCH 40/44] clean up top language in validator registry section

---
 specs/core/0_beacon-chain.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
index 4cecb4ddd..ddfb833f8 100644
--- a/specs/core/0_beacon-chain.md
+++ b/specs/core/0_beacon-chain.md
@@ -1701,7 +1701,7 @@ def process_ejections(state: BeaconState) -> None:
 
 ### Validator registry and shuffling seed data
 
-First, update `previous_epoch_calculation_slot`, `previous_epoch_start_shard` and `latest_index_roots`:
+First, update the following:
 
 * Set `state.previous_epoch_calculation_slot = state.current_epoch_calculation_slot`
 * Set `state.previous_epoch_start_shard = state.current_epoch_start_shard`

From f96cd871b1e9b48f54b23cab106937d5f9d66cc3 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Fri, 25 Jan 2019 15:25:19 -0700
Subject: [PATCH 41/44] update ordering of assignments

---
 specs/core/0_beacon-chain.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
index ddfb833f8..dc9fadd54 100644
--- a/specs/core/0_beacon-chain.md
+++ b/specs/core/0_beacon-chain.md
@@ -1705,8 +1705,8 @@ First, update the following:
 
 * Set `state.previous_epoch_calculation_slot = state.current_epoch_calculation_slot`
 * Set `state.previous_epoch_start_shard = state.current_epoch_start_shard`
-* Set `state.latest_index_roots[epoch % LATEST_INDEX_ROOTS_LENGTH] = hash_tree_root(get_active_validator_indices(state, state.slot))`
 * Set `state.previous_epoch_seed = state.current_epoch_seed`
+* Set `state.latest_index_roots[epoch % LATEST_INDEX_ROOTS_LENGTH] = hash_tree_root(get_active_validator_indices(state, state.slot))`
 
 If the following are satisfied:
 

From 86faacdcd2fdebda137b0ce661553d7e4286e4b4 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Fri, 25 Jan 2019 15:27:27 -0700
Subject: [PATCH 42/44] clarify assignments in val reg not change

---
 specs/core/0_beacon-chain.md | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
index dc9fadd54..b6dc26a7a 100644
--- a/specs/core/0_beacon-chain.md
+++ b/specs/core/0_beacon-chain.md
@@ -1768,7 +1768,10 @@ and perform the following updates:
 If a validator registry update does _not_ happen do the following:
 
 * Let `epochs_since_last_registry_change = (state.slot - state.validator_registry_update_slot) // EPOCH_LENGTH`.
-* If `epochs_since_last_registry_change` is an exact power of 2, set `state.current_epoch_calculation_slot = state.slot` and `state.current_epoch_seed = hash(get_randao_mix(state, state.current_epoch_calculation_slot - SEED_LOOKAHEAD) + get_active_index_root(state, state.current_epoch_calculation_slot))`. Note that `state.current_epoch_start_shard` is left unchanged.
+* If `epochs_since_last_registry_change` is an exact power of 2:
+    * Set `state.current_epoch_calculation_slot = state.slot`
+    * Set `state.current_epoch_seed = hash(get_randao_mix(state, state.current_epoch_calculation_slot - SEED_LOOKAHEAD) + get_active_index_root(state, state.current_epoch_calculation_slot))`.
+    * _Note_ that `state.current_epoch_start_shard` is left unchanged.
 
 **Invariant**: the active index root that is hashed into the shuffling seed actually is the `hash_tree_root` of the validator set that is used for that epoch.
 

From 56037726210fa6e79be3afe974c6284ad4eb18fe Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Fri, 25 Jan 2019 15:28:08 -0700
Subject: [PATCH 43/44] add missing period

---
 specs/core/0_beacon-chain.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
index b6dc26a7a..d949af716 100644
--- a/specs/core/0_beacon-chain.md
+++ b/specs/core/0_beacon-chain.md
@@ -1769,7 +1769,7 @@ If a validator registry update does _not_ happen do the following:
 
 * Let `epochs_since_last_registry_change = (state.slot - state.validator_registry_update_slot) // EPOCH_LENGTH`.
 * If `epochs_since_last_registry_change` is an exact power of 2:
-    * Set `state.current_epoch_calculation_slot = state.slot`
+    * Set `state.current_epoch_calculation_slot = state.slot`.
     * Set `state.current_epoch_seed = hash(get_randao_mix(state, state.current_epoch_calculation_slot - SEED_LOOKAHEAD) + get_active_index_root(state, state.current_epoch_calculation_slot))`.
     * _Note_ that `state.current_epoch_start_shard` is left unchanged.
 

From 85d39af1cad0e4869944be8bdcbfb75b7c3c64f6 Mon Sep 17 00:00:00 2001
From: Danny Ryan <dannyjryan@gmail.com>
Date: Fri, 25 Jan 2019 15:28:49 -0700
Subject: [PATCH 44/44] add missing period

---
 specs/core/0_beacon-chain.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/core/0_beacon-chain.md b/specs/core/0_beacon-chain.md
index d949af716..8eaa2b5e4 100644
--- a/specs/core/0_beacon-chain.md
+++ b/specs/core/0_beacon-chain.md
@@ -1815,7 +1815,7 @@ def process_penalties_and_exits(state: BeaconState) -> None:
 ### Final updates
 
 * Let `epoch = state.slot // EPOCH_LENGTH`.
-* Set `state.latest_penalized_balances[(epoch+1) % LATEST_PENALIZED_EXIT_LENGTH] = state.latest_penalized_balances[epoch % LATEST_PENALIZED_EXIT_LENGTH]`
+* Set `state.latest_penalized_balances[(epoch+1) % LATEST_PENALIZED_EXIT_LENGTH] = state.latest_penalized_balances[epoch % LATEST_PENALIZED_EXIT_LENGTH]`.
 * Remove any `attestation` in `state.latest_attestations` such that `attestation.data.slot < state.slot - EPOCH_LENGTH`.
 
 ## State root processing