forked from ethereum/EIPs
-
Notifications
You must be signed in to change notification settings - Fork 12
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
EIP 1010: Uniformity Between Two Addresses (ethereum#1010)
* Create eip-draft_uniformity_between_0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B_and_0x15E55EF43efA8348dDaeAa455F16C43B64917e3c.md * Fix typo * Use pull request ID as tentative EIP I think this might fix the Travis CI build errors * Update and rename eip-draft_uniformity_between_0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B_and_0x15E55EF43efA8348dDaeAa455F16C43B64917e3c.md to eip-1010.md
- Loading branch information
1 parent
1059761
commit 4453f8f
Showing
1 changed file
with
69 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,69 @@ | ||
--- | ||
eip: 1010 | ||
title: Uniformity Between 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B and 0x15E55EF43efA8348dDaeAa455F16C43B64917e3c | ||
author: Anderson Wesley (@andywesley) | ||
discussions-to: https:/andywesley/EIPs/issues/1 | ||
status: Draft | ||
type: Standards Track | ||
category: Core | ||
created: 2018-04-18 | ||
--- | ||
|
||
## Simple Summary | ||
|
||
This document proposes to improve the uniformity of ether distribution | ||
between wallet address `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` and | ||
wallet address `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c` which are | ||
currently experiencing a significant non-uniformity. | ||
|
||
## Abstract | ||
|
||
As of the date of this EIP, the difference in balance between | ||
address `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` and address | ||
`0x15E55EF43efA8348dDaeAa455F16C43B64917e3c` is far from equitable | ||
or uniform, with the former having more than 365,000 ether | ||
more than the latter. The distribution of ether between these two | ||
addresses must be improved in order to protect the Ethereum economy | ||
from centralized control. This will be accomplished by transferring | ||
100,000 ether from the former address to the latter. This is a properly | ||
motivated improvement in keeping with the core Ethereum philosophy of | ||
decentralization. | ||
|
||
## Motivation | ||
|
||
This proposal is necessary because the Ethereum protocol does not allow | ||
the owner of an address which does not own an equitable amount of ether | ||
to claim their share of ether from an address which owns a dangerously | ||
centralized quantity. Rather than proposing an overly complicated generic | ||
mechanism for any user to claim ether to which they believe they are | ||
equitably entitled, this proposal will take the simple route of a one-time | ||
transfer of 100,000 ether from `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` | ||
to `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c`. This avoids duplicating | ||
the effort of other proposals and provides a net improvement to the | ||
Ethereum project and community. | ||
|
||
## Specification | ||
|
||
The balance of `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` will be decreased | ||
by 100,000 ether. The balance of `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c` | ||
will be increased by 100,000 ether. No net change in the amount of extant | ||
ether will occur unless at the time of implementation the former address does not | ||
contain sufficient ether for such a deduction. | ||
|
||
## Rationale | ||
|
||
The value 100,000 was chosen after careful technically sound analysis of various economic theories | ||
developed over the past century. In spite of the fact that it is a convenient round | ||
number, it is actually the exact output of a complex statistical process iterated to | ||
determine the optimal distribution of ether between these addresses. | ||
|
||
## Backwards Compatibility | ||
|
||
Clients that fail to implement this change will not be aware of the correct balances | ||
for these addresses. This will create a hard fork. The implementation of this change | ||
consistently among all clients as intended by the proposal process will be sufficient | ||
to ensure that backwards compatibility is not a concern. | ||
|
||
## Copyright | ||
Copyright and related rights waived via | ||
[CC0](https://creativecommons.org/publicdomain/zero/1.0/). |