Dust threshold changed without any mention in 0.11.1

[Hyena]

Thanks a lot bitcoin developers for screwing my application by changing the minimum output amount YET AGAIN. You should have at least mentioned it in the changelog or under the notable changes section:
https://bitcoin.org/en/release/v0.11.1

That's right, instead of 540 satoshis the bitcoin-core now won't allow outputs smaller than 2730 satoshis. This is starting to piss me off because every time you change it I must also change my program logic. If you have to do it then at least make it possible to request the current minimal dust threshold with an RPC.

Since this is such a bullshit change, I hereby spawn a parallel conversation: should developers not upgrade their bitcoin-core to 0.11.1 because of this? So that we could still make smaller output transactions? OR perhaps I should modify the source code of bitcoin-core to deliberately allow smaller amounts. It's up to miners anyway, so stop putting this crap into bitcoin-core if it can be so easily evaded.

[1715629252]

1715629252

[1715629252]

1715629252

[1715629252]

1715629252

[1715629252]

1715629252

[1715629252]

1715629252

[1715629252]

1715629252

[achow101]

The dust threshold is not hard coded. It is determined by the minrelaytxfee. The dust threshold changes with what is set as the minrelaytxfee, so you can set the minrelaytxfee in your own node to the original default of 0.00001 instead of the new default of 0.00005. That will change your dust threshold.

[DumbFruit]

So change the code running on your miner, I don't see why you need to be so melodramatic about it.

[shorena]

The code in question is here -> https://github.com/bitcoin/bitcoin/blob/ad57b310bac44a7e470cf66276421f2bbc61b1f0/src/primitives/transaction.h#L155

Code:

    CAmount GetDustThreshold(const CFeeRate &minRelayTxFee) const
    {
        // "Dust" is defined in terms of CTransaction::minRelayTxFee,
        // which has units satoshis-per-kilobyte.
        // If you'd pay more than 1/3 in fees
        // to spend something, then we consider it dust.
        // A typical spendable txout is 34 bytes big, and will
        // need a CTxIn of at least 148 bytes to spend:
        // so dust is a spendable txout less than 546 satoshis
        // with default minRelayTxFee.
        if (scriptPubKey.IsUnspendable())
            return 0;

        size_t nSize = GetSerializeSize(SER_DISK,0)+148u;
        return 3*minRelayTxFee.GetFee(nSize);
    }

As knightdk said you can set the value yourself in your bitcoin.conf file.

[Hyena]

The dust threshold is not hard coded. It is determined by the minrelaytxfee. The dust threshold changes with what is set as the minrelaytxfee, so you can set the minrelaytxfee in your own node to the original default of 0.00001 instead of the new default of 0.00005. That will change your dust threshold.

This seemed to provide a solution to my problem. Any ideas what the default minrelaytxfee was in 0.11.0 ? When I set it to 0.00000001 the minimal amount I was able to send was 3 satoshis. How to get 546 as it was in previous version?

[shorena]

The dust threshold is not hard coded. It is determined by the minrelaytxfee. The dust threshold changes with what is set as the minrelaytxfee, so you can set the minrelaytxfee in your own node to the original default of 0.00001 instead of the new default of 0.00005. That will change your dust threshold.

This seemed to provide a solution to my problem. Any ideas what the default minrelaytxfee was in 0.11.0 ? When I set it to 0.00000001 the minimal amount I was able to send was 3 satoshis. How to get 546 as it was in previous version?

Old default is 0.00001 its given per 1000 bytes. The algorithm assumes a TX size of 182 bytes and multiplies by 3.

Code:

182 * 3 * 1000(Satoshi)/1000(byte) = 546 satoshi (dust)

with the modified default minrelaytxfee 0.00005 its

Code:

182 * 3 * 5000(Satoshi)/1000(byte) = 2730 satoshi (dust)

[achow101]

The dust threshold is not hard coded. It is determined by the minrelaytxfee. The dust threshold changes with what is set as the minrelaytxfee, so you can set the minrelaytxfee in your own node to the original default of 0.00001 instead of the new default of 0.00005. That will change your dust threshold.

This seemed to provide a solution to my problem. Any ideas what the default minrelaytxfee was in 0.11.0 ? When I set it to 0.00000001 the minimal amount I was able to send was 3 satoshis. How to get 546 as it was in previous version?

It was 0.00001

[Hyena]

Old default is 0.00001 its given per 1000 bytes. The algorithm assumes a TX size of 182 bytes and multiplies by 3.

Code:

182 * 3 * 1000(Satoshi)/1000(byte) = 546 satoshi (dust)

with the modified default minrelaytxfee 0.00005 its

Code:

182 * 3 * 5000(Satoshi)/1000(byte) = 2730 satoshi (dust)

