Move EIP assets to assets folder (#977)

- Create `assets` folder
- Move existing EIPs (1, 107, 858) assets into the `assets` folder
- Update link to assets in EIPs 1, 107 and 858
- Describe the inclusion of assets for EIPs in `README.md`

EIPS/eip-1.md

@@ -64,7 +64,7 @@ EIPs can also be superseded by a different EIP, rendering the original obsolete.
 
 The possible paths of the status of EIPs are as follows:
 
-![EIP Process](eip-1/process.png)
+![EIP Process](../assets/eip-1/process.png)
 
 Some Informational and Process EIPs may also have a status of “Active” if they are never meant to be completed. E.g. EIP 1 (this EIP).
 
@@ -114,7 +114,8 @@ Each EIP should have the following parts:
 EIP Formats and Templates
 -------------------------
 
-EIPs should be written in [markdown] format. Image files should be included in a subdirectory for that EIP.
+EIPs should be written in [markdown] format.
+Image files should be included in a subdirectory of the `assets` folder for that EIP as follow: `assets/eip-X` (for eip **X**). When linking to an image in the EIP, use relative links such as `../assets/eip-X/image.png`.
 
 EIP Header Preamble
 -------------------

EIPS/eip-107.md

@@ -29,19 +29,19 @@ Account unlocked :
 -----------------
 When the account is already unlocked, the user is presented with the following popup for every transaction that the dapp attempts to make:
 
-![](eip-107/authorization.png)
+![](../assets/eip-107/authorization.png)
 
 Account locked and no "personal" api exposed via rpc:
 -----------------
 When the account is locked, and the node does not provide access to account unlocking via its rpc interface, the following popup will be presented. This is not ideal since this requires the user to know how to unlock an account:
 
-![](eip-107/authorization-locked.png)
+![](../assets/eip-107/authorization-locked.png)
 
 Account locked but node exposing the "personal" api via rpc :
 -----------------
 A better option is to ask the user for their password, but this is only possible if the node allows access to the "personal" api via rpc. In such case, the following dialog will be presented to the user so he/she can accept the transaction by providing the password required to unlock the account:
 
-![](eip-107/authorization-password.png)
+![](../assets/eip-107/authorization-password.png)
 
 
 Specification

EIPS/eip-858.md

@@ -15,7 +15,7 @@ Reduce the block reward to 1 ETH.
 The current public Ethereum network has a hashrate that corresponds to a tremendous level of energy consumption. As this energy consumption has a correlated environmental cost the network participants have an ethical obligation to ensure this cost is not higher than necessary. At this time, the most direct way to reduce this cost is to lower the block reward in order to limit the appeal of ETH mining. Unchecked growth in hashrate is also counterproductive from a security standpoint.
 
 ## Motivation
-The current public Ethereum network has a hashrate of 232 TH/s). This hashrate corresponds to a **lower bound** for power usage of roughly [821 MW](eip-858/calculations.md) and yearly energy consumption of 7.2 TWh (roughly 0.033% of [total](https://en.wikipedia.org/wiki/List_of_countries_by_electricity_consumption) global electricity consumption). A future switch to full Proof of Stake will solve this issue entirely. Yet that switch remains enough in the future that action should be taken in the interim to limit excess harmful side affects of the present network.
+The current public Ethereum network has a hashrate of 232 TH/s). This hashrate corresponds to a **lower bound** for power usage of roughly [821 MW](../assets/eip-858/calculations.md) and yearly energy consumption of 7.2 TWh (roughly 0.033% of [total](https://en.wikipedia.org/wiki/List_of_countries_by_electricity_consumption) global electricity consumption). A future switch to full Proof of Stake will solve this issue entirely. Yet that switch remains enough in the future that action should be taken in the interim to limit excess harmful side affects of the present network.
 
 ## Specification
 Block reward to be changed to 1 ETH / block.

README.md

@@ -12,6 +12,8 @@ A browsable version of all current and draft EIPs can be found on [the official
 
 Your first PR should be a first draft of the final EIP. It must meet the formatting criteria enforced by the build (largely, correct metadata in the header). An editor will manually review the first PR for a new EIP and assign it a number before merging it. Make sure you include a `discussions-to` header with the URL to a discussion forum or open GitHub issue where people can discuss the EIP as a whole.
 
+If your EIP requires images, the image files should be included in a subdirectory of the `assets` folder for that EIP as follow: `assets/eip-X` (for eip **X**). When linking to an image in the EIP, use relative links such as `../assets/eip-X/image.png`.
+
 Once your first PR is merged, we have a bot that helps out by automatically merging PRs to draft EIPs. For this to work, it has to be able to tell that you own the draft being edited. Make sure that the 'author' line of your EIP contains either your Github username or your email address inside <triangular brackets>. If you use your email address, that address must be the one publicly shown on [your GitHub profile](https://github.com/settings/profile).
 
 When you believe your EIP is mature and ready to progress past the draft phase, you should do one of two things: