RFC: Updating dust output definition, and default fees

[jgarzik]

URL: https://github.com/bitcoin/bitcoin/pull/2100

1) Create COIN_DUST constant, to represent the dust spam limit used.

2) Update COIN_DUST from 0.01 BTC to 0.001 BTC

Rationale: With the increase in bitcoin value (US$13.67 as of this
writing), it seems reasonable to reduce the value level of which we
consider "dust spam."

3) Update TX miner and relay fee defaults to 0.001 / 0.0005 BTC respectively

Rationale: Reflects growth of dust spam in unspent transaction output dataset.

Review of impact:
a) Definition of COIN_DUST reduced from 0.01 to 0.001.
b) Miners who mine with this code will require a fee >= 0.001 to
include TX's with outputs <= COIN_DUST
c) Normal clients will require a fee >= 0.0005 to relay TX's with
outputs <= COIN_DUST

[DeathAndTaxes]

Not sure the dust constant needs to be changed BUT I do like replacing hard coded literal values with constants.

[BoardGameCoin]

b) Miners who mine with this code will require a fee >= 0.001 to
include TX's with outputs <= COIN_DUST
c) Normal clients will require a fee >= 0.0005 to relay TX's with
outputs <= COIN_DUST

Why not make these be

b) Miners who mine with this code will require a fee >= 0.001COIN_DUST to
include TX's with outputs <= COIN_DUST
c) Normal clients will require a fee >= 0.0005COIN_DUST/2 to relay TX's with
outputs <= COIN_DUST

?

[jl2012]

URL: https://github.com/bitcoin/bitcoin/pull/2100

1) Create COIN_DUST constant, to represent the dust spam limit used.

2) Update COIN_DUST from 0.01 BTC to 0.001 BTC

Rationale: With the increase in bitcoin value (US$13.67 as of this
writing), it seems reasonable to reduce the value level of which we
consider "dust spam."

3) Update TX miner and relay fee defaults to 0.001 / 0.0005 BTC respectively

Rationale: Reflects growth of dust spam in unspent transaction output dataset.

Review of impact:
a) Definition of COIN_DUST reduced from 0.01 to 0.001.
b) Miners who mine with this code will require a fee >= 0.001 to
include TX's with outputs <= COIN_DUST
c) Normal clients will require a fee >= 0.0005 to relay TX's with
outputs <= COIN_DUST

Another post (https://bitcointalk.org/index.php?topic=128900.0) mentioned that currently 11% unspent output is 0.00000001BTC, 32% is less than 0.0001BTC and 60% is less than 0.001BTC. At the current price of US$13.5, 0.0001BTC worths only $0.00135. These are basically zero-value but take up 1/3 of resources of the network. To discourage these kinds of transaction, an even higher fee (e.g. 0.005BTC) should be charged with outputs < 0.0001BTC

[gmaxwell]

Another post (https://bitcointalk.org/index.php?topic=128900.0) mentioned that currently 11% unspent output is 0.00000001BTC, 32% is less than 0.0001BTC and 60% is less than 0.001BTC. At the current price of US$13.5, 0.0001BTC worths only $0.00135. These are basically zero-value but take up 1/3 of resources of the network. To discourage these kinds of transaction, an even higher fee (e.g. 0.005BTC) should be charged with outputs < 0.0001BTC

Perhaps a dust threshold could be made dynamic based on the chain.

For example, compute the fee/KB for the last 2016 blocks and take its median value = MedianFee.  Then assuming that every transaction must pay MedianFee/kb and each additional input to a transaction adds X bytes you arrive at a figure of MedianFee*X = the smallest output value which isn't worthless.

Unfortunately thin clients can't measure this value on their own, but its data they could reasonably just trust if their server provides it (lying results in a DOS attack, but a thinclients server can dos attack in many ways).

The proper thing to do with these transactions is not to relay or mine them at all— since it appears that there is be no economic incentive to spend them. But this is a bit blunt— as there are no doubt interesting ways to use small outputs which are not harmful, never redeemed bloat sources.  I'm not sure how to best penalize these without completely denying them.

[deepceleron]

URL: https://github.com/bitcoin/bitcoin/pull/2100

1) Create COIN_DUST constant, to represent the dust spam limit used.

2) Update COIN_DUST from 0.01 BTC to 0.001 BTC

Rationale: With the increase in bitcoin value (US$13.67 as of this
writing), it seems reasonable to reduce the value level of which we
consider "dust spam."

When the minimum fee (if a fee is even required) was reduced 20-fold from .01 to .0005 (and the exchange value was doubling every month) in May-June 2011, the value of Bitcoin was the same as today. This greatly impacted the economics of Bitcoin as set up by Satoshi - upon examination of any facet of the currency, everything about Bitcoin seems extremely thought out as though it was delivered through divine intervention. Using a similar "value" argument to also allow more small transactions for free doesn't quite hold up. If you really want to send 0.005 today, you can for a 10% fee (Paypal would charge about a 700% fee for someone to receive $0.05 from you). A fee of less than $0.01 to instantly send any amount of money anywhere in the world is pretty reasonable.

[grau]

Let us recognize that it is not dust as defined by an arbitrary threshold, but coin fragmentation in general that drives cost of the network.

A simple transaction has number of outputs to inputs ratio of 2, if addresses are infrequently re-used (as required to maintain high level of privacy) this leads to an exponential hence problematic expansion of the open transactions set. There are legitimate use cases for privacy but they should be weighted against their cost to the network just like dust.

I suggest to deal with dust and fragmentation in a combined approach to also incentivize dust collection and aggregation.

