Change addresses are broken #14603

We are an ATM company operating the wallet to supply our machines. In the last couple of months we have found that our coins keep getting stuck in the change address for quite some time, resulting in many failed transactions and a huge workload on our helpdesk.

When this happens the balance disappears from the wallet and it appears empty. If you restart the node, the balance reappears and you can send 1 transaction and then the same thing happens again.

We have been using core for several years now with no prior issues. We have tried various versions (16, 16.3, 17) on several different servers but they all do the same thing now. It appears to be linked in some way to an uptick in unconfirmed transactions - https://www.blockchain.com/btc/unconfirmed-transactions

Today this rose from 4k to 25k in a few hours and the majority of the txs appear to be for a fee and not much else, and once again our wallet has stopped working.

Has something changed that would result in this issue or could this be caused by the 'ddos attack' on the bitcoin network?

We're running ubuntu 14 but we've also tried 17. Running on an SSD and an appropriate CPU. The general sever runs many wallets and BTC is the only issue. We have tried on a fresh server with nothing but the wallet on but this makes no difference.

Potential duplicate of #9752?

While it seems to have the same resulting symptoms it doesn't always appear to require a chain of 25 unconfirmed transactions to start happening. Today we had hardly had any when it stopped working. Additionally there is no error, it just says low balance.

That being said I had not heard of this limit. Is there any mechanism to allow for more than 24 tx's between blocks as this seems like a huge limitation for business users?

The limit is on chains of unconfirmed transactions, not unconfirmed transactions themselves. You shouldn't be chaining 24 unconfirmed in general usage I would think unless you're churning the entire wallet every transaction.

Ok thanks for that. Say for instance I have 2 BTC in my wallet and 50 customers make a purchase in a space of 10 minutes, how is it possible to stop that being a chain? Its going to change the full balance for every tx and they'll all be unconfirmed and dependant on each other. Am I missing something?

If you're processing that many payments you should probably batch them up using sendmany or raw tx RPCs, to construct a single transaction that performs all payments simultaneously. This will reduce your fees as well as reduce the length of unconfirmed chains.

Alternatively, you can occasionally break up your coins yourself by sending part of your coins to yourself. That will permit a chain of unconfirmed transactions per coin you have.

Ah ok thank you very much. That sounds like the ideal solution, unfortunately we're using a variety of different manufactures of ATM/server and none of them have this functionality built in. They all handle each tx individually. Definitely something to pester them all about though!

So if there is not a flag to enable more I guess our only immediate option is to use multiple wallets to ensure we never go over the limit?

Just a guess, but it sounds like what you're doing is sending a wallet a single, large transaction. Perhaps each ATM has its own 'wallet' which you're sending to.

At some stage in order to do that, you must have combined a bunch of smaller inputs.

The correct thing to do is to not perform the recombination in the first place (which will also reduce your fees).

edit: it'll also improve your users' privacy

Many thanks for the help. When someone makes a transaction on pretty much all brands of ATM (that we've come across) they just use an RPC call to sendtoaddress after validation. The tx's are tiny/standard single input/two output (customer and change) transactions. As previously stated we've been using our central wallet for sometime in the same configuration without issue. The problem started when everyone was told to update to 16.3 urgently...

https://www.ccn.com/new-core-patch-fixes-bitcoin-network-vulnerability-to-ddos-attacks/

By the sounds of it we definitely need to push for manufactures to start implementing sendmany instead of sendtoaddress but in the short term this isn't workable. Ideally we don't want multiple wallets as this will create a significant burden.

@hosekhoshtaghaza sendtoaddress doesn't scale and you end up paying more fees than necessary. If you stick to sendtoaddress, in the short term, then you must help with "coin management", either by splitting big coins to accommodate several concurrent sendtoaddress, or by joining smaller coins in order to "rescue some value". In other words, you have to find a way to keep your wallet healthy considering the requested payments.

Anyway, batch processing should the priority.

@promag Thats awesome thanks for the clear guidance. We will give all of that a go and push for batch processing. I am going to close this issue for now as if this is the source of our problem, this is definitely a duplicate of #9752. If still no joy I will get better info. Thanks again everyone!