Defining Dust as a function of the Transaction Fee (instead of MinRelayTxFee)

NicolasDorier commented at 3:52 am on October 14, 2015: contributor

#6793 raised MinRelayTxFee to limit spamming attack which lead to crashing node. This is an effective solution, but this also changed the amount of Dust.

 0CAmount GetDustThreshold(const CFeeRate &minRelayTxFee) const
 1    {
 2        // "Dust" is defined in terms of CTransaction::minRelayTxFee,
 3        // which has units satoshis-per-kilobyte.
 4        // If you'd pay more than 1/3 in fees
 5        // to spend something, then we consider it dust.
 6        // A typical spendable txout is 34 bytes big, and will
 7        // need a CTxIn of at least 148 bytes to spend:
 8        // so dust is a spendable txout less than 546 satoshis
 9        // with default minRelayTxFee.
10        if (scriptPubKey.IsUnspendable())
11            return 0;
12
13        size_t nSize = GetSerializeSize(SER_DISK,0)+148u;
14        return 3*minRelayTxFee.GetFee(nSize);
15}

Such sudden change of a widely used default hurted other meta-layer protocols such as Counterparty, Omni, ChanceCoin, NewbieCoin, OA, EPOBC, Colu.

As well as wallets : if you want to send 1000 satoshi to Alice, but have a coin of 2100 satoshi. A wallet with MinTxRelayFee of 1000 will send the 1100 satoshi of change. But if you change the MinTxRelayFee abruptly to 5000 like that and I don’t update the wallet software, now, the transaction will be ignored because the change is considered Dust.

The dust rule prevents UTXO bloating by preventing the creation of TxOut whose value is lower than the cost of the ScriptSig to spend it.

There is some discussion about making a floating minRelayTxFee on #6722 which will even more complicate the task for wallets and services who will need to get this new variable from somewhere.

I am opening this issue to propose another solution : Defining Dust as a function of the Transaction Fee.

This has the advantage to not require any data which a wallet or service does not already have, and offer the best response we can get of “does this output cost more than spending it”. This can also be easily implemented and reviewed.

ptschip commented at 4:23 am on October 14, 2015: contributor

As well as wallets : if you want to send 1000 satoshi to Alice, but have a coin of 2100 satoshi. A wallet with MinTxRelayFee of 1000 will send the 1100 satoshi of change. But if you change the MinTxRelayFee abruptly to 5000 like that and I don’t update the wallet software, now, the transaction will be ignored because the change is considered Dust.

If a transaction is below the mintxrelayfee it will not necesarily be ignored. it still may be accepted into the memory pool based on the value of -limitfreerelay.

The dust rule prevents UTXO bloating by preventing the creation of TxOut whose value is lower than the cost of the ScriptSig to spend it.

There is some discussion about making a floating minRelayTxFee on #6722 #6722 which will even more complicate the task for wallets and services who will need to get this new variable from somewhere.

In #6803 #6803 minrelaytxfee is increased linearly once the mempool is full. Wallets would only need to know the size of the mempool to calculate what the current value of minrelaytxfee would be.

I am opening this issue to propose another solution : Defining Dust as a function of the Transaction Fee.

This has the advantage to not require any data which a wallet or service does not already have, and offer the best response we can get of “does this output cost more than spending it”. This can also be easily implemented and reviewed.

— Reply to this email directly or view it on GitHub #6824.

NicolasDorier commented at 4:37 am on October 14, 2015: contributor

Wallets would only need to know the size of the mempool to calculate what the current value of minrelaytxfee would be.

This is an information most wallet do not have, contrary to recommended fee, also, it does not match what the dust is : a way to prevent uneconomical output.

gmaxwell commented at 4:38 am on October 14, 2015: contributor

The recent spam attack showed pretty persuasively that the dust values had been moved too low as well (perhaps even more so than the relay fee– considering the incredible amount of utxo set bloat).

Making them depend on the actual fees would have the perverse incentive of encouraging lower fees to squeeze more dust through. Please go battle out with coblee who was loudly calling Bitcoin flawed for not adopting litecoins progressively higher fees with more dust. :)

Keep in mind that the relay fee and dust limits are minimums—- if you’re depending on sending things at the minimum you may have a bad time; especially if you’re doing so without the benefit of realtime network intelligence (e.g. a mempool.). Since the minrelayfee is a minimum (at least for non-treated-as-free transactions) a scheme based on the actual fees would also not result in anything but a higher dust threshold.

