add references for EIPs 158 and 161

EIPS/eip-158.md

@@ -35,3 +35,8 @@ Do not implement point 2 above (ie. no new empty accounts can be created, but ex
 This removes a large number of empty accounts that have been put in the state at very low cost due to flaws in earlier versions of the Ethereum protocol, thereby greatly reducing state size and hence both reducing the hard disk load of a full client and reducing the time for a fast sync. Additionally, it simplifies the protocol in the long term, as once all "empty" objects are cleared out there is no longer any meaningful distinction between an account being empty and being nonexistent, and indeed one can simply view nonexistence as a compact representation of emptiness.
 
 Note that this proposal does introduce a **temporary** breaking of existing guarantees, in that by repeatedly zero-value-calling already existing empty accounts one can create a state change at a cost of 700 gas per account instead of the usual 5000 per gas minimum (with SUICIDE refunds this goes down further to 350 gas per account). Allowing such a large number of state writes per block will lead to heightened block processing times and increase uncle rates in the short term while the existing empty accounts are being cleared, and eventually once all empty accounts are cleared this issue will no longer exist.
+
+# References
+
+1. EIP-158 issue and discussion: https://github.com/ethereum/EIPs/issues/158
+2. EIP-161 issue and discussion: https://github.com/ethereum/EIPs/issues/161

EIPS/eip-161.md

@@ -49,3 +49,8 @@ Same as #158 except that several edge cases are avoided since we do not break in
 - that a newly created account cannot be deleted prior to being deployed.
 
 `CREATE` avoids zero in the nonce to avoid any suggestion of the oddity of `CREATE`d accounts being reaped half-way through their creation.
+
+# References
+
+1. EIP-158 issue and discussion: https://github.com/ethereum/EIPs/issues/158
+2. EIP-161 issue and discussion: https://github.com/ethereum/EIPs/issues/161