mirror of https://github.com/status-im/EIPs.git
Use pretty URLs
This commit is contained in:
parent
aecc9b33dd
commit
264e8be5ed
|
@ -62,7 +62,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:
|
||||
|
||||
<img src=./eip-1/process.png>
|
||||
![](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).
|
||||
|
||||
|
|
|
@ -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:
|
||||
|
||||
<img src="./eip-107/authorization.png">
|
||||
![](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:
|
||||
|
||||
<img src="./eip-107/authorization-locked.png">
|
||||
![](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:
|
||||
|
||||
<img src="./eip-107/authorization-password.png">
|
||||
![](authorization-password.png")
|
||||
|
||||
|
||||
Specification
|
||||
|
|
|
@ -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](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.
|
||||
|
|
|
@ -31,6 +31,8 @@ theme: minima
|
|||
plugins:
|
||||
- jekyll-feed
|
||||
|
||||
permalink: slug
|
||||
|
||||
defaults:
|
||||
-
|
||||
scope:
|
||||
|
|
|
@ -4,7 +4,6 @@ layout: default
|
|||
|
||||
<div class="home">
|
||||
<h1 class="page-heading">EIP {{ page.eip | xml_escape }}: {{ page.title | xml_escape }}</h1>
|
||||
|
||||
<table>
|
||||
<tr><th>Author</th><td>{{ page.author | xml_escape }}</td></tr>
|
||||
{% if page["discussions-to"] != undefined %}
|
||||
|
|
Loading…
Reference in New Issue