Bitcoin Forum

It happens that I do send out many micro payments in automatic mode with bitcoind. In general I do not mind to pay some fees in order to support the network. But when it comes to the multiple small payments it damages my income.

I'm aware of that tiny or "young" transactions are need to backed up by fee. But I still can't understand the pattern of fee calculation.

Altogether around 50% transactions goes with 0.01 BTC fee and others are free. There is no correlations with the amount. Larger ones may be with fee and smaller may be free. The wallet consists of plenty BTC with the majority of funds being very mature. paytxfee parameter seems does not give any effect.

I'm trying to understand algorithm of fee calculation in order to minimize my losses.

The minimum transaction fee is .0005 per KB of transaction message size, if your Bitcoin is suggesting more, it should be updated to something newer than <0.3.23. In addition, you can use sendmany to send payments to multiple recipients at once, which will be cheaper:

The total amount of the transaction doesn't matter.

It is the amount and age of the inputs.

Thus 1 BTC paid by an 1 BTC input 144 blocks old = no fee, while 1 BTC paid by 1000 0.001 inputs which are 6 blocks old = relatively large fee.

Then if I have young and plenty mature money in the same wallet what bitcoind chooses to pay out?

If it is just random pick I'm thinking to have two wallets running. One to accept payment and leave there, another to send payments. Once in a while swap their functions.

Look into "sendmany".

It would be good if payments are to be sent in a time. But that is not an option to delay them in order collect a bunch.

it's not random. It's designed to maximize coin age and reduce inputs.

I've installed latest version and fee reduced to 0.0005 BTC. Which is absolutely fine for me and makes useless any additional tricks.

Bitcoin actually chooses coins with the goal of reducing change. (This is not the best way to do it.)

Where did this meme originate?  It's not true.  The official client will use coins with more than 6 confirmations if it can, but other than that makes no effort to use old coins.  It tries to find the set of coins which has the smallest value above the value you're trying to send, which usually results in a small 'change' output being left in your wallet, which can tend to increase future fees.

The idea of using two wallets is a reasonable one and should work.  Bear in mind that to avoid fees, each coin you spend should be at least one "bitcoin day" old.  i.e. multiply the coin's value in BTC by its age in days, and it that's more than about one then you can probably spend it for free.  That's just a rough rule of thumb, because the number of outputs also affects the transaction size, but only about 20% as much as the number of outputs does.  (Each input adds 179-181 bytes to the transaction size, while each input only adds 34 bytes).

Alternatively, if you feel comfortable building the client from source, you can modify it so that it prefers older coins.  Find the bit in wallet.cpp that says:
and add a few more lines, so it tries the oldest coins first.  Something like this would work:

Depending how 'micro' your coins are, and how old your wallet is, you might want to go further still, but I'm sure you get the point.

Er! Danger Will Robinson! Danger!

The selection function is fairly greedy but the objective is non-convex, this can lead to surprising results.  You can currently end up paying more fees than you need. Consider the following sequence:

Say you want to send 1.0 BTC.
Selection pass runs, finds 1.0 BTC using 100 .01 BTC inputs that all have more than six confirms.
Software then decides that a fee of .01 (random figure) is needed based on the size of the transaction.
Selection runs again looking for 1.01, but can't find that much using inputs with >=6 confirms, so it considers 1 confirm transactions.
Selects inputs of 1.0,0.01 from the set of transactions with at least one confirm, and pays fees that are not really required.

Adding more stages makes this worse.   I have a patch here that first only considers inputs from the set which are high enough priority that any transaction composed solely of them will be high priority, somewhat like your posed your proposed patch but it sets the threshold to be max(144/value,1) confirms.  In my testing I found that it pretty frequently caused stupid decisions at least for wallets with distributions like mine.

If you want to iterate it should be over the entire CreateTransaction, not just inside select coins (and, in fact, all the SelectCoins iteration should be removed). I'm hesitant to write code to do this because any change in this area desperately needs test cases. This code is far too risky to change lightly.

Good point.  I missed that.