Erosion.md

BIP - Erosion

Abstract

This proposal suggest redistributing stale UTXOs by letting miners collect them gradually (the stale funds "erode").

Summary

Erosion Mechanism

New block field redistList is define. It should contain a list of pairs addr , sat, where addr is an address and sat is an amount of satoshis, satisfying all of the following conditions.

1. No address appears twice.

2. The weight of the redistList field does no exceed 10,000 weight units (to avoid clogging the network in case erosion is available in abundance and is more profitable than fees).

3. Every pair must satisfy prevEroded + sat < ero(n) * addrUTXO, where addr holds addrUTXO unspent satoshis and was first spent to n blocks ago, prevEroded is the amount that was already redistributed (the sum of amounts that appear paired with addr in all previous blocks' redistList field), and ero is the erosion-factor function that has the following properties.

   1. Takes values between 0 to 1.
   2. Takes the value 0 for a large initial interval.
   3. Is monotonically increasing, eventually reaching 1.
   4. Has low inclination (increases slowly).

   (A simple example: ero(n) = 0 until n = 1,000,000, then increases by 0.001 every 10,000 blocks.)

   In other words, the condition specifies that the total erosion may never exceed some predefined ratio that this proposal shall define, which simulates (delayed) erosion from the moment funds are spendable at an address.

For the purpose of this proposal, all UTXOs are considered to have been spent at the block in which this soft fork is activated as a one-time exception, to give users proper time to learn about this change in consensus and refresh their UTXOs before they begin to erode.

Spending Eroded Funds

New transaction type redistSpend is accepted. Its input is a block number n. The spent amount must not exceed the sum of sats that appear in the redistList of block n, and its signature must match the one of the coinbase address of block n. It also may only appear in block with number over n+100.

In addition, other transactions are now rejected if they have previously been included in a redistList and do not subtract the sum of all redistributed satoshis (otherwise coins are just being duplicated).

Motivation

Market Transparency

Loss of access to funds are prevalent in Bitcoin due to loss of private keys. There are various methods to estimate which stale UTXOs are actually lost funds, but they are not very accurate, and they may never be. The most famous example are the funds in Satoshi's original account, which nobody knows whether they are lost or will be spent in the future.

This phenomenon translates to uncertainty in gauging the actual value of a bitcoin. Eroding stale UTXOs will boost the accuracy of these estimates, for the following reasons.

1. Users with accessible UTXOs are motivated to refresh their UTXOs to avoid erosion (spend them to another address they own), thereby signaling to the market that they are not lost funds.
2. Actual lost funds will be redistributed, thereby renewing the market's access to them.

Extra Miner Fees

As it stands now, lost funds act to deflate the value of the currency. By eroding stale UTXOs, deflation is replaced with rewarding miner, thus increasing the security of the protocol. As block reward decreases, this may become an important income source for miners. It also adheres closely to the bitcoin-as-precious-metal analog (mimicking tomb raiders, people searching for gold on beaches with metal detectors, etc.).

Issues

Erosion by Neglect

If this proposal is accepted, users who neglect moving their funds (e.g. in cold wallets) will have their funds begin to erode, even though they have the private key. This is mitigated in several ways.

1. Erosion starts after a long time, so only users who keep their funds stale for that long will be affected. Several years is probably long enough to avoid most neglect scenarios.
2. Erosion is slow and sparse, so even if users forget about this, as long as they occasionally check that their funds were not secretly stolen, they will notice that funds have eroded and will be able to take action before further erosion occurs.
3. Wallets can add "auto refresh" feature, which automatically broadcasts a transaction (to itself) a little before erosion begins (or in case of cold wallets, at least "erosion warnings").

Miner Censorship

A conceivable attack by miners would be to censor refreshing transactions in order to later reap the rewards from these funds being stale. However, stale funds are redistributed according to hashing power, while the fees of the refreshing transaction are not. Therefore, the smaller the hash-power of the miner, the less they stand to gain from such a strategy. Larger miners will know that if they censor transactions smaller miners will step in and process them before they can reap the rewards, rendering this strategy unprofitable.

Broadcasting nLockTime in Advance

Users may broadcast refreshing transactions years in advance (with nLockTime at intervals that would prevent the funds from becoming stale), thereby circumventing erosion even if they lose their private key in the future, which is undesirable assuming this proposal is accepted. There are many reasons for this not to work out for the user: there is no guarantee that miners/nodes will preserve such transactions in their pool, the protocol may soft-fork so that they become invalid by the time they unlock, included fees may be insufficient, etc.