Kill dust accounts

[gavofyork]

Specification

Variant A

Following on from the definitions of EIP #161:

At the end of the transaction, any account touched by the execution of that transaction which is now dust SHALL instead become non-existent (i.e. deleted).

Where:

An account is considered dust when it has a balance less than KEEPALIVE_DEPOSIT and no code.

KEEPALIVE_DEPOSIT is a constant equal to 420 Szabo.

Variant B

Following on from the definitions of EIP #161:

At the end of any transaction, if the account sending that transaction has a balance of less than the transaction's gas_price multiplied by 21000, it SHALL become non-existent (i.e. deleted).

Variant C

Following on from the definitions of EIP #161:

At the end of the transaction, any account created or whose balance is decreased by the execution of that transaction which is now dust SHALL instead become non-existent (i.e. deleted).

Where:

An account is considered dust when it has a balance less than the transaction's gas_price multiplied by 21000 and no code.

Notes

This PR basically means that for any account to continue in existence on the Ethereum network it must have a minimum balance. Whenever the balance drops below the system constant KEEPALIVE_DEPOSIT the account would be deleted. Any remaining balance would be effectively burnt, any code or storage would cease to function and the effective nonce would become zero.

An important consequence of this is that accounts would become immediately insecure and susceptible to a variety of transaction-replay attacks if the balance were ever to drop too low. This means that third-party tools, particularly wallets, will need to ensure that any transaction which would result in an account's balance dropping to the point of being deleted is:

a) impossible to do without the user being told it will actually delete the account and make it no longer usable; and
b) that once done, the account is marked dead in the UI, indicating clearly that it should no longer be used to receive funds.

A more complex EIP could include a mechanism allowing it to increase or decrease over time according to miners' preferences similarly to the gas limit. To avoid a malicious miner cartel reducing it too speedily and compromising accounts with small but significant balances, the speed of movement of the limit should be slow, perhaps around 1.5x per month.

A still more complex variant would involve forcing miners to pay ether in order to raise the gas limit temporarily. From this behaviour, a reasonable gas price could be derived and from that a reasonable value for KEEPALIVE_DEPOSIT.

Rationale

The state trie is become clogged with dust accounts which, practically-speaking, are systematically created and orphaned at industrial volumes by irresponsible members of the Ethereum community. One particular offender, the operator of a popular exchange, produces around thousands of new dust accounts per day. Naively encoded, each such account adds around 100 bytes to the state trie. Overall this results in the storage and synchronisation bandwidth requirements of Ethereum needlessly increasing by up to 1 MB per day.

Implementing this EIP would allow around 500k accounts to be removed from the state, immediately saving up to 50 MB from databases and state-based synchronisation bandwidth. It would also prevent any new ones from being created, providing continued cumulative savings.

KEEPALIVE_DEPOSIT is defined as the current average cost in Ether to send a basic transaction, following from the assertion that a basic account is useless if it no longer has enough funds to send a basic transaction.

Contracts (at least those pre-existing) should be spared from this mechanism, through the requirement of dust accounts having no code, since their continued existence may be an important guarantee that caused prior actions to take place.

[vbuterin]

This would work as a one-time clearing measure. For the longer term, once existing dust is cleared, I'm inclined to say that instead of having a fixed keepalive deposit, we say that if an account, after sending a transaction, has remaining ether less than that transaction's current gasprice times 21000, then the account should be deleted.

[pipermerriam]

has remaining ether less than that transaction's current gasprice times 21000, then the account should be deleted.

If I understand correctly, this could be a very bad rule that ends up deleting accounts that should not be considered dusty. If someone sends a transaction with an extremely high gas price then this would end up wiping out their account entirely even though it still has plenty of ether in it.

[gumb0]

Some more recent data points I've collected while playing with warp snapshots.

As of block 4,945,000 (Jan-21-2018)
out of total ~23M accounts there are 12,53,9049 accounts that have balance < 420 szabo and no code.

And state trie DB savings in case of cpp-ethereum would be
9.7 Gb with dust vs 7.3 Gb without dust
(that's full state trie for one block, with storage and code and without prehashes)

Also for the price of ether around $1000 420 szabo is around $0.42.

[gumb0]

The graph of balances of accounts without code
x: account balance in wei, log scale
y: number of non-contract accounts with balance <= x

420 szabo is approximately the middle of x-axis.

y-axes doesn't start at 0, because there are 10,230,424 accounts with balance 0. (so the line starts at (0, ~10^7) )

[alexvandesande]

My opinion that 420 Szabo is extremely high. Anything that is in the order of magnitude of cents, can become actual money depending on the very volatile market. It wasn't that long ago that 0.42 ether was worth $0.42.

I would prefer some longer term change: either introduce a "rent" concept where accounts would have to pay weis for storage or just create other styles of scalability.

Also, it's important to note that the unintended consequence of this EIP is that it might encourage users to use wallet contracts when they didn't need one, or to use wrapped eth instead of eth, which can end up using even more space. It also creates another difference between normal accounts and contracts, which might create issues.

[pirapira]

I oppose account removals without the consent of the affected private key holders. There is no method to tell all of them about the to-be-removed accounts.

[AlexeyAkhunov]

More data in this blog post for reference: https://medium.com/@akhounov/more-data-for-eip-168-kill-dust-accounts-83e8dd0938d3

[realcodywburns]

Rather than burning coins, why not add the dust to the blockreward of the block in which the transaction occurs that would drop an account below keepalive level. Burning coins, even dust, feels wasteful.

[moeadham]

"One particular offender, the operator of a popular exchange, produces around thousands of new dust accounts per day."

Could we not first ask the offender (ex. s-s dot io) to reconsider their implementation, and attempt to clean up their current mess, before penalizing all users of the network?

[damientam]

The proposal does not solve the problem
This policy could be bypassed easely by the offender simply by adding dumb code in the soon-to-be affected account.

The proposal creates other, bigger problems
This could also lead to destruction of account without their holder's knowledge. This destruction process could happened in the middle of an operation of exchange for example, Coins would leave, to be replaced by other coins soon, but when the new coins arrive, the account has been deleted.

[fergarrui]

What if an account is eligible to be deleted but it has, for example ERC20 tokens balances in some contract(s)?

[Arachnid]

@fergarrui Deleting the account will not affect its token balances.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.