any idea what to do except waiting or praying?
Yes... I'm thinking this might work...
Basic Idea is that you swipe the unconfirmed transaction to another address you own. Most wallets actually have many addresses in the pool. Anyway, when you swipe the unconfirmed transaction, you put a real juicy TX fee on your swipe TX. Point is for a miner to claim the juicy swipe TX, they have to confirm your floating TX with it.
Basically you pay a bounty for a miner to mine your incoming transactions. That's the BIP anyway.
I know I sound like a broken record on this, hopefully once I run some tests on testnet3 I can back it up with some code or results... Just a proposal based on theory right now.
EDIT On Bitcoin-Qt v0.10.2, when you prepare your SEND transaction, there is a button for "Choose Fee". Default is 25 blocks for confirmation, if you max it out, it claims you will get confirmations in 1 block.
Isn't there something called the replace by fee patch which miners can accept the transaction with more fee than the transaction with less fee? Most mining pool didn't implement that. IIRC, most miners only accept the transaction which reaches their node first and most nodes only relay transactions with inputs that aren't already in your mempool. The 1 block fee can be quite high if the network load is high. If an attacker stresses the network with high fees, your transactions will get pushed down to the bottom unless you are willing to pay a premium.
Nothing. Even though it is small and the outputs are of a good size, your coin age is low. The coin age resets everytime the inputs is used so your input's coin age gets low. If you want fast confirmation, use at least 0.00001 BTC as a fee.