Interesting. I removed the unconfirmed transaction from my wallet and indeed, after remaining unconfirmed for 2 days it disappeared from the Blockchain. But, several hours later it somehow reappeared on Blockchain in a newer block and actually got confirmed. 

* feels so rusty after 3 yrs absence from the BTC-concept*

What would be the "dynamic fees" in context of the Bitcoin Core client?
Would that be the option I mentioned earlier - "Recommended:  set to 'Normal' " ?
Is it worth to set it even higher up...like move the "lever" thingie to the middle or even farthest right "High"? Or am I always safe if it's set to Normal and my transactions will be confirmed within reasonable time (and _never_ end up in the limbo that I'm currently experiencing due 0.00001BTC/kb setting) ?

Hi,
Thanks for the reply.
I guess I can try that.
Basically what you are saying is that these double-spending (with higher fee) hacks that one can find here and there when googling for this issue aren't really working?

Hi guys,
Please advise here. This is the first time in 3 yrs I've ever tried to make a btc transaction and the rules of the net seem to have changed since then regarding fees and so. Basically I tried to send a small btc amount just to get a feel of it before sending larger amounts to my BTC-trading account. Then I came to discover that I've probably given it too small fee (00001BTC/kb). The transaction got stuck in unconfirmed state over a day. So I googled for the solution to try to cancel the fee - apparently it could be done by using "zapwallettxes" function in Bitcoin Core that I'm using. Clearing the transaction from the wallet worked. I understand that I'm then supposed to use the very same input and send it with larger fee (this time I used the "Recommended: Normal" setting in BitCoin Core which at the moment generated 000047446BTC/kb fee) to some other btc addres and that way "override" the unconfirmed/stuck transaction from days before. It doesn't seem to be working. The old transaction is still there (https://blockchain.info/tx/8aec8cfe5128e0a618c256cea2a1139eb226c9b63abbcad49d9693edc1fce259) while the new one (with dcc24f374233d77b24774d3f76484a3764427104003ed16aecd30618652bbf94 ) is nowhere to be seen on blockchain.info (Sorry we could not find any blocks or transactions matching this hash
). Please help. I simply don't dare to send a single more btc before this clears out. Imagine if the similar problem happened with larger amount - I would go insane.

Any help is appreciated.

Hi guys,

I'm using the latest version of Multibit, even though I've noticed following behavior ever since I started using this app. Every time it starts up the hard drive is constantly writing to wallet files. The disk activity never stops as long as the client is active. The I/O of the system gets effected quite badly so it can be really rough at times. It's okay as long as the block chain is up to date, or just few days off. The problems start if I need to reset the block chain for some reason. The re-sync would start very quickly and the block info would be retrieved for several days just in matter of seconds, but after maybe 30 seconds the hard drive activity and write to the wallet files would start and then the remaining sync would become painfully slow. Same goes to shutting down the client, it can take minutes for it to shut down, as the client needs to write down the data.
The log is filled up with rows like these:

11:45:26.049 [Timer-3] DEBUG org.multibit.file.FileHandler - Result of delete of file '/home/mhead/MultiBit/multibit1.wallet' was true
11:45:26.049 [Timer-3] DEBUG org.multibit.file.FileHandler - End of secureDelete
11:45:26.049 [Timer-3] DEBUG org.multibit.file.FileHandler - Saving wallet file '/home/mhead/MultiBit/multibit1.wallet' ...
11:45:26.062 [Timer-3] DEBUG org.multibit.file.FileHandler - ... done saving wallet file. Wallet file size is 396173 bytes.
11:45:26.063 [Timer-3] DEBUG org.multibit.file.FileHandler - Start of secureDelete

I am aware of the fact that MultiBit is writing down occassional backup wallets to the disk in case of corruption, but it seems to me that it "loops" the writes, never taking a rest, as long as the application is active. CPU usage is usually close to 100%. Not having the top notch machine, but still, this happening on a Linux Ubuntu box with a Core Duo 3GHz and 4GB RAM is just ridicilous.

Any tips?

Thanks in advance!