why DB charges a withdrawal fee and does not include any of it for a transaction fee?
13 blocks already have been mined any my transaction is still unconfirmed.
![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FfUyLWXQ.png&t=665&c=KcYPsDjR9OWyDw)
I made a support ticket on the site:
I've seen several customers complaining of having to wait many hours for their withdrawals to confirm.
I've looked into the problem and it seems to be caused by a recent change in the rules re. required fees.
I suspect lots of miners (or the big pools) are running old versions of bitcoind were stricter on fees, and so the withdrawal transactions you're making with no fee look like they don't have enough fee to the miners.
The code in question is in core.cpp:
double CTransaction::ComputePriority(double dPriorityInputs, unsigned int nTxSize) const
[...]
BOOST_FOREACH(const CTxIn& txin, vin)
{
unsigned int offset = 41U + std::min(110U, (unsigned int)txin.scriptSig.size());
if (nTxSize > offset)
nTxSize -= offset;
}
That's ignoring the bytes used to spend old outputs, in an attempt to clean up the blockchain by making it free to spend old outputs.
I think that removing the 6 lines of the whole FOREACH block would solve the problem, causing a little extra fees to be included in some cases, costing very little, and not pissing off your customers...
Hopefully that will help them make withdrawals work more quickly in future!
Edit: here's the transaction as it shows on blockchain.info:
![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2Fb3AY1FP.png&t=665&c=WTMk_FXJwRUVQQ)
Note that the transaction was seen at 13:06 and now it's 18:21, over 5 hours later.
The two inputs are:
1.60263675 BTC in block 317543, 24 confirms at time of spending
0.9999 BTC in block 317513, 54 confirms at time of spending
To determine whether a transaction can be free or not, first we multiply each inputs's value (in satoshis) by its depth (in blocks) and sum them:
>>> (24 * 160263675 + 54 * 99990000)
9,245,788,200
Then we divide by the size of the transaction, and if the result is bigger than 57,600,000 then the transaction can be free.
In old versions of the code, the whole size of the transaction was used - that's 372 bytes:
>>> 9245788200 / 372
24,854,269
That isn't bigger than 57.6 million, and so the transaction isn't free according to the old rules.
In new versions of the code, the transaction size is reduced to make it cost-effective to clean up old unspent outputs. In this case both inputs get a 155 byte allowance, reducing the effective transaction size by 310 to just 62 bytes. We then divide by 62:
>>> 9245788200 / 62
149,125,616
That *is* bigger than 57.6 million, and so the transaction *is* free.
(It's a little more complex than that, but I think that's more than enough detail already).
It's curious, given this, that blockchain.info says that the transaction fee is less than reco
mmended, but I guess they're still using the old rules too.