Topic: Dust threshold changed without any mention in 0.11.1 - page 3. (Read 6002 times)

Yes this suck, I understand I am in the same boat, try to follow bitcoin PR and Issues. I am just saying that I would have appreciated more concerns about impacted developers who have to support real customers before the fact.

Ok fine. I'm not into pointing fingers anyway. Stuff like that happens, I'm a developer myself, I know. The monetary loss due to this was perhaps 0.5$ in my situation. And the idea of increasing the minimum acceptable output amount is also good, even though it was badly broadcast this time. I tried restarting my node with different minrelaytxfee values and the difference was humongous. With 0.00001 I had 20k unconfirmed TXs. I increased that number to 0.00003 and the number of unconfirmed TXs dropped below 10. This clearly eliminates the "stress test" attack vector on the Bitcoin's network. I hated it.

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.

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.


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.


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).

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.

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.


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.

So, worse than blow up.

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

Those UTXOs are unspendable.

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

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.

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


and




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.

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?

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

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?

It was 0.00001

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

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?

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.

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