## Eip 210 ### Issue A: `BLOCKHASH` semantics @vbuterin's intent when writing the EIP was that the `BLOCKHASH` operation would still only return the most recent 256 blockhashes, and nothing older than that. For fetching older stuff, a contract would need to `CALL` the contract. #### Alternative one: Modify the EIP to make it clear that `BLOCKHASH` retains the earlier semantics. Consequences: * If so, clients do not necessarily need to modify anything regarding `BLOCKHASH`, except raising `gasCost`. * Since contracts will `CALL` the contract, perhaps it should be made `ABI`-compatible. * Either via ignoring the first 4 bytes, allowing any signature * Or explicity expecting signature `blockhash(uint256)` #### Alternative two: Don't modify the EIP, use it as written. Consequences: * Changes `blockhash` semantics (but more useful) * Makes actually `CALL`ing the contract totally unnecessary (why would anyone ever do that?) * Forces clients to modify `BLOCKHASH` ### Issue B: Genesis lookup Should we add support for the contract to return the genesis hash? Consequences: 1. Would complicate contract creation a bit * Either via stuffing the genesis hash into the contract code * Or via setting genesis hash in storage 2. Would increase runtime cost a bit