Automatically merged updates to draft EIP(s) 1344 (#2215)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-1344.md

@@ -20,6 +20,8 @@ This EIP adds an opcode that returns the current chain's EIP-155 unique identifi
 ## Specification
 Adds a new opcode `CHAINID` at 0x46, which uses 0 stack arguments. It pushes the current chain ID onto the stack. The operation costs `G_base` to execute.
 
+The value of the current chain ID is obtained from the chain ID configuration, which should match the EIP-155 unique identifier a client will accept from incoming transactions. Please note that per EIP-155, it is not *required* that a transaction have an EIP-155 unique identifier, but in that scenario this opcode will still return the configured chain ID and not a default.
+
 ## Rationale
 The current approach proposed by EIP-712 is to specify the chain ID at compile time. Using this approach will result in problems after a hardfork, as well as human error that may lead to loss of funds or replay attacks on signed messages.
 By adding the proposed opcode it will be possible to access the current chain ID and validate signatures based on that.
@@ -42,7 +44,8 @@ This was previously suggested as part of [EIP901](https://github.com/ethereum/EI
 TBD
 
 ## Implementation
-A sample implementation was attempted here: https://github.com/fubuloubu/py-evm/commit/eaab5ffa2164d4cc06ae5c855a49d030965be828
+A reference implementation is here:
+https://github.com/fubuloubu/py-evm/tree/eip1344-chain-id
 
 An example implementation of a trustless chain ID oracle was implemented here:
 https://github.com/fubuloubu/chain-id-oracle/blob/master/ChainIdOracle.vy