I suppose you could already go ahead and use the actual fee for your dust threshold behavior– you’ll end up with an overly conservative value, but so long as you’re meeting minrelayfee you have enough.

NicolasDorier commented at 4:46 am on October 14, 2015: contributor

I suppose you could already go ahead and use the actual fee for your dust threshold behavior– you’ll end up with an overly conservative value, but so long as you’re meeting minrelayfee you have enough.

I was thinking about that, my main problem is that I don’t know when this minRelayFee change will kick again. I can’t use exactly the fee rate of the actual transaction, this will be too high and overkill, but if I take anything less based on some formula, then I’m not garanteed that one day, the minRelayTxFee will move again and break what I did.

Making them depend on the actual fees would have the perverse incentive of encouraging lower fees to squeeze more dust through.

yes, but if you lower fee, your transaction might not end up in a block or mempool anyway, because it will be kicked out by #6722 . My observation does not exclude having PR 6722, just that MinRelayTxFee and Dust be decoupled so wallet don’t need any other external magic value.

rubensayshi commented at 9:46 am on October 14, 2015: contributor

Couldn’t the dust threshold be based on the fee of the transaction that it is part of? Not based on any estimated optimal fee or anthing like that. If a transaction is relayed and mined with a certain fee that means that that fee/kb is a fee that has a chance of getting mined, thus making the dust based on that should be a fair choice.

Also something to consider is that wallets when doing coin selection are supposed to avoid a dust change output and instead add it to the fee. So your point about not relying on minimums for the various meta protocols @gmaxwell is a valid one, they could easily use a higher value because the coins are never lost.
but for determinating if it’s worth adding a change output or not is a very different case, there needs to be a clear threshold where wallets decide to give the coins to the miner instead.

or do you have a different opinion / idea on how a wallet should decide when it’s no longer worth adding a change output?

TheBlueMatt commented at 9:58 am on October 14, 2015: member

Note that #6722 reverts the minRelayTxFee to 1000, resetting the dust limit by side-effect (if we want to change that, it should be separately discussed, however).

rubensayshi commented at 10:26 am on October 14, 2015: contributor

@TheBlueMatt so the minRelayTxFee remains a constant (and thus the dust too) but what is accepted into the mempool is not?

TheBlueMatt commented at 10:32 am on October 14, 2015: member

Yes.

On October 14, 2015 3:26:57 AM PDT, Ruben de Vries notifications@github.com wrote:

@TheBlueMatt so the minRelayTxFee remains a constant but what is accepted into the mempool is not?
I’ll move my question to that issue, so we don’t have to hijack this one ;)

Reply to this email directly or view it on GitHub: #6824 (comment)

NicolasDorier commented at 10:33 am on October 14, 2015: contributor

Couldn’t the dust threshold be based on the fee of the transaction that it is part of? Not based on any estimated optimal fee or anthing like that.

This is what I propose yes. If the transaction reach the mempool and is not kicked by #6722 then we can consider the fee to be a fair value and by extension, the dust calculated upon the fee of the transaction to be fair too. @TheBlueMatt the question is less about what is the appropriate minRelayTxFee and more about what wallet providers should do to prevent being burned by such unpredictable changes. If wallet consider the optimal fee rate for the basis of dust, they are overly conservative, but if they consider anything less, then a future change of minRelayTxFee might break things again. Also, as said, using fee is a better way to know if the output is economical than any magic value.

rubensayshi commented at 10:33 am on October 14, 2015: contributor

@TheBlueMatt I have doubts about a mempool based minRelayTxFee but I’ll save that for the other topic…

When the DUST would be constant while the minRelayTxFee floats, that would at least prevent a transaction being nostandard based on fluctuations (and mempools), but it would however be somewhat of a ’lie’ to the user, because some outputs that are above DUST could still be economically unspendable .. ?

sipa commented at 10:37 am on October 14, 2015: member

I think that’s a problem. If the effective relay fee becomes free-floating, the dust protection will become ineffective if it isn’t adjusted accordingly.

No need to break existing applications without good reason of course, but at the time the dust limit was introduced, it was even intended already that the feerate it is based on would end up being dependent on network conditions…

sipa commented at 10:39 am on October 14, 2015: member