Let us assign a minimum fee (FEE) for the ratio of number of outputs to inputs, a transaction with ratio n should offer n*FEE fee to be relayed or mined.

Transactions collecting dust would become cheap compared to those fragmenting.

Zero fee transactions should not be relayed or mined (other than of their ratio is below 1/FEE so they become free for collection of dust)

[gmaxwell]

Let us assign a minimum fee (FEE) for the ratio of number of outputs to inputs, a transaction with ratio n should offer n*FEE fee to be relayed or mined.
Transactions collecting dust would become cheap compared to those fragmenting.
Zero fee transactions should not be relayed or mined (other than of their ratio is below 1/FEE so they become free for collection of dust)

You can't just do that. Block size is finite. Ultimately miners will prefer transactions with more fee per kbyte of transaction data.  Software could implement default rules which are against the miners best economic interests, but then many miners would just change it— and the inconsistency would be even worse.

For free transactions, or as a tie breakers for transactions with very similar fee/kb transactions which reduce the txout set are in the miner's (and overall communities best interest), but I don't think those cases are common enough to be worth solving alone. (E.g. addressing it only for free transactions doesn't even solve SD's 1e-8 BTC messaging).   (though I do also think we should also strongly bias the free transaction logic to favor transactions which reduce the txout set size)

This is why I was suggesting a heuristic to determine the smallest output which is economically nonredeemable (because its value is less than the marginal fee that would be required to get the transaction mined in reasonable time). The idea here is to avoid creating outputs which will not ever be redeemed by anyone because they would lose funds by doing so (perhaps someday they'd be worth redeeming— except they'll have likely lost the keys long before then).  This isn't quite the same as penalizing txout set bloating, but it should prevent there from being a disincentive to _de_bloat it.

I'm a little irritated that I wrote you a nice explanation about why privacy preserving behavior does not need to increase fragmentation, and relative to current behavior privacy improvements could reduce fragmentation... and you've ignored it and gone on saying that privacy is a major risk factor here, but oh well.

[🏰 TradeFortress 🏰]

The default fee handling needs to prioritize transactions with higher fees. Most mining pools do this already, but the default client should too. If not all acceptable transactions could be included into a block, include the ones with the highest TX fee first.

[gmaxwell]

The default fee handling needs to prioritize transactions with higher fees. Most mining pools do this already, but the default client should too. If not all acceptable transactions could be included into a block, include the ones with the highest TX fee first.

This has been done for a long time. How do you think the pools are doing this?    But the criteria is not _highest fees_, it's _highest fees per byte_— because thats the criteria that maximized income given the constraints.

[gmaxwell]

As more discussion fodder— here is in image that shows the role that very tiny txouts are having in bloating the txout set:

[grau]

Let us assign a minimum fee (FEE) for the ratio of number of outputs to inputs, a transaction with ratio n should offer n*FEE fee to be relayed or mined.
Transactions collecting dust would become cheap compared to those fragmenting.
Zero fee transactions should not be relayed or mined (other than of their ratio is below 1/FEE so they become free for collection of dust)

You can't just do that. Block size is finite.

You make a very valid point that miner seek to maximize fee/size and that nodes should make sure tx favorable on that measure get to them.

Since tx size is also driven primarily by the number of inputs and outputs we have identified two goals (containing UTXO and high fee/size) driven by same parameters. Do we find arguments to determine the relative weight of the two goals, such as (w being a fraction in [0,1])?

fee = (w(nr_of_outputs/nr_of_inputs) + (1-w)(nr_of_outputs + number_of_inputs)) * FEE.

I think the principal privacy leak is if two or more addresses are used as input for the same transaction while they have not previously received funds from same source address. If that is correct then privacy enhancing algorithms will in effect avoid aggregation hence bloat the UTXO. I apologize if I missed a contrary argument. Please point me to it.

[gmaxwell]

I apologize if I missed a contrary argument. Please point me to it.

I thought it was in this thread for some reason, here you go.

[Roy Badami]

The default fee handling needs to prioritize transactions with higher fees. Most mining pools do this already, but the default client should too. If not all acceptable transactions could be included into a block, include the ones with the highest TX fee first.

This has been done for a long time.

Surely only since 0.7?  Or does that count as a long time in bitcoin time? :-)

[Mike Hearn]

(though I do also think we should also strongly bias the free transaction logic to favor transactions which reduce the txout set size)

If we do that it makes sense for wallets to automatically defragment users wallets using free transactions that can wait around until there's spare space in the block, eg, at night. Such a policy is quite easy to implement for wallets on phones and tablets.

[marcus_of_augustus]

Good discussion, some good ideas and solution approachs being raised here to the unresolved hard-coded "fees" issue.

[ShadowOfHarbringer]

b) Miners who mine with this code will require a fee >= 0.001 to
include TX's with outputs <= COIN_DUST
c) Normal clients will require a fee >= 0.0005 to relay TX's with
outputs <= COIN_DUST

Why not make these be

b) Miners who mine with this code will require a fee >= 0.001COIN_DUST to
include TX's with outputs <= COIN_DUST
c) Normal clients will require a fee >= 0.0005COIN_DUST/2 to relay TX's with
outputs <= COIN_DUST

?

I have an even better proposition

const COIN_DUST_FEE_MULTIPLIER = 0.5;

b) Miners who mine with this code will require a fee >= 0.001COIN_DUST to
include TX's with outputs <= COIN_DUST
c) Normal clients will require a fee >= 0.0005COIN_DUST * COIN_DUST_FEE_MULTIPLIER to relay TX's with
outputs <= COIN_DUST