Bitcoin network congestion
It is well known that due to the temporary anti-DoS limit introduced by Satoshi Nakamoto in 2010, the current Bitcoin throughput is constrained to about 3 transactions per second.With every difficulty increase it temporarily drops and then starts growing with miners' hashing power until the next difficulty adjustment.
That is why on the 21st of January after the expected 16.64% difficulty increase many Bitcoin users faced higher bitcoin fees and longer transaction confirmation times. Dozens of thousands of unconfirmed transactions still reside in the mempool.
Bitcoin scalability controversy
Bitcoin community has been discussing the scalability problem for years and despite the fact that it came up with a few potential solutions, it has been failing to find the one that would satisfy everybody.
According to Nodecounter, about 17% of mining power is in favour of increasing the block size limit via a hard fork proposed by Bitcoin Unlimited team, whereas 24% support Segwit proposed by Bitcoin Core developers. For some reason the compromise that would include the benefits of both solutions has not yet been achieved.
This leaves us in the reality where a constrained Bitcoin throughput diminishes our ability to handle micro-transactions and forces us to keep users' money longer than we would prefer to.
Low value transactions
The problem with micro-transactions is that they take the same amount of block space as high value transactions, but it doesn't make economic sense to add high fees to them.Hence they have a relatively low fee and in the current state of Bitcoin there is no guarantee that the low fee transaction will ever be confirmed.
E. g. the recommended fee currently is 120 satoshi per byte and the average transaction size is 226 bytes, thus if you want to quickly move 10000 satoshi, you have to pay a fee of 27120 satoshi.
In order to save the block space we use hourly sendmany transactions to pay our users. It allows us to send money to multiple recipients in a single transaction. E. g. if there are 64 recipients, then the transaction is only ~2309 bytes, or about 4329 satoshi per recipient (that is still prodigal for 10000 satoshi withdrawals).
That's why use use a small fee of 20 satoshi per byte (or 721 satoshi per recipient). It worked just fine until recently.
"Insufficient funds" incident
Yesterday we noticed that our bitcoin node couldn't create new transactions and returned the "Insufficient funds" errors despite the fact that the listaccounts command returned sufficient balance on our account (unlike getbalance and getinfo calls that returned a negligible balance).We investigated the cause of this inconsistent behaviour and figured out that all of our hourly outgoing transactions got stuck after the latest difficulty increase thus forming a long chain of unconfirmed transactions. Our bitcoin node refused to continue this chain and decided to wait for confirmation of the change.
Thanks to ViaBTC pool for its transaction accelerator that enabled us to push through the stuck transactions and thus temporarily solve the problem.
Really, thank you!
Withdrawal thresholds increase
Recently we increased the default withdrawal threshold to 0.0001 btc , but many users still had lower values in their settings.Since they might be unaware of how expensive it could be for them to spend the received micro-amounts, we decided to increase their withdrawal thresholds to 0.00100001 btc (while allowing them to set it back to 0.0001 btc if they want to).
We still need to develop a long-term solution and may be forced to increase the minimal withdrawal threshold, the interval between transactions, or to add a withdrawal fee in the future.