You're right. With that old default of 0.00001, the minimum output size is 0.00000546 satoshis. Now this leads to me a tough question -- how to determine the smallest possible value for that parameter that is still safe to use in a sense that neighbouring nodes will relay it. Is 0.00001 still safe to use? How long will it be safe to use? What's the best practice for developers when solving this problem?

[shorena]

Old default is 0.00001 its given per 1000 bytes. The algorithm assumes a TX size of 182 bytes and multiplies by 3.

Code:

182 * 3 * 1000(Satoshi)/1000(byte) = 546 satoshi (dust)

with the modified default minrelaytxfee 0.00005 its

Code:

182 * 3 * 5000(Satoshi)/1000(byte) = 2730 satoshi (dust)

You're right. With that old default of 0.00001, the minimum output size is 0.00000546 satoshis. Now this leads to me a tough question -- how to determine the smallest possible value for that parameter that is still safe to use in a sense that neighbouring nodes will relay it. Is 0.00001 still safe to use? How long will it be safe to use? What's the best practice for developers when solving this problem?

I would guess that for now 0.00005 is over the top. I had to increase it because the spam caused my node to crash, but its running fine with 0.00002 (twice the old default). Its also not very powerful (2GB single core VPS). I cant tell you for how long 0.00005 will work or even how many are running the default config.

0.11.1 is pretty common for the short time its out though, 12.8% according to -> https://bitnodes.21.co/dashboard/?days=365

[Hyena]

I would guess that for now 0.00005 is over the top. I had to increase it because the spam caused my node to crash, but its running fine with 0.00002 (twice the old default). Its also not very powerful (2GB single core VPS). I cant tell you for how long 0.00005 will work or even how many are running the default config.

0.11.1 is pretty common for the short time its out though, 12.8% according to -> https://bitnodes.21.co/dashboard/?days=365

I guess it's a tough problem then. I need a programmatic solution. So that the program could detect and overcome the issue of nodes not relaying its transactions. For now 0.00001 should work but if it suddenly stops working in the future then I will get in trouble. How would you go about it? If the TX has not been confirmed in 60 minutes then somehow withdraw it, increase the fee and make a whole new TX? Actually I wouldn't be able to make a new TX because it will probably require more funds than initially planned. Has anyone else thought of this?

[shorena]

I would guess that for now 0.00005 is over the top. I had to increase it because the spam caused my node to crash, but its running fine with 0.00002 (twice the old default). Its also not very powerful (2GB single core VPS). I cant tell you for how long 0.00005 will work or even how many are running the default config.

0.11.1 is pretty common for the short time its out though, 12.8% according to -> https://bitnodes.21.co/dashboard/?days=365

I guess it's a tough problem then. I need a programmatic solution. So that the program could detect and overcome the issue of nodes not relaying its transactions. For now 0.00001 should work but if it suddenly stops working in the future then I will get in trouble. How would you go about it? If the TX has not been confirmed in 60 minutes then somehow withdraw it, increase the fee and make a whole new TX? Actually I wouldn't be able to make a new TX because it will probably require more funds than initially planned. Has anyone else thought of this?

Is it about the fee or do you need as small as possible outputs? IMHO the fee is best handled by core directory with

estimatefee nblocks

Estimates the approximate fee per kilobyte
needed for a transaction to begin confirmation
within nblocks blocks.

Arguments:
1. nblocks (numeric)

Result:
n : (numeric) estimated fee-per-kilobyte

-1.0 is returned if not enough transactions and
blocks have been observed to make an estimate.

Example:
> bitcoin-cli estimatefee 6

and

estimatepriority nblocks

Estimates the approximate priority
a zero-fee transaction needs to begin confirmation
within nblocks blocks.

Arguments:
1. nblocks (numeric)

Result:
n : (numeric) estimated priority

-1.0 is returned if not enough transactions and
blocks have been observed to make an estimate.

Example:
> bitcoin-cli estimatepriority 6

If you need as small as possible outputs I dont have a real solution, besides get in touch with a miner and see that you can pitch the TX directly to them.

[Hyena]

If you need as small as possible outputs I dont have a real solution, besides get in touch with a miner and see that you can pitch the TX directly to them.

yeah, I need as small as possible. Ideally I would pay a little extra fee to the miner in order to have them confirm my tx that has less than usual outputs. both parties would win from this. the miner gets a bigger fee and I'd have the possibility to send a smaller amount of bitcoins per output.

[mezzomix]

Do you consolidate the dust at a later point in time or do you just blow up the UTXO database?!

[Hyena]

Do you consolidate the dust at a later point in time or do you just blow up the UTXO database?!

Those UTXOs are unspendable.

[Nicolas Dorier]

Hyena, please be more vocal next time before the fact.

I whined alone about it before the drama happened : https://github.com/bitcoin/bitcoin/pull/6793
Quoting myself :

I'm just a bit down to be hit collaterally by a good idea to prevent spam. Especially when raising IsDust does not prevent spam at all. It is like we get hit, without benefit for any party, neither for spammers, you, us, or our deployed customers, pure pain without pleasure.