Defining dust in function of a transaction’s actual fee is an interesting idea, I must say. It is more predictable for wallet software, but remains effective under different relay policies.

rubensayshi commented at 10:59 am on October 14, 2015: contributor

I think the dust should be detached from configurable policies, a transaction below minRelayTxFee at least has a chance of getting into the free space

also dust is about it being economically unspendable right? so that’s more about the fee than the relayfee, that’s also the reason why most people always confused the dust being 5640 (based off default fee) instead of 546 (based of default relayfee)

dexX7 commented at 11:08 am on October 14, 2015: contributor

My initial understanding was that a floating relay fee implies a floating dust threshold.

To satisfy that outputs are not uneconomic, this seems reasonable, however, this comes at the cost of needing more information to determine the threshold. Whether this is an issue or not for meta protocols, this seems to affect non-full-nodes in general.

sipa commented at 11:12 am on October 14, 2015: member

To satisfy that outputs are not uneconomic, this seems reasonable, however, this comes at the cost of needing more information to determine the threshold. Whether this is an issue or not for meta protocols, this seems to affect non-full-nodes in general.

It’s a hard problem, but not more an issue than determining a good fee, or determining an exchange rate if your wallet supports different currencies.

NicolasDorier commented at 3:35 am on October 15, 2015: contributor

By checking the code, currently fee of a transaction depends on the dust present. (Dust are added to the fee) However, if we need fee for determining dust then we get circular dependency, maybe not so easy to implement as I thought. :(

0// Never create dust outputs; if we would, just
1// add the dust to the fee.
2if (newTxOut.IsDust(::minRelayTxFee))
3{
4    nFeeRet += nChange;
5    reservekey.ReturnKey();
6}

rubensayshi commented at 10:06 am on October 19, 2015: contributor

that code is already in a while(true) to deal with scenarios such as when there’s enough to pay fee pre-change but not enough to pay fee post-change etc afaik, it’s doable to build ontop of that I suppose. @gmaxwell @sipa I think mostly for the case of if (newTxOut.IsDust(::minRelayTxFee)) it’s important that people are able to have a consistent dust value,
because even someone who pays a healthy fee could have his TX badly (or not at all) propagated because he has a lower minRelayTxFee configured then most of the network.
however attaching it to the tx fee doesn’t give the desired effect either, because if someone would use a high fee (for getting into a block quicker) he’d be pushing up his own dust limit.
maybe it should be a constant on it’s own? because dynamic based on either minRelayTxFee or the tx fee is both a problem?

the coloredcoins protocols already have stuff in place to just increase the amount they use instead of using the bare minimum such as padded values or putting the actual values in opreturns etc. so people who intentionally create dust outputs can easily fix their problem.

NicolasDorier commented at 2:43 pm on October 19, 2015: contributor

so people who intentionally create dust outputs can easily fix their problem.

At the cost of updating all of our clients yes. As I said, this problem is not dramatic, but is worse pain in the ass than an hardfork which requires only to update a node. Every single piece of code creating a transaction need to know the amount of dust. So either we provide minTxRelayFee from external trusted source, either we find a scheme based on fees. But this need to be decided in core, whatever scheme based on fee I would have used for anticipating this problem before the bump, making it 5x more would have broke it anyway.

because if someone would use a high fee (for getting into a block quicker) he’d be pushing up his own dust limit.

Not sure this is so much a problem, dust is not so costly, making it 1 cts instead of 2 cts because of 2x more fee is not so much big of a deal.

ABISprotocol commented at 9:29 pm on October 20, 2015: none

Dust is not a problem, it is a gift. See http://abis.io for ideas.

ABISprotocol commented at 5:56 am on November 6, 2015: none

In my prior comment on this, I indicated that http://abis.io should be looked at for ideas regarding how you can do things with dust (in particular, use it as a gift rather than as a problem). Here are some additional ideas for what you can do with dust:

https://github.com/petertodd/dust-b-gone ~ by @petertodd
#4079 (comment) ~ by @gmaxwell

laanwj added the label Brainstorming on Feb 16, 2016

MarcoFalke commented at 6:13 pm on May 8, 2020: member

Fixed by #9380, I guess

MarcoFalke closed this on May 8, 2020

DrahtBot locked this on Feb 15, 2022

Defining Dust as a function of the Transaction Fee (instead of MinRelayTxFee) #6824