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.

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


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

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


with the modified default minrelaytxfee 0.00005 its

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 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?

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.

Those UTXOs are unspendable.

So, worse than blow up.

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.

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.