I proposed pegging dust on the fees : https://github.com/bitcoin/bitcoin/issues/6824

I agree with you that this is a bitch move and core devs don't care at all about it, nor about breaking stuff. (see the discussion)

Basically they tell you that you are wrong to hard code the value without giving a good way to find the dust amount without a centralized server to tell the correct value. (which is why I proposed pegging dust on the fee)

Sadly I don't code in C++ to implement my proposal, and no dev care about dust, so we'll have to handle this mess by ourselves either by using a centralized server for getting the right dust OR hard coding and redeploying everytime they change like that.
This freaking change broke every single piece of code which create a transaction... not only meta protocol, but normal wallet as well. (https://github.com/voisine/breadwallet/issues/291)

This suck but we'll have to live with it it seems.

[dserrano5]

Do you consolidate the dust at a later point in time or do you just blow up the UTXO database?!

Those UTXOs are unspendable.

So, worse than blow up.

[Hyena]

So, worse than blow up.

That's one way to look at it. But it's still subjective. I've been in debate about it so many times. A really short counter argument would be that it's not "worse" until it increases the utility and thus the intrinsic value of bitcoin. It is worse when it is part of an attack on the bitcoin network.

Another really good point that was brought out in a previous discussion about the UTXO issue is that the Bitcoin network has to deal with it one way or another. Human moral cannot be relied on. If UTXOs are bitcoin's vulnerability then some day someone may want to exploit that vulnerability to bring the network to its knees. What is more, if I wanted to use that attack vector, I would generate the UTXO private keys deterministically so that in the end I could even get my attack money back.

Hyena, please be more vocal next time before the fact.

What do you mean by being more vocal next time before the fact? I just discovered this mess-up yesterday the hard way. My customers lost their money because of that without getting any service. Next time I won't upgrade my bitcoin wallet, period. At least that's what I feel like doing. Obviously I will upgrade if I have to, for some really good reasons.

[gmaxwell]

If you are not using the Bitcoin currency except incidentally but instead abusing the system to store data there are no promises that you're going to have a good time. It's not in the users of the system's general interest to accept an eternal data storage cost on your behalf.

As mentioned above, there is no explicit "dust threshold"-- it's determined by the minimum relay fee rate.  In particular, the number "540" you were expecting was certainly never announced;-- and the change to the relay fee was absolutely release noted; and important for keeping nodes from blowing up in the short term-- yes, a somewhat lower value would have also worked but the relay fees were out of wack (adjusted predicatively down when the prices was at almost three times the current and going up) and the minimum bump might have been met immediately by the attackers (who can update their behavior much faster than people can upgrade software).

Above you write that you are creating unspendable outputs-- this is _specifically_ one abuse of the system dust threshold was intended to discourage; so it sounds like it's working as designed now.

But by all means, feel free to not upgrade your software or change its behavior... it's not the action of your own software that will inhibit you-- all it does it tell you quickly and cleanly so your transactions don't get stuck, it's the action of everyone else that inhibits the abuse. And it is quite effective, or else I suspect we wouldn't be enduring your vicious invective.

If someone is looking for a safe dust approximation without any relayfee intelligence, the original level of 5460 base units is probably a better expectation.

[Hyena]

If you are not using the Bitcoin currency except incidentally but instead abusing the system to store data there are no promises that you're going to have a good time.

WTF are you talking about? What you might see as abusive is by no means an objective evaluation of the situation. Keep your petty feelings to yourself. As a core developer you should not allow yourself to give in to your emotions. It is your job to find a solution to the UTXOs because that number will increase EITHER WAY. With or without abuse.

and the change to the relay fee was absolutely release noted

FALSE. Stop lying in my face. When I searched the release notes there were no indication to the minrelaytxfee config parameter and the default value that might have changed as a result. It is pathetic to see you try to cover up this mess. Be an adult and admit that the release notes were lacking that info.

or else I suspect we wouldn't be enduring your vicious invective.

So now you're trying to put all the blame on me even though my activities have nothing to do with the fact that you missed an important part from the release notes. What is more, you fail to remain neutral and objective and again, give in to your petty childish emotions. Calling my activities vicious?! Be grateful to me for highlighting the UTXOs issue because when a malicious user starts to abuse this vulnerability you will not have a chance for a reasonable debate. I like bitcoin and I want it to evolve over time, I am willing to cooperate because I am at your side (in case you are on evolving Bitcoin's side, of course).

[achow101]

and the change to the relay fee was absolutely release noted

FALSE. Stop lying in my face. When I searched the release notes there were no indication to the minrelaytxfee config parameter and the default value that might have changed as a result. It is pathetic to see you try to cover up this mess. Be an adult and admit that the release notes were lacking that info.

When the release was announced in the bitcoin-dev mailing list, the email included the information about the change of the minrelaytxfee. However, this was never mentioned in the website for some reason.