Question: What happens if the block proposer at the `POW_RECEIPT_ROOT_VOTING_PERIOD` boundary puts a bad receipt root? Does this give too much power to that block proposer?
* Separated out proposer from validators
* Update 0_beacon-chain.md
* Update specs/core/0_beacon-chain.md
Co-Authored-By: vbuterin <v@buterin.com>
* Update specs/core/0_beacon-chain.md
Co-Authored-By: vbuterin <v@buterin.com>
* get_proposer -> get_beacon_proposer, block -> slot
* Move proposer sig to the end of a block
* Update specs/core/0_beacon-chain.md
Co-Authored-By: vbuterin <v@buterin.com>
* sig -> signature
* add type hints for get_beacon_proposer
Also adjusted constants to keep interest rates and the quadratic leak period the same.
Also, did some simplifications of the cycle calculation procedure. Make the decision to remove automatic registration of a validator as a proposer when they join, because that can just happen on its own due to the reshuffling procedure.
* pack small items tightly to fit more items in single chunk, decreasing
the number of hash operations needed
* remove chunk padding - hash algorithm will pad to its own block size
anyway
* express data length in number of items instead of binary bytes at leaf
level (equivalent)
Moves the procedure for handling specials into the per-block processing loop. Cleans up the specification for handling them to be more unambiguous, and changes the formats to be more readable and simpler to implement.
* Added tree hashing algorithm
* Update simple-serialize.md
* add one more ref to tree_hash
* Add the zero-item special case
* list_to_glob to handle empty list
