Those are good. If you can wait till they pile up another option might be SendMany.

Want to tell more about your the size and frequency of your normal receives and sends? If they are too small and too fast there might not be much to be done.

Sending all coin to one address might not be optimal because then all of your coin will become 'new coin' very often and that causes fees, because that's what a tx spammer would do, send the same coin over and over.

Someone else probably has a better idea than me, but sending to yourself something like 2BTC chunks might be good.

If you plan to increase volume even more and speed is not of the essence you should look into finding or having made a SendMany script. That will let you make a bunch of tx at once for a fee that is only slightly larger than a normal fee.

Consolidating your coins won't reduce your fees though, it will only make it so you pay a big amount during the consolidation step and not a little amount during each spend transaction.

Bitcoin was not built to be a microtransaction system.  0.002 BTC is an amount worth a U.S. penny.  The costs for doing that transaction (transferred and stored at thousands of nodes) are currently being subsidized by the amount of currency that is issued (50 BTC per block, about 7,200 BTC per day, or about $36K USD per day) to the miners.

At some point a lower the miners will start forcing these larger sized transactions to cough up a higher amount for the transaction fee.

So, while the transactions are cheap today, feel free to take advantage of it while it lasts (maybe months, maybe years?).  Just know, this probably won't be the situation forever.

Transaction fees come about from any one of three conditions, two of which you don't always have control over. 

(1) Priority of the transaction inputs:  age * size   (age is in block numbers, size is in BTC).  If there's not enough priority on the inputs, you pay a fee
(2) Total transaction size:  each input is about 170 bytes, each output is about 40 bytes.
(3) Dust outputs:  if any output is less than 0.01 BTC, you have to pay 0.0005 fee.


If you're talking microtransactions, you are probably hitting (3) every time.  But that would only cause a 0.0005 fee.  The priority issue is probably also an issue, but again only causes a fee of 0.0005 BTC.  Number (2) is what causes large fees.   If (1) and (3) are satisfactory, the transaction can be free if it's less than 3-4 kB. 

However, above 3-4 kB, you're going to be paying 0.0005 per kB.  As seen above, inputs are 4x the size of outputs:  if you can bundle up lots of your transactions into a single transaction with lots of outputs, you might be getting those extra outputs for "free".  i.e. if you're going to use 5 kB and return 90% of it as change to yourself anyway, you might as well try to batch all the transactions together.   You're already using 5kB of inputs, your fee probably wouldnt' even go up for 20 outputs.

Btw, I'm pretty sure that even the forced-zero-tx-fee branch of the Bitcoin client still requires a fee for dust outputs.  It's the only thing preventing nodes from spamming the hell out of the network and bloating the blockchain with dust.  However, many nodes will accept low-priority, large-kB transactions without any fee.

-Eto


P.S. -- There's more conditions that may result in fees that have to do with transaction volume on the network.  If blocks are getting full, you will pay more to get yours included.  I have ignored those here, because I don't believe that transaction volume is high enough on the network to induce those.  Worst case, your tx might be delayed a block or two until there is room for your standard-fee tx.

Yup.  But keep in mind that 250KB (where it starts to matter), and 500KB (hard limit) are arbitrary limits that technically can be increased (as a revision to the protocol, i.e., not just new software but a whole process).

There's lots of proposals for pruning.  None of them look like they're going to make it into the protocol/client any time soon.  The devs are more concerned that CPU and internet bandwidth are going to cap out before user start needing multiple hard-drives to store that data.  On the other hand, while the current client is full-blockchain only, the first-time  blockchain download is going to become a serious hurdle for bitcoin adoption.