* Add RandaoRevealSlashing for early Randao reveals
* add some randao reveal slashing tests
* Unifying RANDAO reveal slashing and Custody reveal slashing; implemented more lenient penalty for not-to-early reveals
* Fix custody reveal domain
* Also test exposed_randao_reveals
* Re-add exposed_randao_reveals to validator initialization
* Fix tests
* Unified Randao Reveal slashing mechanism and Custody Reveal,
CUSTODY_PERIOD_TO_RANDAO_PADDING = EPOCHS_PER_CUSTODY_PERIOD
* Move exposed_randao_reveals into separate data structure to keep validator record clean
* new shiny staggered custody periods
* Fixes style and type hinting
* removes whitespace
* Cleans up multi-line conditionals
* Make RANDAO key reveal penalties proportional to block rewards
* Minor typos
* Minor typos
* Fixes off-by one error
* Removes unnecicary whitepsace
* Clean up comments; add test for key reveal too far in the future
* Reduce the CUSTODY_PERIOD_TO_RANDAO_PADDING again
* Fix max_proposer_slot_reward
* Fix types
* Move test
* Fix RandaoKeyReveal tests
* Move all RANDAO key reveal to phase 1
* Factor out signature checking
* Some fixes
* Update specs/core/1_custody-game.md
Co-Authored-By: dankrad <dankrad@ethereum.org>
* Addressing Vitalik's suggestions: Separate RANDAO and Custody key reveals; append the cleanup of RANDAO reveals instead of adding a new function
* Remove remnants of verify_custody_key
* RandaoKeyReveal -> EarlyDerivedSecretReveal
* Make penalty proportional to number of secrets already exposed
* Update specs/core/1_custody-game.md
Co-Authored-By: dankrad <dankrad@ethereum.org>
* Update specs/core/1_custody-game.md
Co-Authored-By: dankrad <dankrad@ethereum.org>
* Update specs/core/1_custody-game.md
Co-Authored-By: dankrad <dankrad@ethereum.org>
* Custody game changes
1. Don't store the full chunk bits, instead only store a Merkle root. Increased history size complexity from `N` to `N + log(N)` but with the benefit of decreasing storage requirements from `N` to a single 32 byte hash.
2. `custody_bit` is computed as the first bit of the hash of the custody bits, not the xor. This allows us to more safely use functions with more risky security assumptions for computing the chunk mix.
* Update specs/core/1_custody-game.md
* Update specs/core/1_custody-game.md
* Update specs/core/1_custody-game.md
* Update specs/core/1_custody-game.md
* XOR aggregation before SHA256 to reduce number of hashes
* Simplifed get_chunk_bits_root
* standalone -> indexed
* Fix missing "data" and ToC
Cosmetic changes:
* Add 4 lines of comments (now every statement has a comment)
* Avoid unnecessary `assert` (the end goal for me is for `assert`s to be exclusive to the operation processing helpers).
* Merge `return`s into one (increase readability, reduce verbosity)
* Use shorter-named `bit_0_indices` and `bit_1_indices` helper variables
Substantive change:
* Remove the condition that `len(0_indices) + len(1_indices) > 0`. This condition is redundant in the context of `process_attester_slashing` because of `slashed_any`. It is largely artificial in `process_attestation` where validators are incentivised to maximise new attestations.
The state transition spec should be reasonably self-contained, limiting the amount of "magic" outside of it. This PR is a first step in this direction, specifically for operation processing.
Add 32-byte of arbitrary "graffiti" data in beacon blocks, in a similar vein to `extraData` in Eth1. To be used in wonderful and unpredictable ways (permissionless innovation by block proposers).
* Remove `get_crosslink_committees_at_slot` (that function's ugly man...)
* Make the "base" that everything works off instead be `get_crosslink_committee`
* Attestations store epoch, start shard and shard, no longer slot (slot can be calculated from the other three)
* Retaining start shard in attestations allows `get_attesting_indices` to peek much further back into the past, making it useful for slashings (Phase 1)
* Some two-layer-deep nested loops become one-layer-deep loops
* Initialisation bug: initial `effective_balance` be not greater than `MAX_EFFECTIVE_BALANCE`
* Hysteresis bug: do not prevent `effective_balance` to go from `MAX_EFFECTIVE_BALANCE - 1` to `MAX_EFFECTIVE_BALANCE`
Fix bug [flagged by @NIC619 and @hwwhww](https://github.com/ethereum/eth2.0-specs/pull/850#issuecomment-485275575) whereby the `activation_epoch` of validators dequeued since the finalized epoch was overwritten.
Cosmetic changes:
1) Remove `activate_validator` (there is no overlap between genesis and non-genesis activations)
2) Improve comments related to activation queue
As discussed in yesterday's call, temporarily disable transfers until the network is deemed stable enough. We can consider doing a "test-run hard fork" changing this constant prior to the phase 1 hard fork.
Danny Ryan
Justin
vbuterin
Hsiao-Wei Wang
dankrad
terence tsao
Alex Stokes
JSON
Carl Beekhuizen
Diederik Loerakker